[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