[FFmpeg-user] ffprobe MOV TAG:timecode does not match Quicktime Player

[Dave Rice]

On Jan 2, 2013, at 3:52 PM, Gary Margiotta <gary_margiotta at yahoo.com> wrote:
> 
> On Dec 27, 2012, at 5:06 PM, Carl Eugen Hoyos <cehoyos at ag.or.at> wrote:
> 
>> Gary Margiotta <gary_margiotta <at> yahoo.com> writes:
>> 
>>> ffprobe version 0.10.2 Copyright (c) 2007-2012 the FFmpeg developers
>> 
>> Please test current git head.
>> If it is still reproducible, please provide a sample.
> 
>>> I can confirm that this scenario is still reproducible within the current git head. In the procedure he used to create the file the value >>"21:43:06;29" is still stored within the timecode track but an edit list is created within the timecode track (as well as any others) to >>identify the proper offset. I think this is related this ticket: https://ffmpeg.org/trac/ffmpeg/ticket/1137
>>> Dave Rice
> 
> Thanks Dave for the info.  Carl, I cannot post the sample since it s a proprietary asset.

I produced some samples of the issue using the -timecode option and the mandelbrot source. If I understand correctly https://ffmpeg.org/trac/ffmpeg/attachment/ticket/1137/5seconds_with_tc.mov should be an example of a file before your edit and https://ffmpeg.org/trac/ffmpeg/attachment/ticket/1137/5seconds_with_tc_with_QTedit.mov an example of a file after your edit. Both report a timecode in ffmpeg of 01:00:00:00 although the second edited one starts on a different value in ffmpeg because of the edit. I describe this more here: https://ffmpeg.org/trac/ffmpeg/ticket/1137#comment:3. A related issue that you didn't mention is that ffmpeg will also decode all the frames that you had edited out which was the original nature of my ticket.

> What does start_time with a negative value represent?

I've seen this with some types of QuickTime edits and the sample that I created above also exhibits a negative start_time value after the edit.

> Could the absolute value of the start_time parameter in the ffprobe
> output be used as an offset from the TAG:timecode parameter to get the actual start timecode of the clip

Subtracting the negative start time from the reported timecode does provide the timecode that QuickTime 7 starts with but I don't think this approach can be used reliably. For instance with https://ffmpeg.org/trac/ffmpeg/attachment/ticket/2044/fcp_capture.mov the reported timecode matches between ffmpeg and QuickTime, 00:59:14;24, but ffmpeg reports a start_time of 0.100434 which at the frame rate is 3 frames. Subtracting the start_time from the reporting timecode in this case would cause an inaccuracy.

Dave Rice