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

[Gwenole Beauchesne]

On Fri, 27 Feb 2009, Michael Niedermayer wrote:

>> You can see that vaapi_render_state_private as vdpau_render_state.
>> Currently, the application allocates those. But Michael wanted lavc to
>> handle that itself, so I was only suggesting patches to achieve this. Since
>> this yields mess, in your opinion, it's probably not a good idea then. i.e.
>> let's just stick to the current approach: have the application allocate the
>> *_render_state structs.
>
> I dont remember suggesting this...
> what i suggested IIRC was that the struct could be stored in a struct not in
> data that is uint8_t []

Yes, but you didn't want my av_alloc_vaapi_render_state() either, so what 
could I do? If I examine all the constraints, I have a satisfactory 
problem so one should be spilled. :)

I don't mind assigning this struct to an mpi->planes[3] or whatever which 
will be fed back to an hwaccel_data member, but this means the application 
has to allocate it somehow, thus the former helper.

Or am I missing a something?

Let me summarize to check I understand all of your constraints (Reimar's 
included):

1. We want *_render_state structs be stored in a specific AVFrame member, 
not hijack some data[i] (mandatory)
2. We don't want the user app to allocate that struct itself (wish?)
3.1. We want the application be able to access the render state struct at 
::get_image() location / or
3.2. find another means to make it initialize the struct with 
app-provided data (va_context/surface in VA API case, surface in VDPAU 
case
4. We can't initialize an extra mp_image_t::hwaccel_data because the image 
allocation is well hidden under the mpcodecs_get_image() chain (vf->vo), 
which loses AVFrame at the same time (that's normal).
5. AVHWAccel::start_frame()/decode_slice() can only allocate data that is 
live until the ::end_frame()
6. ff_draw_horiz_band() does not necessarily send the surface that was 
just rendered at ::end_frame() time
7. vaapi_render_state struct needs private data user doesn't care about 
and doesn't have to access.
7.1 this data can't be allocated in start_frame() because of 5 and 6.
7.2 lazy allocation of the struct is desired to avoid many alloc/free
7.3 if private data is disassociated from original public data, we need a 
location to bind this private data to the public struct priv member.

Doing 7.3 could be particularly ugly IMO, because we would be allocating 
the private data before ::get_buffer() and, after this call, we then 
have to bind it to some returning data[3].

That's why, IMO, while we are at allocating the private struct, why not 
allocate the public one at the same time? This avoids the binding step 
after ::get_buffer() but it turns out it's difficult without other changes 
to MPlayer.

<shakers activated, let's see what gets out of the box :)>