[MPlayer-dev-eng] [PATCH] raw filter (ve_raw.c) writing improper frame data
John Koleszar
jkoleszar at on2.com
Wed Nov 30 17:58:35 CET 2005
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
More information about the MPlayer-dev-eng
mailing list