|Anonymous | Login | Signup for a new account||2014-03-07 21:59 CET|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001962||Kdenlive||Capture||public||2011-01-04 15:11||2011-06-10 10:49|
|Platform||x86_64||OS||Mandriva Linux||OS Version||2010.2|
|Target Version||Fixed in Version||0.8|
|Summary||0001962: Transcoding to mkv or wav truncates audio|
|Description||My input files are *.MOV like the attached sample from Kodak Zx3.|
When I transcode to "lossless Matroska" in kdenlive I lose about 17 frames worth of audio at the end of the clip.
If I transcode the clip's audio to wav I also lose a much smaller portion of the audio.
See this screen shot.
The top two tracks are the split original file
The next two tracks are the original transcoded with mkvmerge (perfect AFAICT).
The next two are the same file transcoded in kdenlive to lossless Matroska.
The last track is the wav.
|Steps To Reproduce||Add the attached clip to a project.|
Select it and right click -> transcode -> Lossless Matroska
Check "add clip to project" -> Start
Add both clips to the timeline and compare.
|Additional Information||Sorry the category is incorrect but there was no correct option.|
I can find no way to attach multiple files here, so if you need the output files please ask and I will upload individually.
|Tags||No tags attached.|
|Build/Install Method||Distribution package|
|Attached Files||100_0184.MOV [^] (3,024,430 bytes) 2011-01-04 15:11|
|This seems to be fixed in trunk.|
|transcode just uses ffmpeg. you mean trunk of ffmpeg fixes this?|
I didn't, but that is probably the reason.
My Kdenlive 7.8 uses my system version of ffmpeg which is:-
FFmpeg version SVN-r22960, Copyright (c) 2000-2010 the FFmpeg developers
built on Jun 15 2010 16:28:30 with gcc 4.4.3
configuration: --prefix=/usr --enable-shared --libdir=/usr/lib64 --shlibdir=/usr/lib64 --incdir=/usr/include --disable-stripping --enable-postproc --enable-gpl --enable-pthreads --enable-libtheora --enable-libvorbis --disable-encoder=vorbis --enable-x11grab --enable-runtime-cpudetect --enable-libdc1394 --enable-libschroedinger --enable-libmp3lame --enable-libfaad --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-version3 --enable-libx264
libavutil 50.14. 0 / 50.14. 0
libavcodec 52.66. 0 / 52.66. 0
libavformat 52.61. 0 / 52.61. 0
libavdevice 52. 2. 0 / 52. 2. 0
libswscale 0.10. 0 / 0.10. 0
libpostproc 51. 2. 0 / 51. 2. 0
My current build of Kdenlive trunk uses :-
FFmpeg version SVN-r26302, Copyright (c) 2000-2011 the FFmpeg developers
built on Jan 10 2011 15:09:49 with gcc 4.4.3
configuration: --prefix=/home/baz/kdenlive/20110110 --disable-doc --disable-network --disable-ffserver --enable-gpl --enable-version3 --enable-shared --enable-debug --enable-pthreads --enable-libmp3lame --enable-libx264 --enable-libvpx
libavutil 50.36. 0 / 50.36. 0
libavcore 0.16. 0 / 0.16. 0
libavcodec 52.108. 0 / 52.108. 0
libavformat 52.92. 0 / 52.92. 0
libavdevice 52. 2. 3 / 52. 2. 3
libavfilter 1.72. 0 / 1.72. 0
libswscale 0.12. 0 / 0.12. 0
Would you please look at the format of the attached clip from my Kodak Zx3 camera, as I have been struggling with Kdenlive (all versions) using these clips (profile 720p 29.97fps) for about a month now. It seems that unless I crop the first frame and the last 4 frames from each clip in the timeline, the rendered output in Kdenlive runs out of lip sync (several seconds after 30mins play).
The last 4 frames display as either blank or duplicates in kdl, also the first frame is displayed as a random frame from the middle of the clip.
With each clip cropped this way, several hundred clips remain in sync when rendered to mpeg4.
I would like an opinion before filing it as a kdenlive bug.
It is for this reason that I have not yet registered this camera with kdenlive.
I did some investigation. First of all, I have a fix in my working copy for the problem with reliably seeking back to the first frame. You were not the first to report it. However, typically, when rendering, this should not be a problem because Kdenlive does not yet support reversing the clip direction, and it still reliably seeks to an in point and plays from the first frame okay. I just made a new MLT release over the weekend that does not contain this fix, and the fix is not exactly trivial to apply yourself. However, again, it should be mainly only a cosmetic issue.
Regarding the duration, Kdenlive/MLT/FFmpeg only makes a duration estimate. FFmpeg can only know the exact duration after decoding the entire clip. However, MLT and Kdenlive has no way to dynamically alter the clip duration once it plays through an entire clip. For these files, for some reason, FFmpeg over estimates the duration. Even after remuxing to mov, it over estimates by a couple of frames. One extra frame is due to a rounding error. There is some floating path to determine the length in frame units, and I round that up to the next whole frame to err on the side of not inadvertently removing some footage. I am thinking about changing that, but it still will not be 100%. When I superficially subtract an extra 1 from that duration, it works fine in the remuxed file, but I still get an extra frame on the original file. Therefore, you must manually trim out the white "error" frames unless I am convinced it is OK to change my policy and somewhat arbitrarily subtract 2 to 4 from the reported duration to err on side of safety. What do you think?
I have also been doing some tests.
I wrote a script to remove a number of frames from each file and re-encode it, using ffmpeg. The shortened files have the same problem when added to the timeline, and sync still runs wildly out when rendered, which I expected after your explanation.
One strange result of this test is that every re-encoded file starts at frame 3 of the source file. (When compared on the timeline in kdl) I used :-
ffmpeg -i $filename -vframes $oframes -r 29.97 -vcodec copy -acodec copy $outfile
Could some of the extra end frames be due to skipped start frames I wonder ? (All frames time shifted back by 2)
My full script is here for your interest:-
I admit to being lost with this issue, but from a practical point of view I think it would be best to automatically crop the last 4 frames unless another solution can be found. This does produce useable clips which would stay in sync when simply piled onto the timeline and rendered.
Regarding the first frame seeking patches - will these be added to trunk in due course?
So you feel it is OK to truncate the reported duration for every video file of every kdenlive user?
Currently, over-estimation has a manual workaround, but there is no workaround (within Kdenlive) to extend an incorrect duration that is shorter than actual.
>>So you feel it is OK to truncate the reported duration for every video file of every kdenlive user?
No not necessarily. I was assuming that each input file would be handled according to it's parameters, and that this treatment would only be applied to known problem file types.
FWIW during my searches for a solution to this issue I came across many reports of similar problems - none of which concluded in a proper fix.
I have been trying to edit 850 clips into a video since mid December using Kdenlive and have spent most of that time on trying to work around this issue.
It is a serious problem which needs a proper solution.
I feel that losing 4 frames (133ms) would be a small price if it saved a month of frustration.
You did not comment on the missing start frames using ffmpeg. Any thoughts?
Re: this treatment would only be applied to known problem file types
This is much easier said than done. The only criteria I have at the moment for this workaround rule is to apply it whenever there is H.264 in MOV, which is very broad. In general, I avoid workarounds for specific formats. It makes the code difficult to maintain, and the worked-around behaviour tends to be sensitive to the FFmpeg version. The format-specific stuff rightly belongs in the respective modules of the FFmpeg libs.
You could perhaps save some time by transcoding everything to something more reliable for editing. Generically speaking this means no temporal compression, but not necessarily the bulky Lossless Matroska.
Re: every re-encoded file starts at frame 3 of the source file.
When I remuxed the sample you provided, I did not reproduce this. How are you observing it? single-frame-stepping in Kdenlive? If so, then you are vulnerable to the bug on seeking to the first frame. Actually, I am not convinced that is a bug in MLT. For some file types, seeking to the first from elsewhere in the file works just fine. There are different seeking behaviors in FFmpeg based on format. The workaround I am adding is not ideal, but it is a different approach for a specific use case that works universally (no regression) by simply closing the video stream and re-opening it.
I am not going to go into any deeper analysis of your remuxing script and its results because that is diverging from the core problem, and I see little insight to gain from it. It only adds noise and confusion to the discussion.
I think we need to focus on whether removing the last four frames alone without removing the first frame resolves your a/v sync problem because I am not ever going to arbitrarily remove the first frame. Then, the question is why would you not manually trim the white error frames at the end? Most people have to trim each shot anyways.
>This is much easier said than done. The only criteria I have at the moment for
>this workaround rule is to apply it whenever there is H.264 in MOV, which is
>very broad. In general, I avoid workarounds for specific formats. It makes the
>code difficult to maintain, and the worked-around behaviour tends to be
>sensitive to the FFmpeg version.
Fair enough - I can appreciate the difficulty
>The format-specific stuff rightly belongs in
>the respective modules of the FFmpeg libs.
I have been spending some time on #ffmpeg IRC trying to get some help on this.
>You could perhaps save some time by transcoding everything to something more
>reliable for editing. Generically speaking this means no temporal compression,
>but not necessarily the bulky Lossless Matroska.
I did try this (using Matroska) which threw up another bug with ffmpeg which was cropping the audio - I filed a bug. However the sync problem was not cured - only reduced. I would not know which format to choose as an alternative interim file - I used Matroska as you suggested it in another similar case in the forum.
>Re: every re-encoded file starts at frame 3 of the source file.
>When I remuxed the sample you provided, I did not reproduce this. How are you
>observing it? single-frame-stepping in Kdenlive?
Yes - but I am ignoring frame one and comparing 2,3,4, etc.
Note that the audio is correct and starts on frame one (apart from the bug I reported about the audio channels displaying one frame displaced).
>If so, then you are vulnerable to the bug on seeking to the first frame.
I don't think so as noted above.
>I am not going to go into any deeper analysis of your remuxing script and its
>results because that is diverging from the core problem, and I see little
>insight to gain from it. It only adds noise and confusion to the discussion.
I agree. (but it could be related)
>I think we need to focus on whether removing the last four frames alone without
>removing the first frame resolves your a/v sync problem because I am not ever
>going to arbitrarily remove the first frame.
I agree - I think the frame one issue is not related to the sync issue, but at the time I was trying to find a workaround I did not know about the frame one seek problem or I would have ignored it.
I will stop removing frame one in my edits and see how the sync issue goes.
>Then, the question is why would you
>not manually trim the white error frames at the end? Most people have to trim
>each shot anyways.
I already have on over 500 clips - that's not the point. I am trying to help make Kdenlive an even better product by testing and reporting these issues.
How would your average user know that it was necessary to remove 4 frames? It took me about 3 weeks to figure out (and that's pretty much full time as I am retired). Questions on the forum and in #kdenlive got me nowhere.
Most people would have given up long ago.
Please don't feel that I am complaining in any way, I am just trying to help get to the bottom of what is an annoying issue for many people who will want to use the Kodak Zx3 (and now Zx5) which I guess has the same format, with Kdenlive in the future. Personally I can now live with this bug, but it would be better fixed.
> I will stop removing frame one in my edits and see how the sync issue goes.
It will be very helpful if you can test that specifically since I do not have enough of this footage to test adequately for a/v sync esp. over the durations you are describing.
> How would your average user know that it was necessary to remove 4 frames?
My thought was that they would see these 4 frames as undesirable white frames and trim them away. Are you not seeing them as white?
I appreciate your desire to make things better, and I want to see if this resolves the issue. Truncating the file by a few frames at the end is not out of the question especially if it saves people from some frustration and prevents an a/v sync problem.
I have done a fairly controlled test this morning.
I took a 5 second clip with a clapper in the middle. I then added this 10 times to the timeline.
Each test was rendered to mpeg4 200k and viewed in Kdenlive.
Unmodified clips from camera.
Result:- Video exactly 5 frames behind audio in middle of last clip.
With 3 frames cropped on timeline from end of each clip.
Result:- In sync.
As test 2 but with frame number one cropped from the start of each clip.
Result:- In sync. With 10 black frames appended before 3 white ones at the end.
As test 2 but with 4 frames cropped.
Result:- In sync.
Test 5. As test 2 but with 2 frames cropped from each clip.
Result:- In sync.
Test 6. As test 2 but with only 1 frame cropped from each clip.
Result:- In sync !!
I was expecting clicks at clip joints, as there is something horrible in the last 2/3 frames of each clip showing on the source timeline, however there is nothing visible (or audible) in the rendered output.
So, this is encouraging, but inconclusive, as I cannot tell from these tests if any audio gaps are present in the rendered output as there was no background noise, or if there are duplicate frames added between clips.
I will do a repeat test with sound and steady motion in each clip to check the joins.
|I have checked in changes to mlt git to truncate the duration instead of rounding and to subtract it by one. Also, I checked in the change to reliably seek to the first frame.|
|2011-01-04 15:11||barjaczen||New Issue|
|2011-01-04 15:11||barjaczen||File Added: 100_0184.MOV|
|2011-01-08 10:38||barjaczen||Note Added: 0006306|
|2011-01-18 07:15||ddennedy||Note Added: 0006325|
|2011-01-18 17:19||barjaczen||Note Added: 0006326|
|2011-01-25 06:46||ddennedy||Note Added: 0006343|
|2011-01-25 20:50||barjaczen||Note Added: 0006345|
|2011-01-25 21:13||ddennedy||Note Added: 0006346|
|2011-01-25 21:35||barjaczen||Note Added: 0006347|
|2011-01-25 22:49||ddennedy||Note Added: 0006348|
|2011-01-26 01:28||barjaczen||Note Added: 0006349|
|2011-01-26 07:03||ddennedy||Note Added: 0006351|
|2011-01-26 13:48||barjaczen||Note Added: 0006353|
|2011-01-30 21:40||ddennedy||Note Added: 0006370|
|2011-01-30 21:40||ddennedy||Status||new => resolved|
|2011-01-30 21:40||ddennedy||Fixed in Version||=> Recent git|
|2011-01-30 21:40||ddennedy||Resolution||open => fixed|
|2011-01-30 21:40||ddennedy||Assigned To||=> ddennedy|
|2011-04-26 21:58||j-b-m||Fixed in Version||Recent git => 0.8|
|2011-06-10 10:49||Granjow||Status||resolved => closed|
|Copyright © 2000 - 2014 MantisBT Team|