[Ffmpeg-devel] [PATCH] lowres chroma bug
Oleg Metelitsa
oleg
Mon Feb 12 09:08:26 CET 2007
Hello,
>> > 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