[MPlayer-dev-eng] [bug] expand vs. pp vs. lavc :)

[Arpi]

Hi,

> > is it again an expand problem (i don't think so, maybe some side-effects of
> > some align-values?) or pp bug or feature? :)
> pp bug, fixed, 
thx

> btw perhaps, we should mention in the tech docs somewhere that filters should 
> try to avoid writing outside the width x height rectangle even if its within 
> stride x height

yes...
filters/codecs can request a w*h buffer by callig get_image(), and will
get a buffer stride>=width>=w & height>=h... but they shouldn't read/write
outside of their w*h range...
(actually codecs/filters requiring MB boundaries already requests
w=(disp_w+15)&(~15), h=... sized buffers)

there are (currently) 2 cases when it gets buffer stride>w:
- horizontal expand (vf_expand OR -vo DGA or framebuffer with -dr)
- big (32...) align requirements of overlay hw (g400 requires 32-aligned BES
lines, and also some Xv driver rounds up stride to 2^n && n>=2)

in the former cases (expand) the part outside of w*h is visible...

btw this whole approach is broken by design...
as if you have a w*h movie where w%16!=0 or h%16!=0, and you want to show it
using -vop expand (or -vo dga etc) then you'll see the pixels outside of
the intended display area (w*h) too... which may be ugly.
but fortunatelly movies with w%16!=0 or h%16!=0 are rare...
and we still can -vop crop first... (i mean -vop expand=anysize,crop)


A'rpi / Astral & ESP-team

--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu