[Ffmpeg-devel] [PATCH] mov dnxhd muxing

[Baptiste Coudurier]

Michael Niedermayer wrote:
> Hi
> 
> On Fri, Mar 23, 2007 at 11:11:06PM +0100, Baptiste Coudurier wrote:
>> Hi
>>
>> M?ns Rullg?rd wrote:
>>> Michael Niedermayer <michaelni at gmx.at> writes:
>>>
>>>> Hi
>>>>
>>>> On Fri, Mar 23, 2007 at 07:14:38PM +0000, M?ns Rullg?rd wrote:
>>>>> Michael Niedermayer <michaelni at gmx.at> writes:
>>>>>
>>>>>>> According to new policy, can you please supply me a full svn dump ?
>>>>>> i would if i had access to it, please ask
>>>>>> root at mphq or 
>>>>> What policy, 
>>>> i think baptiste means the draft propsal thing in mplayer svn, calling it
>>>> policy is of course not really correct ...
>>>>
>>>>> what sort of dump,
>>>> dont ask me ...
>>>>
>>>>> and what for?
>>>> baptiste wants to fork due to philosophical disagreement
>>>>
>>>> to summarize
>>>> avid needs some specific atom in mov to play dv in mov
>>>> final cut pro does not need that specific atom
>>>>
>>>> baptiste does not agree to always write the atom
>>> If writing it is still in line with the spec, I don't see a problem
>>> with doing so.  I can't imagine it incurring any significant size
>>> overhead.
>> atoms present inside stsd are decoder specific atoms, passed to the
> 
> yes but does adding these avid atoms to all dv variants break anything
> in the spec?
> does it break final cut pro? or other dv decoders?

I don't know, I can try, to it's still an ugly solution.

>> decoder. In quicktime/isom/mp4/3gp philisophy a codec_tag is associated
>> to a specific decoder,
> 
> mp4a? aac, mp3, ... ?

I was too quick, it's quicktime API.

>> and associated to specific atoms, all avid
>> codec_tags (AVdn, AVdv, AVUI, AVmp) use those atoms (ACLR, APRG, ARES)
> 
> and here i really feel that a avid-mov muxer would be a reasonable solution

We need to find something more elegant, bloating Makefile and
allformat.c/h is not reasonable.

>>>> he doesnt agree to drop support for either of the 2 propriatary applications
>>>> he neither agrees to use a dummy muxer for the avid atom variant similar to
>>>> psp/3gp muxers
>>> While I think the dummy muxers are a little hackish, I don't see a
>>> cleaner immediate solution.
>> if (mode == MODE_MOV && (codec_tag == "AVdn" || codec_tag == AVdv))
> 
> you forgot AVUI and AVmp at least, how many more are there? how do you
> know this list is complete?

I don't know atm, I can try to generate all samples with avid.

> how should the user know he has to override the fourcc to make these
> atoms appear?

Yes I concede that this not intuitive, but -f avid-mov is not intuitive
for me either, even though it is listed in ffmpeg -formats, and anyway
people directly using lavf, access muxers directly using guess_format
with "avid-mov", that's not more intuitive than setting codec_tag to
AVdv, IMHO, though would just need some documentation.

> its like
> user1: " ive encoded dv in mov but avid doesnt play it"
> dev: " force AVdv"
> user2: " ive encoded mpeg2v in mov but avid doesnt play it"
> dev: " force AVmp"
> ...
> 
> while OTOH it would be
> user1: " ive encoded dv in mov but avid doesnt play it"
> dev: "moron, you must use -f avid-mov"
> user1: " ive encoded mpeg2 in mov but avid doesnt play it"
> dev: "moron, you must use -f avid-mov"
> ...
> 
> later is much more intuitiv

It's not for me, but that's my own point of view, I feel more comfortable
using ffmpeg -i file -vtag AVdv -vcodec dvvideo test.mov

>>>> instead he wants either
>>>> base the writing of the atom on the codec_tag (fourcc) or add
>>> Ugh.
>>>
>>>> a target field and various tables to the muxers (=redesign the API with
>>>> no advantage but breaking API&ABI by doing so and making everything more
>>>> complex)
>> a target field without those tables is also ok, and you could use it to
>> differentiate between 3gp and 3g2 and get rid of 3g2 muxer which only
>> change ftyp brand.
> 
> breaks API & ABI and increases complexity from the user apps POV
> it also breaks simply listing the supported container (variants)

I still don't get how adding one field at the end breaks ABI/API.

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