[Ffmpeg-devel] I'm giving up

Michael Niedermayer michaelni
Thu Nov 23 20:21:50 CET 2006


Hi

On Thu, Nov 23, 2006 at 04:54:48PM +0100, Panagiotis Issaris wrote:
> Hi,
> 
> On Tue, 2006-11-21 at 14:59 +0100, Reimar D?ffinger wrote:
> > Hello,
> > On Tue, Nov 21, 2006 at 01:44:10PM +0100, Cyril Russo wrote:
> > > Ok guys,
> > > 
> > > I'm fed up. Here the patch attached (in case Thunderbird messes it up). 
> > > There is no tab inside as both
> > > hexdump -C mjpeg.c | grep  "09 "
> > > hexdump -C mjpeg.c | grep  " 09"
> > > give no output.
> > > 
> > > What could have been a 5 mn process is becoming a 3 days issue for what 
> > > ? 50 lines of code.
> > 
> > I can understand you, and I left my first patch to ffmpeg for others to
> > fix, too. Though I think there were simpler patches that had to go
> > through worse.
> > I'd like to say though that at the rate that ffmpeg evolves 50 lines of
> > only suboptimal code will become 500 lines of mess in no time. Look at
> > some of the code in MPlayer (e.g. mplayer.c) if you need "proof"...
> Code can also be optimized and improved after being accepted in the main
> source tree.
> 
> I do not think that acceptance in the main source tree excludes code
> improvements afterward. Of course I am not saying that all code should
> be accepted on first post, but I do not think that new code should be
> perfect either. Moreover it's an added feature, not including the code
> gives several disadvantages. Namely, the new feature is not there even
> if it would have been suboptimal implementation. Secondly, the changes
> (optimizations etc.) which the contributor makes on his own are not
> being tracked and logged by the revision control system. Thirdly, others
> are less inclined to help out on completing and optimizing the new
> feature. And fourthly, it frightens off new contributors.
> 
> And fourthly, it frightens off new contributors, directly as in the case
> of the parent of this thread, or indirectly as in my case.

well, the situation with the parent is a little different as kostya
provided a much simpler and cleaner solution though yes it doesnt support
every valid jpeg but still i suspect that kostyas solution can be extended
to support all cases supported by Cyrils patch without having to duplicate
the function
and the optimization well it has to be split and  benchmarked, adding
START/STOP_TIMER around recompiling and comparing the output is a matter
of 5min ...


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


-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is




More information about the ffmpeg-devel mailing list