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

[Baptiste Coudurier]

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.

Also I'd like to mention that it is always a fight when you did broke
something, swf demuxing for example, but there you did not request for a
 so called "bug report", so you clearly acts like it please you.

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

>>>> I don't know any file with different height in container than sum of
>>>> both field, since mjpeg supports any resolution, while some codecs don't
>>>> , and that's why mov do that.
>>> but mov does that too with mpeg4 and mpeg4 also supports any resolution
>> Im not aware of any problem concerning mpeg4, h263 yes, but not mpeg4.
>> Can you please submit a bug report ?
> 
> there is no bug as the mov demuxer correctly ignores width/height for mpeg4
> in mov, it didnt at some point in the past and people did send bugreports
> so it was fixed ...

there was a bug, can you highlight it, I did not see it ever. And I
doubt this was a bug and I bet Quicktime did display it correctly.

> but as you are mov maintainer you should know that and not ask me, hey
> why not go and read the quicktime spec like you ask me to do with ODML?

Im not aware of any bug related to this issue, can you please point me
to subject date ?

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

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