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

[Rich Felker]

On Mon, Jan 02, 2006 at 08:55:49PM +0200, Ivan Kalvachev wrote:
> 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.

The muxer needs full frames. This could in principle be avoided if you
told the muxer the size of the frame to begin with, and then submitted
it in pieces, but I'm not sure if it's worth it. The only case where
you would ever submit in pieces is raw rgb/yuv, and this is a very
stupid format to use.. :)

Rich