[Ffmpeg-devel] [PATCH] lowres chroma bug

Oleg Metelitsa oleg
Mon Feb 12 09:08:26 CET 2007


>> > 3)  We can add two extra pixels to image in lowres=2 mode:
>> > image_stride =  image_width  +  2
>> > chroma_stride = image_width/2 + 2
>> > Then  the garbage will be written to those extra (dummy) pixels rather
>> > than to the beginning of the next row.
>> Please,  find  the  patch  3)  attached.  It  may be not so interested
>> comparing  to  the  patches  proposed earlier. But the advantage is it
>> does not change non lowres H.264 operation.
>> Index: libavcodec/utils.c
>> ===================================================================
>> --- /libavcodec/utils.c (revision 7890)
>> +++ /libavcodec/utils.c (working copy)
>> @@ -279,7 +279,9 @@
>>          if(!(s->flags&CODEC_FLAG_EMU_EDGE)){
>>              w+= EDGE_WIDTH*2;
>>              h+= EDGE_WIDTH*2;
>> -        }
>> +        } else if(s->lowres==2)
>> +            w+= 4;
>> +
>>          avpicture_fill(&picture, NULL, s->pix_fmt, w, h);
>>          pixel_size= picture.linesize[0]*8 / w;

MN> and it will fail if avocodec_default_get_buffer() isnt used aka for example
MN> in mplayer

I  do  not  know any way to add extra pixels if an application creates
the buffer for image storage and sets AVPicture->linesize[] by itself.

In  this case the only solution is your idea to separate lowres codes.
I  like this idea because there is an additional serious image quality
bug  in  lowres  mode. To see it try set frame rate 1 fps and lowres=2
and look at moving parts of an MPEG4 image. (Look for example at faces
of  moving  people).  All  moving  parts of the image are cumulatively
loosing  details  between I-frames. The effect is more visible in case
of big GOP size (i.e. 60). There is no such effect in case of lowres =
0. I do not have any idea how to fix this bug without writing separate
code for lowres.


Oleg Metelitsa

More information about the ffmpeg-devel mailing list