[Ffmpeg-devel] [PATCH] movenc timecode track support

Baptiste Coudurier baptiste.coudurier
Wed Dec 13 17:02:10 CET 2006

Michael Niedermayer wrote:
> Hi
> On Wed, Dec 13, 2006 at 02:59:18PM +0100, Baptiste Coudurier wrote:
>> Michael Niedermayer wrote:
>>>>>>>>>>> [...]
>>>>>>>>>> Any problem with that patch ?
>>>>>>>>> what good does it do? / what is a timecode track good for?
>>>>>>>> Useful to specify start time of the media, used in editing systems
>>>>>>>> (Final Cut). Mov timestamps always start from 0. Basically same use as
>>>>>>>> mpeg2 gop headers timecode or h264 sei picture timing.
>>>>>>> except that these dont contain things with names like color, font face
>>>>>>> graphics mode, ... what the hell do these do in that "timecode track"?!
>>>>>> You can display time code in quicktime player, and those defines how to.
>>>>> ok and how now is that start time brought from the user into the final file?
>>>>> definitly not the same way as with mpeg and thats unacceptable, whatever the
>>>>> API it must be the same between different containers
>>>> A packet containing 32 bit int frame count start. What is unacceptable ?
>>> theres no common API
>>> you cant expect every user of libav* to know how the starttime is stored
>>> in every format, then if the user doesnt know how should he use this?
>>> and why should every application have to duplicate the respective code?
>>> and how to convert between mov<->mpeg the starttime would be lost ...
>> Common API between what ? Lavc and lavf ? IMHO there should be 2 APIs.
>> If the user wants to set time code in gop headers and a different one in
>> mov file, he should be able to do so, even if that sounds stupid at the
>> beginning (Im thinking about drop frame and non drop frame variants).
> no, setting different start times at muxer and codec layer is useless
> unless you want to create broken files with contradcting information
> its the same as with width/height or sample rate, nothing special here

Different width and height at container/codec level are common with
quicktime. I bet to allow cropping for codecs which does not support it.

People do it, time code in gop headers is starting from 0 and container
time code is set to media start (MXF). Same for D-10 which contain a
SMPTE time code in mpeg2 extradata, and 422 profile allows you to encode
all active lines (VBI) which can contain another time code.

It allows different referentials for different kind of people working on
/with the media. (Broadcaster, editers, dubbers)

IMHO not supporting it is caping lavf.

>> There is no API for lavf yet. Like we do not have CODEC_TYPE_TIME_CODE,
>> and no demuxer/muxer at all supports something like that. Now if you
>> agree to add that codec type, I'll be happy to work on demuxing time
>> code in GXF and MXF.
> CODEC_TYPE_TIME_CODE is unacceptable

It is not at all like CODEC_TYPE_WIDTH and CODEC_TYPE_HEIGHT.
SMPTE defines standards to code time code: SMPTE 12M, and how to
transport it in containers (MXF, GXF), codecs(MPEG2, DV)
I see a point "decoding" it and use an internal common format.

EG 40-2002 Conversion of Time Values Between SMPTE 12M
Time Code, MPEG-2 PCR Time Base and Absolute Time 32.00

SMPTE 266M-2002 Television ? 4:2:2 Digital Component Systems ?
Digital Vertical Interval Time Code                      22.00


What would be acceptable ?

>> There is an API to set time code in lavc for mpeg2. You can extend it to
>> set sei picture timing in h264 or mpeg4 gop header if you want.
>> Now an API lavc<->lavf is complicated, 
> no it is not, its the same as with width/height, either demuxer sets it
> or decoder/parser set it in av_find_stream_info()

Time code in mpeg2 gop headers can be non linear, can jump, and it not
forbidden behaviour, and pretty used by people: Spliced mpeg, cut scenes
for dubbing purpose...

Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
SMARTJOG S.A.                                    http://www.smartjog.com
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
Phone: +33 1 49966312

More information about the ffmpeg-devel mailing list