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

[D Richard Felker III]

On Mon, Dec 30, 2002 at 12:45:04AM +0100, Arpi wrote:
> 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)

How about a special MPI flag informing filters that some extra junk
will be written? Then expand could just black-out a few pixels every
frame and everything would be fine, AND still fast.

Rich