[Ffmpeg-devel] [PATCH] mov dnxhd muxing

Måns Rullgård mans
Fri Mar 23 21:31:41 CET 2007


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.

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

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

Such tables belong in a configuration file of some kind.  Adding some
functions to parse a simple configuration file and apply setting to an
AVCodecContext or AVFormatContext might be something to consider.

I really think we should try to find a solution acceptable to all.  It
would be a shame to lose a good developer.

-- 
M?ns Rullg?rd
mans at mansr.com




More information about the ffmpeg-devel mailing list