[Ffmpeg-devel] [PATCH] mov dnxhd muxing

[Baptiste Coudurier]

Michael Niedermayer wrote:
> Hi
> 
> On Fri, Mar 23, 2007 at 01:05:20AM +0100, Baptiste Coudurier wrote:
>> Michael Niedermayer wrote:
>>> Hi
>>>
>>> On Thu, Mar 22, 2007 at 11:04:05PM +0100, Baptiste Coudurier wrote:
>>>> 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.
>>> huh? movenc.c does not contain code which writes them depending on codec_tag
>> huh, that's what Im willing to do and fighting for, you are against it,
>> Im proposing another solution, you are against it, you propose another
>> muxer, Im against it, I think we are having a fair discussion here.
>> I want to write those atoms if tag is AVdn or AVdv or ....
> 
> why not write them if codec_id==DVVIDEO ?

I asked that in the first mail :(

I explained the problem with default decoder, please, I did not write
mov mess, Im just trying to find the simplest and good solution to be
able to use those files.
If we use "dv5p" for DVVIDEO 50mbit/s PAL, it will only play with Final
Cut pro installed. If we use "AVdv" it will play with avid codecs
installed, those can be freely downloaded from avid, I asked, mainly to
you, a good suggestion, I think I would change current behaviour and use
avid tags, but what if someone wants to use the file in Final Cut ? He
has to use "dv5p" and he can do that by using -vtag dv5p, ok API is not
so easy/clear, but that can be documented.

> [...]
>>> also many of these flavors of mov you are speaking off are documented in
>>> completely seperate specifications, its not correct to merge them into one
>>> externally vissible muxer even if we could, and the code is shared anyway ...
>> If you are talking about 3gp/mp4/isom, yes they are different of mov, Im
>> only talking about needed atoms in "stsd" MOV. if (codec_tag == "bleh"
>> && mov->mode == MODE_MOV), also notice muxer is using a "flavour" field
>> to distinguish variants, and putting them in "our" mp4 would be ok
>> according to our brand which is "isom" and specs clearly says specific
>> atoms for decoders should be ignored if unknown.
> 
> you can put all the 3gp 3g2 and psp stuff in .mp4 but what about the ftyp
> this differs currently, if it would work with isom ftyp which i doubt a
> little then iam not opposed to merge them all and write the extra atoms
> unconditionally

A good thing would be to make ftyp brand user configurable, that's why I
though about some target/flavour field, and if psp flavour is used,
write those atoms.
Now I don't feel like writing all psp shit in 3gp. 3gp is by far the
cleanest variant of ISO Media IMHO.
Also Robert Swain tells me latest psp firmwares does not need those
shitty atoms anymore....

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