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

Michael Niedermayer michaelni
Sat Apr 14 18:40:36 CEST 2007


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?

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

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?

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


Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein
-------------- 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/26f98fa6/attachment.pgp>

More information about the ffmpeg-devel mailing list