[FFmpeg-devel] [PATCH 2/2] movenc: add timecode track support.

Tim Nicholson nichot20 at yahoo.com
Wed Apr 4 16:22:39 CEST 2012





----- Original Message -----
> From: Clément Bœsch <ubitux at gmail.com>
> To: FFmpeg development discussions and patches <ffmpeg-devel at ffmpeg.org>
> Cc: 
> Sent: Wednesday, 4 April 2012, 15:03
> Subject: Re: [FFmpeg-devel] [PATCH 2/2] movenc: add timecode track support.
> 
> On Tue, Mar 20, 2012 at 12:27:52PM +0000, Tim Nicholson wrote:
>>  On 20/03/12 08:00, Clément Bœsch wrote:
>>  > On Tue, Mar 20, 2012 at 07:39:01AM +0000, Tim Nicholson wrote:
>>  >> On 09/03/12 16:51, Clément Bœsch wrote:
>>  >>> From: Clément Bœsch <clement.boesch at smartjog.com>
>>  >>>
>>  >>> The example in the QT specs shows a likely invalid gmin atom 
> size, which
>>  >>> suggests tmcd atom is contained in the gmin one, while it is 
> actually in
>>  >>> the gmhd atom, following gmin (according to the given layout 
> on the same
>>  >>> page, and various samples):
>>  >>>
>>  >>> [..]
>>  >>
>>  >>
>>  >> ping.
>>  >>
>>  > 
>>  > Patch rebased for review, no functional changes from previously 
> (IIRC).
>> 
>> 
>>  OK this sort of half works, but something isn't quite right.
>> 
>>  Ffprobe reports the timecode OK as does FCP7 and sebsky. *However* if you 
> scroll
>>  along the clip the timecode gets lost/freezes. This does not happen with a
>>  genuine clip.
>> 
>>  Inspecting the clip in Quicktime7 using <Command> J and comparing 
> with the same
>>  clip exported out of FCP shows a significant difference.
>> 
>>  Whilst the duration of my sample clip is shown as 01:01.92 for all tracks 
> in the
>>  exported (genuine) version. The ffmpeg version shows the timecode track as 
> being
>>  only 4 frames long. (By comparison ffmbc timecode track has the same 
> duration as
>>  the clip and scrolls OK)
>> 
> 
> I did a full re-check and fixed a "little" thing; tcmi atom was 
> missing 16
> bits in the middle (it's not in the specs, but it seems there is indeed 16
> "unknown" bits in the samples I have). I don't know if that will 
> help (it
> shifts a few things so maybe it does).
> 
> However, I couldn't find anything suspicious in the durations or timescale
> related fields, so if that's still reproducible with the attached patch,
> could you share the original samples, the command line you used, and
> expected output (from QT7 or anything)?
> 

Hi Clément, I am currently now on holiday so won't be able to test until I get back after 16th April. Ping me if you don't hear anything then...

> Anyway, thank you for testing it and raising feedback,

My pleasure.

> 
> -- 
> Clément B.


 
-- 

Tim


More information about the ffmpeg-devel mailing list