[Ffmpeg-devel] [PATCH] movenc timecode track support
Wed Dec 13 14:59:18 CET 2006
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).
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.
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, since time code will go from
elementary stream to container, with delay and asynchronous operations.
Let's say we parse mpeg2 packet and get gop header time code, we should
add a track "on the fly" ? It will polute much the code and be ugly IMHO.
Now time code for mov is handled as a generic data packet, and a generic
IMHO that code does nothing wrong.
Data track copy should be allowed in lavf, that code only contains
special case to handle codec tag tmcd and creating standard atoms.
And it will work for stream copy from mov to mov.
I don't see how that is unacceptable besides the fact that no complete
API is provided. That code has to be written one day or another.
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