[FFmpeg-devel] [PATCH][VAAPI][2/6] Add common data structures and helpers
Fri Feb 27 14:31:56 CET 2009
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 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
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
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.
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
<shakers activated, let's see what gets out of the box :)>
More information about the ffmpeg-devel