[MPlayer-dev-eng] [PATCH] Implement stride support in ve_raw and vf_vo wrapper

[Ivan Kalvachev]

2005/12/13, John Koleszar <jkoleszar at on2.com>:
> Here's a better patch to fix the pitch issues I'm seeing with the raw
> encoder and SDL vo. If an image with stride is passed to the put_image
> function, it is packed into a temporary buffer and used from there.
> These patches are independent of one another, but I'm submitting them in
> one thread because any comments made will likely apply to both.
>
> A little more detail on the vo issue, since that hasn't been discussed:
> (Note that this is as I understand it, so if I'm wrong, please correct
> me) Libvo has a legacy interface draw_frame that takes a packed (RGB
> only?) buffer as input. There are no parameters to describe the buffer's
> pitch. When vf_vo's put_image function gets called, it first tries the
> new interface that operates directly on mpi's. If that fails, it falls
> back to this legacy interface. If the buffer in the input image has a
> pitch different from what the vo expects, it will obviously not display
> correctly. This patch recognizes these situations and copies the image
> to a temporary buffer, removing any extra strides. This applies to any
> vo that still uses this interface, notably SDL, which uses it for RGB.
> To observe this behavior, use -vo sdl and a codec or filter that outputs
> in RGB. The mobile clip I've linked to in other postings is one example.
>
> One specific issue that should be looked at by someone who understands
> the vo layer better than I do is the condition in vf_vo selecting
> between the draw_slice and draw_frame interfaces. VFCAP_ACCEPT_STRIDE is
> no longer a sufficient check because both interfaces now support
> strides, but I'm not sure MP_IMGFLAG_PLANAR is correct either. Note that
> the original change between the two happened in rev 1.19.
>
> John

>From the patch it looks like you get everything right.

I had some doubts about using the video system to allocate the
temporal buffer, but on second thought I guess it is OK.

However I wodner if it is really necessery to pack and copy the whole
image and the output it at once? Maybe the muxer expects to get full
frames/packets?
If it not (and that's a big if) then you could output one line per
write and same yourself a lot of troubles and gain some speed.