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

[Gwenole Beauchesne]

Le 26 f?vr. 09 ? 22:47, Michael Niedermayer a ?crit :

>>>>> Why not use an hwaccel_data member for it? Though, in that case,  
>>>>> data[0]
>>>>> shall not be NULL for correct operation of h264.
>>>>
>>>> iam ok with that.
>>>
>>> The problem is then what to fill in data[0]. It cannot be NULL, it  
>>> cannot
>>> be "constant" (for all allocs) either. If the HW accelerator  
>>> cannot handle
>>> surface pixels readback, this shall be valid. If it does support  
>>> that, it
>>> would have allocated data[0-2] accordingly and those allocations  
>>> naturally
>>> yield different pointers, so no problem in that case.
>>>
>>> I see two solutions:
>>>
>>> - Make data[0] a linearly increasing ID just to make sure any  
>>> allocated
>>> AVFrame::data[0] is different
>>>
>>> - Replace: h->default_ref_list[0][i].data[0] ==
>>> h->default_ref_list[1][i].data[0] with some ff_compare_picture()  
>>> which
>>> handles hwaccel_data. However, this could be a frequent function  
>>> call. So,
>>> make it static inline in mpegvideo_common.h?
>>
>> 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;

BTW, the previous model also had the advantage to retain hwaccel_data  
structs longer. Now we need to new/free the struct much more often. A  
lazy allocation model of this struct would require extension to  
AVHWAccel, e.g. an ::exit() function as initially suggested to release  
the pool at the very end.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ffmpeg.hwaccel.data.patch
Type: application/octet-stream
Size: 3529 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090227/731f4d93/attachment.obj>
-------------- next part --------------