[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