[MPlayer-dev-eng] [PATCH] changes in vf semantics

[Jindrich Makovicka]

D Richard Felker III wrote:
> This is nonsense. Yes it's true, but in this case direct rendering can
> just fail, no problem. The vo's "get_image" implementation can see
> the requested width/height, and if they don't match the configured
> ones, it can just refuse to do dr. The normal non-dr functions of the
> vo DO NOT CARE about stride/alignment crap for their source image.
> 
> Granted this is sub-optimal in terms of performance, but it only
> affects shitty files, and it's STILL much better than the current
> situation where these files cause sig11!! Also it's a minimal change
> so we can do something better later if we want.

Actually, we should be able to do DR even for these crappy files, as 
long as most of the filters support stride, because get_image can resize 
and reallocate the images as needed. The get_image code needs only to be 
fixed so it only increases the size - currently it can also decrease 
mpi->width and mpi->height, which is wrong. Also, all vf_*:get_image 
functions which assume aligned width should additionally check if the 
image obtained by vf_get_image has the necessary width, which it will 
certainly have, if the subsequent filters accept an arbitrary stride. If 
the width is insufficient, get_image should bail out and revert to 
indirect rendering.

Also, some vf's use mpi->width/height instead of mpi->w/h. Actually, 
width&height shouldn't be used outside of the scope of get_image. This 
should be fixed too.

-- 
Jindrich Makovicka