[MPlayer-dev-eng] [PATCH] raw filter (ve_raw.c) writing improper frame data

[John Koleszar]

Reimar Döffinger wrote:

>Both are wrong, they can be a big performance hit.
>The bug is in ve_raw, it ignores the mpi->stride values.
>Even worse, for yuv it assumes the planes are located on behind the
>other in memory which is an invalid assumption as well.
>  
>
I agree that ve_raw doesn't support stride values, and I know that that 
causes a performance hit. But it also doesn't claim to support these 
types of images - it doesn't set VFCAP_ACCEPT_STRIDE. So it seems to me 
that it's a bug that it's getting an image it doesn't claim to support. 
What's the point of this flag, if it's not to address this issue?

 From my original posting:

> Is the right way to fix this changing ve_raw.c to properly support images
> with variable strides (mp_image_t.width > mp_image_t.w) or is it a bug
> that these types of images are even being passed to this filter, since it
> doesn't advertise support (ie, it doesn't set VFCAP_ACCEPT_STRIDE).

Can you explain how the patch I suggested degrades performance? My 
intention was that all the filters in the chain get to render into 
aligned buffers if the next filter in the chain supports that as input. 
And that seems to be what happens in the simple case I was working on - 
the QT decoder outputs into an aligned image, the expand filter accepts 
that as input, and outputs to a packed image for the raw encoder. I 
agree that it'd be bad if having one filter in the chain that only 
accepted packed images caused all filters to work on packed images, but 
I don't think that's the case. I'll try with a few more filters in the 
chain to make sure this works right.

Also, wouldn't creating a new buffer in ve_raw actually hurt 
performance, since you're guaranteed to have to make a copy, whereas 
under the current scheme the previous filter can direct render into ve_raw?

John