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

[Michael Niedermayer]

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


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


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


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

well, i cant read your mind to find out why you change things like you do
i surely can reverse engeneer the code and figure out what it did before and
after your change (iam not the author of the interlacing code in mjpeg)
and then put a few av_log() in there and see the effect it
has on various videos, i didnt do this and i think its not my job to

the situation with h.264 is similar the last h264 patch submitted i complained
about that i didnt know what and why it does, the author explained and split
the patch up in simpler parts the original patch was just changing 6 lines of 
code (see subject:h264: fix processing of end of sequence nal unit)


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras
-------------- 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/5b34953f/attachment.pgp>