[FFmpeg-user] duration discrepancies when transcoding mov with edit lists

Dave Rice dave at dericed.com
Mon Jun 30 21:19:00 CEST 2014


On Jun 26, 2014, at 2:33 PM, Dave Rice <dave at dericed.com> wrote:

> Hi all,
> I believe this issue is related to an open ticket http://trac.ffmpeg.org/ticket/1137, but in the meanwhile I'm looking for advice for a workaround.
> 
> I have many files that are captured using the Log and Capture process within Final Cut Pro 7. Here is a sample.
> 
> http://dericed.com/samples/1sec1frame_v210_according_to_QT.mov
> 
> When this file is viewing in QuickTime 7 or Final Cut 7 the file has a duration of 30 frames or 00:00:01;01.
> `ffmpeg -i 1sec1frame_v210_according_to_QT.mov` gives a matching duration of 00:00:01.03
> 
> But whenever I transcode the video using ffmpeg the output is much longer at 00:00:02.06. The output shows many frames that are not shown by QuickTime 7 or Final Cut.
> 
> When I load at the quicktime structure I see the video track edit list atom shows:
> track duration=3100
> time scale=2997
> 
> The duration would equal 3100/2997 or 01.03 matching the duration listed by ffmpeg -i, but ffmpeg when transcoding decodes far past the end point signified by the edit list atom.
> 
> My workaround seems to see to use `ffmpeg -i` or ffprobe to get the start time and duration of the video file and then to use these values in -ss and -t during the transcode. So instead of
> 
> ffmpeg -i 1sec1frame_v210_according_to_QT.mov [options here] nowhowlong.mov
> I would use
> ffmpeg -i 1sec1frame_v210_according_to_QT.mov -ss 0.210210 -t 00:00:01.03 [options here] nowhowlong.mov
> 
> So far that seems to work for me, but is this a sane approach to the issue?
> Dave Rice

ping



More information about the ffmpeg-user mailing list