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

[D Richard Felker III]

On Wed, Dec 01, 2004 at 12:00:17PM +0100, Jindrich Makovicka wrote:
> 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.

yes. after we commit the fix to vf core, it would be nice if you could
submit a patch fixing incorrect width/height use in filters. (i have a
feeling it's mostly my filters... :/ )

rich