[Ffmpeg-devel] I'm giving up

Panagiotis Issaris takis.issaris
Tue Dec 5 13:55:59 CET 2006

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

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 +

With friendly regards,
vCard: http://www.issaris.org/pi.vcf
Public key: http://www.issaris.org/pi.key

More information about the ffmpeg-devel mailing list