[MPlayer-dev-eng] sig11 in -vo x11 - probably bug in SwScaler

[Michael Niedermayer]

Hi

On Sunday 31 March 2002 17:26, Arpi wrote:
[...]
> > > Now, while tracing a bug in RLE codec, i've got reproducable sig11
> > > again, now with no scaling but in the scaler doing 24->32bpp bgr
> > > conversion. It seems that in 24bpp modes it reads more than the
> > > allocated image, maybe reads few bytes (lines?) too lot.
> >
> > the 24->32 code does allways read 1 byte too much (last bgr is read as
> > 32-bit) but if the width %8 != 0 than it would read more over the end, i
> > can fix that but there would be a small performance loss (0.?%) as we
> > must do th e
> > last 8 pixels in C, isnt it easier too allocate a larger buffer? and if
> > it
>
> hmm. is it only fro _src_ image?
the swscaler uses the plain C routine for writing the last line so it should 
be ok, but there are a few unscaled converters which might have problems

> i can tweak the vd.c image allocation code to allocate bigger, it is not
> problem (just ugly but if it affects the speed - it's ok).
> but what is for codecs with own internal buffer allocation (which use
> IMGTYPE_EXPORT)? afaik only libmpeg2, odivx libavcodec ars euch, but they
> are all yv12.
hmm, the mmx2 scaler will read over the end with yv12, ill rewrite the mmx2 
horizontal scaler perhaps, as i think it might be possible to fix this & make 
it even faster :)

>
> > reads a line too much than thats a serious bug ...
>
> yes
>
> what happens in yuv2rgb when width or height %2 !=0 ?
> width is rare, but i have files where height%2!=0 and they are yv12.
> the codecs internally work on 8x8 or 16x16 macroblocks but the display area
> (sh->disp_w/h) is smaller, and as it's passed to yuv2rgb dunno what will
> happen...
the swscaler is able to handle it (i did try it some time ago and it worked, 
but the unscaled yuv2rgb had problems with odd sizes) but i didnt do any 
overread overwrite checks, just looked at it and it looked fine while yuv2rgb 
didnt

ill check through the swscaler code and ill try to fix at least some of these 
bugs, but ill skip the stuff which would cause a meassureable performance 
loss or would mean a lot of work for me ;)

[...]

Michael