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

[Michael Niedermayer]

Hi

On Wed, Apr 11, 2007 at 02:17:14PM +0200, Baptiste Coudurier wrote:
> Hi
> 
> 3 patches:
> 
> - remove useless MpegEncContext.
> - fix odd field height decoding.
> - fix some interlaced content.

what is some?


> 
> justification:
> odd_heigth.mov, this sample is 720x405, 

where is this sample?


> and setting height *= 2 is then
> wrong, correct is to set it to container height.
> Since height change every field, do that for every field, not only for
> first picture.

what the 2nd patch seems really to do is 
1. correct a bug where half the init code was only exceuted for width/height
changes during the first frame, this worked fine with even interlaced height
but with odd interlaced height the height changes after every field and so
the init code gets executed after every field but due to the bug just half
of it gets executed ...
2. replace frame height= jpeg height*2  by frame height= container height
why this is hidden under a million of conditionals is unclear
also its unclear what will happen with mov style w/h missuse for croping


what the 3rd patch does is still unclear to me ...


> 
> ODML specs specify the use of AVI1 tag, and meaning of polarity (0 for

what does ODML have to do with mjpeg? is this series of patches related to
mjpeg in avi? the sample file whos location we dont knoe is a .mov not avi


> prog, 

prog? you mean progressive, if so write progressive


> 1 means encoded from first field, 2 means encoded from second
> field), 

so you speak about a variable somewhere in the ODML-avi container spec
which stores a progressive/interlacaed and temporal field order or is it
rather spatial order flag? hows that related to mjpeg and how to the patches?


> and only set polarity when first field is being decoded, use of
> new second_field in context.

this makes no sense, iam i supposed to read the jpeg and odml specs and then
reverse engeneer what the patch does? your comments are as usefull as 
/dev/random

sorry but if you cannot clearly describe what your patches do and why then
they are rejected
the amount of time i spend with your patches likely exceed he time you spended
writing them, i feel like iam being throwen random hacks at and then you even
pester me so i waste even more time looking at the mess again to somehow
make sense of what exactly the patch really changes while you know exactly
but dont describe it in a understandable way

its not even clear which of your comments relates to which of the patches
that is without looking at the patches ...

also the 3rd patch contains cosmetic changes!

and each patch should be in a seperate mail

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The worst form of inequality is to try to make unequal things equal.
-- 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/08a219d6/attachment.pgp>