[Ffmpeg-devel] [PATCH] mjpeg cleanup and again interlaced fix

Michael Niedermayer michaelni
Sat Apr 14 19:07:56 CEST 2007


Hi

On Sat, Apr 14, 2007 at 06:52:27PM +0200, Baptiste Coudurier wrote:
> Michael Niedermayer wrote:
> > Hi
> > 
> > On Sat, Apr 14, 2007 at 06:16:40PM +0200, Baptiste Coudurier wrote:
> >> Michael Niedermayer wrote:
> >>> Hi
> >>>
> >>> On Sat, Apr 14, 2007 at 02:36:07PM +0200, Baptiste Coudurier wrote:
> >>> [...]
> >>>>>>>> you also should know what will happen with mov style w/h CORRECT cropping,
> >>>>>>>> aren't you also mov.c maintainer ?
> >>>>>>> well i think mjpeg after the 2nd patch from you will break with mov
> >>>>>>> cropping, which would mean your 2nd patch is buggy
> >>>>>> Well, it might break for cropping, but it is IMHO less buggy than
> >>>>>> before, patch addresses an issue, and does not address the other issue,
> >>>>>> but still height *2 is wrong.
> >>>>> i dont know if its written in any docs but we have always rejected bugfixes
> >>>>> which knowingly introduce other bugs
> >>>> Why don't you send patches to common parts, which I will know will
> >>>> introduce other bugs ? So you can experience that "rejected" feeling.
> >>> iam maintainer of the common parts also you are free to complain if i break
> >>> something
> >> I did. You voluntary still ignore it and don't fix.
> > 
> > i dont know what exactly you mean, could you tell me the subj/date of the
> > mail where you complained?
> 
> http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2007-March/026040.html
> 
> about r_frame_rate detection.

r_frame_rate is a guess as its documented straight above the variable


[...]
> >>>> You broke ./configure --enable-debug with your h264 bugs without asking
> >>>> anyone and without even willing to fix, and you just said "send patch",
> >>>> that proves how you care about others.
> >>> its a gcc bug ...
> >> You still broke something working, so you must reverse it. Your solution
> >> was not acceptable.
> > 
> > if a changes in the source cause some version of gcc to fail (or even all
> > versions of gcc)
> > due to a gcc bug, this still is a gcc bug and not one in ffmpeg, as its
> > not a ffmpeg bug theres no reason why it should be reversed
> 
> I don't think that is a valid reason to break other working features.
> You MUST deal with gcc bugs like it or not, and not breaking working
> features OR you must implement YOURSELF the check for available
> registers, not saying that you don't care about PIC or that you are lazy.

who are you that you tell me what i "MUST"?


[...]
> >>>>> the proper solution is to use the sum of the height of both fields not the
> >>>>> container height
> >>>> Again feel free to implement that solution, you are mjpeg.c maintainer,
> >>>> and I bet that bug won't be fixed anytime soon.
> >>>>
> >>>>>>>>>> anyway consider that as
> >>>>>>>>>> a bug report 
> >>>>>>>>> ok, then write a proper bugreport
> >>>>>>>> You are aware of the problem now, you have the sample.
> >>>>>>> iam a volunteer, if people dont provide proper bugreports i wont look at
> >>>>>>> the bug, and giving me a sample and a patch i dont understand is not
> >>>>>>> a bugreport
> >>>>>> hey michael Im also a volunteer, I consider trying to fix the bug myself
> >>>>>> to avoid you looking at it better than simply bugreporting, now I don't
> >>>>>> understand why you always answer with aggressivity and without any trust
> >>>>> i do not intentionally awnser agressively and review is not about trust
> >>>>> a patch which i dont understand i wont approve
> >>>> You can understand h264 complicated code, but not what a 10 lines patch
> >>>> does ? Nonsense, you do understand what the code does, you are just
> >>>> unhappy with it, and you just complain, and hope that by complaining
> >>>> patch sender will give up.
> >>> [...]
> >>> after your change (iam not the author of the interlacing code in mjpeg)
> >> you are maintainer, you should know what the code does do, it's not my
> >> job to explain you what the code currently does.
> > 
> > well if you want your patch in svn you should help me instead of fight me
> 
> I have my svn dump now, feel free to fix your own bugs.

if you do a real fork please announce the url on ffmpeg-dev so we can
port any important and correct bugfixes you make to the main ffmpeg-svn

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I count him braver who overcomes his desires than him who conquers his
enemies for the hardest victory is over self. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070414/adebdd97/attachment.pgp>



More information about the ffmpeg-devel mailing list