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

[Baptiste Coudurier]

Michael Niedermayer wrote:
> 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

A wrong guess.

> [...]
>>>>>> 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"?

Aren't you prefering democracy ? In a democracy I can say what Im thinking.
And Im a developer following ffmpeg since more than 1 year now, and an
active
contributor.

Anyway I noticed you did not even care to mention where a problem with a
mov having a wrong height/width caused problem.

[...]

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
SMARTJOG S.A.                                    http://www.smartjog.com
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
Phone: +33 1 49966312