|Anonymous | Login||2016-07-29 17:57 CEST|
|My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000428||Kdenlive||MLT||public||2008-12-03 11:01||2010-08-03 22:14|
|Product Version||Recent git|
|Target Version||Fixed in Version|
|Summary||0000428: AVCHD Clips shown with artifacts in the preview window|
i want to cut and rendering AVCHD Clips, but when i move the cusor in the preview window, it shows a lot of artefacts. The rendering process works fine, also the cutting of a clip.
Theres no problem to give you a test clip.
Thank you very much
|Tags||No tags attached.|
|Build/Install Method||Build Wizard|
Could you take a look at the Playback / Rendering section at the end of:
and let us know how ffplay and inigo go and your version numbers (see the section titled "Version:"
|FFmpeg does not yet provide good support for seeking on AVCHD. Sorry. If you want to confirm this yourself and give some feedback, then use ffplay to play the clip and click on different parts of the window to seek around. The window's x axis is the "scrub bar." I suggest to do this test because FFmpeg is always improving, and MLT's usage of FFmpeg API for seeking may not be optimal.|
I've done this test and the results are the same as in kdenlive preview.
Thank you for the information.
|I am considering other "backends" to MLT such as gstreamer and gmerlin-avdecoder, but FFmpeg already gives us a lot, another backend is a lot of work, and there is plenty of other work to do. However, if you decide to investigate either of the above's support for AVCHD and find one works great, I would like to know and take that into consideration.|
|Thank you for your support. At this time i render my AVCHD file to HDV 1080 50i thats good enought for me.|
Just to note: gmerlin_avdecoder and gmerlin CAN do seeking without artifacts. In video_ffmpeg.c it has the following code:
/* Hack for (possibly wrong encoded) h.264 streams */
if((pi->pts != BGAV_TIMESTAMP_UNDEFINED) &&
(priv->last_parse_pts != BGAV_TIMESTAMP_UNDEFINED) &&
(priv->info->ffmpeg_id == CODEC_ID_H264))
duration = gavl_time_rescale(s->timescale, 4 *
pi->pts - priv->last_parse_pts);
// fprintf(stderr, "Frame duration: %d -> %d\n", pi->pts -
if((duration > 0) && (duration < 3 *
s->data.video.format.timescale *= 2;
|Thank you for trying to help, Johannes. I can decipher this to mean, if the hack is needed, then double the timescale of something in gmerlin_avdecoder. This might explain why some movies seem to play at half speed after I transcode them with ffmpeg. I might be able to use this hint to enable a workaround to the playback rate in MLT. Unfortunately, we only use the seek api of ffmpeg libavformat, and I think that can only be fixed in libavformat such that it seeks backwards far enough to be able to fully decode the desired frame.|
|Btw, taking a AVCHD-file and cutting it into four clips and then putting them back together also produces the same artifacts when rendering! That means that AVCHD-support is pretty much dead for now, until this gets resolved, maybe in ffmpeg, but no-one there seems to answer bug reports. I have a test-clip here: http://www.johanneswilm.org/download/johanneswilm.mts [^]|
|I sent this message to FFmpeg developer list.|
edited on: 2008-12-31 17:16
I read your comments on that list.
While it's true that on the fly editing is preferable, it will be quite impossible for most hardware for still some time to come.
If kdenlive used at least optional proxy editing, both this issue would go away and most modern hardware would be usable for editing AVCHD.
We are working on your bug report, but there is not a single issue at stake, but several: timestamps, speed decoding, etc ... Dan and FFmpeg members have solutions, but they only work in their spare-time. All this depends on work of volunteers (like myself). I have been thinking of your problem during several hours. A solution would make Kdenlive one of the most powerful solution available today.
My preferred solutions:
* Hardware decoding would be excellent, as cheap Nvidia cards only cost 40€. It would also enable film makers to use Kdenlive with large resolutions cams.
* We can also drop B-frames during editing, which can multiply view speed by two. But this still requires a fast computer.
As for proxy editing and transcoding, it might be the only solution in the forecoming days or weeks. I suggest transcoding the AVCHD files to MPEG-2 I-frames only. I will get back to you.
|Can you register your cam with footage, please? At least 4 camcorders have the same problems as you describe. I hope that we can gather enough footage to help FFmpeg members take this issue seriously and fix it.|
Okay, I tried to copy your AVCHD into Mpeg2-I frames high quality:
ffmpeg -i johanneswilm.mts \
-f mp4 \
-acodec copy \
-pix_fmt yuv420p -vcodec mpeg2video -qscale 1 -qmin 1 \
-trellis 1 -intra \
The -copyts option is highly important as it keeps timestamp. You wron't believe me, but FFmpeg is able to read timestamps in Mpeg2. But size of the video is 10x the size of the original AVCHD file.
So I am working on a AVCHD -> AVCHD I frames, lossless only conversion.
Sure I can register it -- but where? I did contact ffmpeg and mplayer and whoever else I could find in this business around June, but never heard more about it.
As to the Mpeg2-i and size: for the preview-window only a small version of the video is required and so it doesn't need to be lossless either. If proxy editing can be included seamlessly (maybe spending some time during initial loading of the file for that without the user having to touch ffmpeg directly), and the original stream then be used for the final rendering, then it would already greatly improve the usability of kdenlive.
And of course I know you guys all work on a volunteer basis. And I'm very thankful for it. I do work on open source software as well as my hobby, although in a very different domain. And yes, I know it takes a lot of time and can be unrewarding when one only hears criticism.
Keep on the good work!
edited on: 2008-12-31 18:46
I know what you mean with proxy settigs. This is third solution. But if timestamps are broken, there may still be problems. We need to make test and understand more what the different options offer. With 5 camcorders support being broken, this may even interest FFmpeg developers.
|VDPAU hardware decoding was added to FFmpeg today. Wait a while until the dust comes down and something is implemented.|
|There have been a lot improvements and hardware decoding is also supported in MLT, so closing this. There are separate requests for editing with proxy clips.|
|2008-12-03 11:01||volker_holthaus||New Issue|
|2008-12-03 11:01||volker_holthaus||Build/Install Method||=> Build Wizard|
|2008-12-03 17:15||cinephiliac||Note Added: 0001504|
|2008-12-03 17:15||cinephiliac||Status||new => feedback|
|2008-12-04 02:27||ddennedy||Note Added: 0001516|
|2008-12-05 14:38||volker_holthaus||Note Added: 0001537|
|2008-12-05 18:18||ddennedy||Note Added: 0001538|
|2008-12-08 15:54||volker_holthaus||Note Added: 0001575|
|2008-12-13 20:13||johanneswilm||Note Added: 0001639|
|2008-12-14 07:36||ddennedy||Note Added: 0001642|
|2008-12-18 18:16||johanneswilm||Note Added: 0001793|
|2008-12-29 13:06||jmpoure||Note Added: 0001960|
|2008-12-31 17:14||johanneswilm||Note Added: 0001987|
|2008-12-31 17:16||johanneswilm||Note Edited: 0001987|
|2008-12-31 17:33||jmpoure||Note Added: 0001988|
|2008-12-31 17:35||jmpoure||Note Added: 0001989|
|2008-12-31 18:16||jmpoure||Note Added: 0001990|
|2008-12-31 18:40||johanneswilm||Note Added: 0001991|
|2008-12-31 18:43||jmpoure||Note Added: 0001992|
|2008-12-31 18:44||jmpoure||Note Edited: 0001992|
|2008-12-31 18:46||jmpoure||Note Edited: 0001992|
|2009-01-02 21:43||ddennedy||Relationship added||has duplicate 0000531|
|2009-01-05 10:52||jmpoure||Note Added: 0002066|
|2010-08-03 22:13||ttill||Note Added: 0005468|
|2010-08-03 22:13||ttill||Status||feedback => resolved|
|2010-08-03 22:13||ttill||Resolution||open => fixed|
|2010-08-03 22:14||ttill||Status||resolved => closed|
|Copyright © 2000 - 2016 MantisBT Team|