[Ffmpeg-devel] [PATCH] mov dnxhd muxing

[Baptiste Coudurier]

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
quicktime pass whole stsd atom to decoders, and those atoms are
contained IN stsd atom, so you cannot decorelate them.

>> 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.
* get rid of dummy muxers (vcd,dvd,psp)

I don't think it is better for everyone to copy ffmpeg.c target command.

> disadvantages:
> * one more field in AVCodecContext

no fields in AVCodecContext.

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

> * breaking API & ABI

Since when adding is breaking ?

[...]

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