[Ffmpeg-devel] I'm giving up

[Michael Niedermayer]

Hi

On Tue, Dec 05, 2006 at 01:55:59PM +0100, Panagiotis Issaris wrote:
> Hi Michael,
> 
> On Thu, 2006-11-23 at 20:21 +0100, Michael Niedermayer wrote
> > > [...]
> > > In my case, my employer is getting fed up with the patch not getting
> > > accepted, and it is getting hard for me to explain and defend the
> > > reasons for getting the patches integrated in the main repository. Most
> > > likely, they will not want me to adapt the patches anymore, and just
> > > carry on with the development, publishing them, but no more then that. 
> > > Which results in what basically is a fork. Which I'd truly dislike as
> > > this would most likely exclude others from helping out.
> > 
> > would a branch in ffmpeg svn with your encoder help? if so ive no
> > objections, i just object that it is added to the main ffmpeg branch
> > until its perfect
> Indeed, it would solve several problems as it would make it easier for
> others to contribute and it would be "in" the FFmpeg tree... 
> 
> But I fear it will not differ much from the current situation as the
> code isn't _really_ "in", it won't get the same exposure as the main
> branch and I'd still have to do the continuous merging.
> 
> What is the reason for objecting to it being added to the main branch
> before being perfect? I mean, surely, it will never be "perfect". So,
> does that mean that it will never get into the main branch? There surely
> has been other code which wasn't perfect and still got added to the main
> branch.
> 
> How would you feel about adding it to the main branch, but disabling it
> by default by using #defines f.e.? It already will not be accidentally
> chosen by users as the "h264" codecname chooses the x264 encoder.
> 
> The diffstat shows that the modifications in the patch in existing files
> is minimal:
>   Changelog                     |    1 
>   doc/ffmpeg-doc.texi           |    2 
>   libavcodec/Makefile           |    1 
>   libavcodec/allcodecs.c        |    2 
>   libavcodec/avcodec.h          |    1 
>   libavcodec/dsputil.c          |    8 
>   libavcodec/dsputil.h          |   16 
>  
>  
> These are the only exceptions, and they were made in response to
> suggestions on the mailinglist:
> libavcodec/h264.c             |  146 --
> libavcodec/h264data.h         |   27 
>  
>  
> I could remove the regression tests modifications to make the patch even
> less intrusive, but I'd think that wouldn't be a good thing to do.
>  tests/Makefile                |    2 
>  tests/ffmpeg.regression.ref   |    4 
>  tests/regression.sh           |   13 
>  tests/rotozoom.regression.ref |    4 
>  
>  
> All other hunks in the patch involve new files:
>   libavcodec/h264cavlc.c        |  311 +++++
>   libavcodec/h264dsp.c          |  260 ++++
>   libavcodec/h264enc.c          | 2503
>  ++++++++++++++++++++++++++++++++++++++++++
>   libavcodec/h264enc.h          |  105 +
>   libavcodec/h264encdata.h      |  110 +

could you send a patch with just the needed changes to existing files?

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

If you really think that XML is the answer, then you definitly missunderstood
the question -- Attila Kinali