[Ffmpeg-devel] [PATCH] mov dnxhd muxing

[Michael Niedermayer]

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 ?


[...]
> > 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

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
-------------- 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/20070323/d591dd14/attachment.pgp>