[MPlayer-dev-eng] [PATCH] Implement stride support in ve_raw and vf_vo wrapper
John Koleszar
jkoleszar at on2.com
Tue Jan 3 23:18:16 CET 2006
Ivan Kalvachev wrote:
>>From the patch it looks like you get everything right.
>
>
After more testing, it looks like I didn't. :-(
>I had some doubts about using the video system to allocate the
>temporal buffer, but on second thought I guess it is OK.
>
This doesn't actually work in all cases. The model for calling
vf_get_image is that you get get destination images by using vf->next,
which I gather is how DR works. Since the ve's and vo's are at the end
of the chain, there is no next filter. Since the decoder (or other
filters) render into the ve's context, the ve can't allocate an image in
it's own context.
This problem manifests itself when a filter or decoder requests a temp
image either via MP_IMGTYPE_TEMP or MP_IMGTYPE_IPB. In this case the mpi
passed to the ve's put_image is the same instance as the temp mpi that
was allocated at init time, which obviously doesn't work. One decoder
that does this is SVQ3 as seen in the clip below:
ftp://opensource:opensource@ftp.on2.com/Narnia_LWR_Trailer1_87d2_3000.mov
Sorry for the large size, I tried to mux a clip of it into an avi to
make it a little smaller, but mplayer segv'd when trying to play it back.
So the question becomes how to best allocate the temp buffer. I could
just memalign it and calculate the dimensions and strides, but it seems
like that duplicates an awful lot of the mpi interface. Based on the
number of formats this is supposed to support, I think it makes sense to
stick with the mpi. My current workaround is a hack that copies about 35
lines from vf_get_image to set up the mpi, but I don't think this is a
good general solution, since that's a big chunk of code to duplicate in
three places (vf_get_image, ve_raw, vf_vo). Would people here be
amenable to moving the common code to a new function for this and using
it in those three places? Or at least the ve and vo? Just need a little
guidance on how to proceed.
To see the issue with the ve:
$ mencoder -nosound -ovc raw -frames 240 -o test.avi
Narnia_LWR_Trailer1_87d2_3000.mov
To see the issue with the vo:
$ mplayer -vf format=bgra -vo sdl Narnia_LWR_Trailer1_87d2_3000.mov
(need to use a rgb format to get into the draw_frame code path. This one
isn't as big a deal as the one above, since it's only one plane, but you
can see that the dimensions are wrong)
Cheers,
John
More information about the MPlayer-dev-eng
mailing list