[Ffmpeg-devel] [PATCH] mov dnxhd muxing

[Baptiste Coudurier]

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.

>>>> 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.

>> 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 ?

>>> disadvantages:
>>> * one more field in AVCodecContext
>> no fields in AVCodecContext.
> 
> well then its AVFormatContext, it doesnt change things ...

That's one less argument.

>>> * 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 ...".
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 ...

>>> * breaking API & ABI
>> Since when adding is breaking ?
> 
> adding? no, removing yes, read the nonsense you write, you proposed above
> that you want to remove dvd,psp,vcd muxers
> and by that require all applications to be changed to support your idea
> of how things should be implemented instead of the perfectly working current
> API

I proposed to ADD one field (target/flavour) also, and you focused on
the removing of psp muxer, that is nonsense.

> if you think you can maintain ffmpeg better then me id suggest you fork

I am not talking about maintaining, I am talking about extending, adding
features, though I might fork one day, it seems our goals are different.

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