[Ffmpeg-devel] [PATCH] mov dnxhd muxing

Baptiste Coudurier baptiste.coudurier
Sat Mar 24 02:01:50 CET 2007


Baptiste Coudurier wrote:
> 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.

Well no, forget that, it would be more intuitive to set output format to
avid-mov. I would prefer to set avformatcontext->variant to "avid" though

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