|Anonymous | Login | Signup for a new account||2014-04-20 06:33 CEST|
|My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002003||Kdenlive||Rendering||public||2011-02-03 23:55||2011-06-10 10:49|
|Platform||x86_64||OS||Mandriva Linux||OS Version||2010.2|
|Product Version||Recent git|
|Target Version||Fixed in Version||0.8|
|Summary||0002003: Audio sync with .mov input files|
|Description||I was in the process of discussing this issue with Dan (ddennedy) in another off topic bug report which is now closed.|
I have continued testing on this issue and finally established that 3 frames need to be automatically cropped from the end of these clips in order for them to render with correct audio sync.
The test that I did at the end of the other report was flawed, so I have spent many hours creating test versions of real life videos from hundreds of clips to verify this, using Version 0.7.9 (rev. 5350).
The sync is perfect with 3 frames clipped, with only two clipped it's about 2 seconds out after 35 mins of rendered output using approx 200 clips.
I have not yet used the very latest SVN with the patch to crop just one frame - I didn't want to confuse the issue or myself as this has been a very time consuming exercise.
I hope a change can be made to remove 3 frames automatically.
|Steps To Reproduce||Create a video with many *.MOV files from a Kodak Zx3 video camera. On rendering the audio sync will be unusable unless the last 3 frames are cropped from each clip.|
|Tags||No tags attached.|
|Build/Install Method||Build Wizard|
|I already committed a change that would drop the last 2 frames - not rounding up maybe eliminates one plus, based on the previous bug report, I am subtracting one. I see there is a piece of metadata in the files from this camera, so I can detect these files and subtract some additional frames.|
edited on: 2011-02-09 12:49
Yes that (metadata) may be a way, but I don't think it only applies to this format.
Using the latest trunk (rev. 5384) it does appear to load clips with two frames removed, however there is still a white frame at the end of each clip.
I tested a 150 clip (all different and straight from camera) video made without editing, with a clapper clip on the end.
The audio was still 62 frames (2 seconds) short at the end.
I then manually removed an extra frame from each clip. All the white frames disappeared, but the last frame (of each clip) displayed in the monitor was sometimes black.
I rendered it again.
The audio was 17 frames short - which is still useless for lip sync.
I then looked at your patch and re-built kdenlive after changing this :-
mlt_position frames = ( mlt_position )( ( ( double )context->duration / ( double )AV_TIME_BASE ) * fps - 1 );
mlt_position frames = ( mlt_position )( ( ( double )context->duration / ( double )AV_TIME_BASE ) * fps - 3 );
I made the same project in this build again from scratch (not saved from previous) and now the clips are 4 frames shorter on the timeline than what I calculate the originals to be by the durations given by mediainfo and ffmpeg.
The error when rendered is now just 2 frames, and lip sync is acceptable at the end of this 22 minute video.
There are no errors when viewing the last frames in the monitor and no white frames.
Even when loading the rendered file back onto the timeline the mp4 does not show 4 white frames as it always did before.
This really is a massive improvement - it cleans out all the white frame rubbish, and clips can be used "as is" without horrid sync issues.
Having always previously used only expensive film, my clips need little or no editing, so to have to edit them all just to overcome software problems is a real PITA - and I can't be alone!
So, my feeling would be to go with "-3" as above, or make that value an advanced configuration variable e.g. "Auto crop from all imported clips" and set the default to 4 (-3) :-)
BTW The "seek to first frame" is much better now, but not cured. I am still sometimes seeing frames from middle/end of clips displayed instead of frame one, but it's not affecting render.
Thanks Dan for your efforts.
Fixed in mlt git commit c9cb510.
I know it took a while, but I had to tend to some other matters and then adopt the new ffmpeg metadata API to detect this clip. If others exhibit this problem, I can extend the tests or make it general.
|After this commit and resolution, it was reported that this problem is more broad as reported on IRC and successfully worked around using the same technique. Therefore, a more recent commit in MLT applies this change to _all_ files. The change is to remove the rounding and subtract 3 frames in the duration calculation. This change will likely negatively effect existing projects that have untrimmed clips. That is an unfortunate sacrifice to make for overall progress.|
|P.S. This change in behavior can be overrridden and adjusted on a per clip behavior if needed.|
|On second thought, existing projects will not be affected because their explicit length and out properties override what is being computed.|
|2011-02-03 23:55||barjaczen||New Issue|
|2011-02-08 08:31||ddennedy||Note Added: 0006394|
|2011-02-08 08:31||ddennedy||Assigned To||=> ddennedy|
|2011-02-08 08:31||ddennedy||Status||new => assigned|
|2011-02-09 12:27||barjaczen||Note Added: 0006405|
|2011-02-09 12:43||barjaczen||Note Edited: 0006405||View Revisions|
|2011-02-09 12:49||barjaczen||Note Edited: 0006405||View Revisions|
|2011-03-01 07:20||ddennedy||Note Added: 0006504|
|2011-03-01 07:20||ddennedy||Status||assigned => resolved|
|2011-03-01 07:20||ddennedy||Fixed in Version||=> Recent git|
|2011-03-01 07:20||ddennedy||Resolution||open => fixed|
|2011-03-24 20:30||ddennedy||Note Added: 0006629|
|2011-03-24 20:30||ddennedy||Note Added: 0006630|
|2011-03-24 21:51||ddennedy||Note Added: 0006632|
|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|