[FFmpeg-devel] [PATCH][VAAPI][2/6] Add common data structures and helpers

[Gwenole Beauchesne]

On Fri, 27 Feb 2009, Gwenole Beauchesne wrote:

>>> Having lavc allocate *_render_state structs sounds good but in practise,
>>> that's not really the ideal solution for MPlayer. How a ::get_image()
>>> could retrieve that hwaccel_data member? MPI allocation is well hidden
>>> mpcodecs_get_image() and it completely doesn't mind about AVFrame.
>> 
>> you could use data[3] for the hwacell struct that would leave 0-2 for
>> YV12 pixels
>
> Not really in a clean way. :)
>
> In the previous model, a VO allocated what we now call the hwaccel_data 
> member, so it was enough for it to pass the resulting struct through data[0] 
> (or data[3]). Thus, data[] (planes[] actually, then copied) was seen as an 
> output arg. Now, we need it to be an in-out arg. i.e. set planes[3] prior to 
> invoking the ::get_image() function and after/inside mpcodecs_get_image() or 
> the vf->get_image(). I don't really see how to achieve it apart extending it 
> with an extra arg. This is not particularly clean as that extra arg is only 
> useful to vd_ffmpeg and not others.
>
> FWIW, I have attached the current lavc part. New AVHWAccel hooks may be 
> useful (get_buffer(), release_buffer()?).
> + after the avctx->get_buffer() call an 
> if(!(avctx->hwaccel->capabilities&FF_HWACCEL_CAP_PIXELS_READBACK)) 
> pic->data[0] = pic->hwaccel_data;

Here is the version without memory leaks. ;-)

I have also attached the MPlayer part, through a new control to bind an 
hwaccel_data to an mpi. WDYT? I am not very satisfied yet but the new 
control has the benefit to not change the original ::get_image() 
semantics, thus making it possible to really allocate YV12 pixels (or NV12 
pixels, generally).

I have checked that H.264 decoding still works, even for bitstreams that 
used to be displayed with unordered frames (that one was fixed without 
hacks by Reimar's numbered mpi for both VDPAU and VAAPI at once ;-)).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ffmpeg.hwaccel.data.2.patch
Type: text/x-diff
Size: 9139 bytes
Desc: 
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090227/ab167756/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mplayer.mpi.bind.hwaccel.data.patch
Type: text/x-diff
Size: 8748 bytes
Desc: 
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090227/ab167756/attachment-0001.patch>