[Ffmpeg-devel] [PATCH] mov dnxhd muxing

Baptiste Coudurier baptiste.coudurier
Fri Mar 23 01:05:20 CET 2007

Michael Niedermayer wrote:
> Hi
> On Thu, Mar 22, 2007 at 11:04:05PM +0100, Baptiste Coudurier wrote:
>> Hi
>> Michael Niedermayer wrote:
>>> Hi
>>> On Thu, Mar 22, 2007 at 06:41:00PM +0100, Baptiste Coudurier wrote:
>>>> Hi
>>>> Michael Niedermayer wrote:
>>>>> Hi
>>>>> On Thu, Mar 22, 2007 at 01:53:48PM +0100, Baptiste Coudurier wrote:
>>>>> [...]
>>>>>>>> Also, avid codecs need those specific mov atoms for some codecs ffmpeg
>>>>>>>> already supports, what would be the good way to write them ?
>>>>>>>> Example: you can mux dv into mov using "AVdv" tag, then avid codecs will
>>>>>>>> decode stream perfectly if those atoms are present, though quicktime
>>>>>>>> wont decode it by default.
>>>>>>>> Quicktime has a native decoder for dv25 so use native one, but for dv50,
>>>>>>>>   there is no decoder. We can use Final cut one, which use his own
>>>>>>>> codec/own tag but only useable when fcp is installed, or Avid ones which
>>>>>>>> are freely available.
>>>>>>>> So what muxing by default, and how to switch ? codec_tag ("stsd" tag) is
>>>>>>>> a solution, but people will have to know which tag to use.
>>>>>>> i dont think codec_tag should be (mis)used for this, but rather a new muxer
>>>>>>> similar to the one for psp should be added to movenc.c
>>>> Can you explain why you think that is "misusing" ? Remember that
>>> because the value of codec_tag does not depend on the existence of these
>>> specific atoms, a specific codec_tag also doesnt require a specific
>>> set of these atoms just try mp4v and psp vs. mp4
>> I am talking about existence of these atoms because of the value of
>> codec_tag, and that is correct.
>>>> quicktime pass whole stsd atom to decoders, and those atoms are
>>>> contained IN stsd atom, so you cannot decorelate them.
>>> well you dont pass the whole atoms and you didnt propose to pass them
>>> so thats unrelated ...
>> existence of these specific atoms depends on codec_tag.
> huh? movenc.c does not contain code which writes them depending on codec_tag

huh, that's what Im willing to do and fighting for, you are against it,
Im proposing another solution, you are against it, you propose another
muxer, Im against it, I think we are having a fair discussion here.
I want to write those atoms if tag is AVdn or AVdv or ....

>>>>>> Humm I would prefer not, and I would like to remove those fancy flavors
>>>>>> of mp4 muxers, Im looking for a generic way to handle specific atoms
>>>>>> required for ipod/psp. 3g2 muxer is code duplication and it only change
>>>>>> brand of ftyp atom, psp only adds a few atoms, maybe a "target" or
>>>>>> "flavor" field in AVFormatContext, then a table of flavors in muxers ?
>>>>>> That should provide also some kind of "target" support, we could provide
>>>>>> some AVOption tables to be used.
>>>>> advantages: none i can see
>>>> * avformat can supply known good encoding settings quickly and simply.
>>> this doesnt belong in avformat, not even libav*
>>>> * get rid of dummy muxers (vcd,dvd,psp)
>>> break vcd, dvd, psp muxing ...
>> not if we add target field to avformat.
> if you remove the muxers and add a field to avformat no existing application
> will be able to use the muxers anymore this breaks API and ABI

Deprecating them and waiting for some major bump is one solution.
You are against it, point taken, now API/ABI evolve hopefully,
many API/ABI breaks occured, and will occur.

>>>> I don't think it is better for everyone to copy ffmpeg.c target command.
>>> no but theres more then one way to solve this, what you propose
>>> is not a good solution a good solution would be to use files with
>>> name=value pairs to store various defaults, something like
>>> dvd-rip-hq.options
>>> psp-h264-900kbit.options
>>> ...
>>> its user editable, doesnt waste space in memory or the object files, doesnt
>>> even depend on the lib version, doesnt require us to maintain 300 target
>>> formats in libav*, ...
>> isn't codec-cfg.c in mplayer ? Why isn't it only a configuration file ?
> this is not mplayer-dev or mplayer-users could we keep the disscussion
> at least somewhat related to ffmpeg please
>>>>> disadvantages:
>>>>> * one more field in AVCodecContext
>>>> no fields in AVCodecContext.
>>> well then its AVFormatContext, it doesnt change things ...
>> That's one less argument.
> -AVCodecContext
> +AVFormatContext
> so yes one less and one more, or in other words, no change
> its clear you have not a single technical argument for the change please
> stop the trolling

One argument is Makefile, allformats.c/h changes needed because
you just add another muxer for one atom, that is a good technical
argument, I don't think discussing and having another point of view is

>>>>> * one more table in AVOutputFormat
>>>> yes
>>>>> * one more parameter _every_ application must deal with and no AVOption
>>>>>   cannot magically make user apps select an entry from the table in
>>>>>   the specific AVOutputFormat
>>>> for target in AVOutputFormat->Targets
>>>> 	if name == target->name
>>>> 		options = target->options
>>>> for option in options:
>>>> 	opt_set_....
>>>> I don't agree at all with your reasoning, if we follow it,
>>>> ffmpeg/libavcodec/libavformat won't have any new parameter ever, since
>>>> every application will have to deal with that new parameter.
>>> huh? i made a list of advantages and a list of disadvantages for adding this
>>> parameter and from them its clear the disadvantages outwheight the advantages
>>> thats not true for every new parameter
>> No you said "one parameter _every_ application must deal with and ...".
> no ive made 2 lists one point on the list of dissadvantages was that every
> application must contain explicit code to support the new parameter while
> otherwise the generic code to support muxers is enough
>> Anyway adding one muxer every time an atom must be written specifically
>> vs adding one field once is clearly better, you avoid adding it to
>> allformats.c/h, Makefile ...
> may i ask why dont you just unconditionally write all these atoms? shouldnt
> a compliant quicktime demuxer ignore unknown atoms?
> also why is mov/mp4 the only container needing such mess, no other needs that

Because it adds unneeded data, strict minimum is the good way to do.

Point is not about mov/mp4 being a messy container. Point is about
adding a feature (allowing ffmpeg files to be directly ingested in AVID
editing system, or used by avid codecs), which can SIMPLY be done by
checking codec_tag, my solution is simplest.

> also many of these flavors of mov you are speaking off are documented in
> completely seperate specifications, its not correct to merge them into one
> externally vissible muxer even if we could, and the code is shared anyway ...

If you are talking about 3gp/mp4/isom, yes they are different of mov, Im
only talking about needed atoms in "stsd" MOV. if (codec_tag == "bleh"
&& mov->mode == MODE_MOV), also notice muxer is using a "flavour" field
to distinguish variants, and putting them in "our" mp4 would be ok
according to our brand which is "isom" and specs clearly says specific
atoms for decoders should be ignored if unknown.

It is better to avoid code duplication, don't you think ?

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