[Ffmpeg-devel] [PATCH] mov dnxhd muxing

[Michael Niedermayer]

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


> 
> >>>> Humm I would prefer not, and I would like to remove those fancy flavors
> >>>> of mp4 muxers, Im looking for a generic way to handle specific atoms
> >>>> required for ipod/psp. 3g2 muxer is code duplication and it only change
> >>>> brand of ftyp atom, psp only adds a few atoms, maybe a "target" or
> >>>> "flavor" field in AVFormatContext, then a table of flavors in muxers ?
> >>>> That should provide also some kind of "target" support, we could provide
> >>>> some AVOption tables to be used.
> >>> advantages: none i can see
> >> * avformat can supply known good encoding settings quickly and simply.
> > 
> > this doesnt belong in avformat, not even libav*
> > 
> > 
> >> * get rid of dummy muxers (vcd,dvd,psp)
> > 
> > break vcd, dvd, psp muxing ...
> 
> not if we add target field to avformat.

if you remove the muxers and add a field to avformat no existing application
will be able to use the muxers anymore this breaks API and ABI


> 
> >> I don't think it is better for everyone to copy ffmpeg.c target command.
> > 
> > no but theres more then one way to solve this, what you propose
> > is not a good solution a good solution would be to use files with
> > name=value pairs to store various defaults, something like
> > dvd-rip-hq.options
> > psp-h264-900kbit.options
> > ...
> > 
> > its user editable, doesnt waste space in memory or the object files, doesnt
> > even depend on the lib version, doesnt require us to maintain 300 target
> > formats in libav*, ...
> 
> isn't codec-cfg.c in mplayer ? Why isn't it only a configuration file ?

this is not mplayer-dev or mplayer-users could we keep the disscussion
at least somewhat related to ffmpeg please


> 
> >>> disadvantages:
> >>> * one more field in AVCodecContext
> >> no fields in AVCodecContext.
> > 
> > well then its AVFormatContext, it doesnt change things ...
> 
> That's one less argument.

-AVCodecContext
+AVFormatContext
so yes one less and one more, or in other words, no change

its clear you have not a single technical argument for the change please
stop the trolling


> 
> >>> * one more table in AVOutputFormat
> >> yes
> >>
> >>> * one more parameter _every_ application must deal with and no AVOption
> >>>   cannot magically make user apps select an entry from the table in
> >>>   the specific AVOutputFormat
> >> for target in AVOutputFormat->Targets
> >> 	if name == target->name
> >> 		options = target->options
> >> 	
> >> for option in options:
> >> 	opt_set_....
> >>
> >> I don't agree at all with your reasoning, if we follow it,
> >> ffmpeg/libavcodec/libavformat won't have any new parameter ever, since
> >> every application will have to deal with that new parameter.
> > 
> > huh? i made a list of advantages and a list of disadvantages for adding this
> > parameter and from them its clear the disadvantages outwheight the advantages
> > thats not true for every new parameter
> 
> No you said "one parameter _every_ application must deal with and ...".

no ive made 2 lists one point on the list of dissadvantages was that every
application must contain explicit code to support the new parameter while
otherwise the generic code to support muxers is enough


> Anyway adding one muxer every time an atom must be written specifically
> vs adding one field once is clearly better, you avoid adding it to
> allformats.c/h, Makefile ...

may i ask why dont you just unconditionally write all these atoms? shouldnt
a compliant quicktime demuxer ignore unknown atoms?
also why is mov/mp4 the only container needing such mess, no other needs that

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

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

I have often repented speaking, but never of holding my tongue.
-- Xenocrates
-------------- 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/c7530053/attachment.pgp>