[Ffmpeg-devel] [PATCH] mov dnxhd muxing

Michael Niedermayer michaelni
Sat Mar 24 00:25:13 CET 2007


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?


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

mp4a? aac, mp3, ... ?


> 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


> 
> >> 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?
how should the user know he has to override the fourcc to make these
atoms appear?

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


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

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070324/91cf1a8f/attachment.pgp>



More information about the ffmpeg-devel mailing list