[Ffmpeg-devel] [PATCH] mov dnxhd muxing

Michael Niedermayer michaelni
Thu Mar 22 22:00:26 CET 2007


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


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


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


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


> 
> > disadvantages:
> > * one more field in AVCodecContext
> 
> no fields in AVCodecContext.

well then its AVFormatContext, it doesnt change things ...


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


> 
> > * breaking API & ABI
> 
> Since when adding is breaking ?

adding? no, removing yes, read the nonsense you write, you proposed above
that you want to remove dvd,psp,vcd muxers
and by that require all applications to be changed to support your idea
of how things should be implemented instead of the perfectly working current
API

if you think you can maintain ffmpeg better then me id suggest you fork

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

The worst form of inequality is to try to make unequal things equal.
-- Aristotle
-------------- 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/20070322/40a67084/attachment.pgp>



More information about the ffmpeg-devel mailing list