[MPlayer-dev-eng] [RFC] Stride support in ve_raw/libvo draw_image interface

[John Koleszar]

Reposting this issue since it seems to have slipped through the cracks.
I'm a little rusty on the details as it's been so long, so please bear
with me.

There are two places I've found where vf's require packed images but can
be passed images with larger strides. This typically happens when
playing material that has a width that isn't a multiple of 16 (or 8? I
forget.)

1. ve_raw writes packed images to the muxer. These images must be
packed, as the stride and offset information isn't stored in any
container mencoder supports.

2. libvo's legacy draw_image interface requires a buffer to a packed RGB
image, as the stride information isn't passed into the vo.

The attached patch is a workaround for the ve_raw case. I allocate a
buffer, then copy the image into that buffer if it isn't packed. There
are some comments in the patch about why I allocate my own buffer
instead of using the vf_get_image interface. I haven't maintained a
patch fixing the vf_vo issue, I use a better vo now. The conditions that
triggered it were very obscure (QT RLE material | mplayer -vo sdl | ssh
-X | xfree86/Cygwin). Don't ask about the performance :) When I did
maintain that fix, it was similar - use a temp buffer, copy the image if
necessary.

There exists a flag VFCAP_ACCEPT_STRIDE that indicates whether a vf
requires a packed buffer or not. ve_raw does not set this flag. In the
draw_image case I found, VFCAP_ACCEPT_STRIDE was not set. The vf layer
(the common vf_get_image code, most likely) ignores this flag. I still
think that the problem should be fixed for all vf's and the
VFCAP_ACCEPT_STRIDE should be honored, but that idea was rejected last
time, so I won't push it.

I don't think the patch in this form is suitable to apply due the the
large amount of code duplicated from vf_get_image. If it is agreed that
this is the right fix in principle, I can post another patch moving the
code that's common to a new function.

Encoding any oddly sized material with -ovc raw should trigger the bug..
I can't remember how to trigger the vf_vo bug, but if you check the
archives for my last post related to this, I think I had instructions
there. A test clip I use is linked below (~30MB).
ftp://opensource:opensource@ftp.on2.com/mobile_378_203_rle.mov


-------------- next part --------------
A non-text attachment was scrubbed...
Name: ve_raw_stride_support.diff
Type: text/x-patch
Size: 5064 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20060411/3a3407e5/attachment.bin>