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

Michael Niedermayer michaelni
Fri Feb 27 14:53:04 CET 2009

On Fri, Feb 27, 2009 at 02:31:56PM +0100, Gwenole Beauchesne wrote:
> 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)

this is a "if its cleaner" thing, that is if its cleaner otherwise there
is no point

> 2. We don't want the user app to allocate that struct itself (wish?)

i dont really care either way

> 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.


8. Avoid making our public interface depend on VA/VDPAU
   that is in order of preferance
   * use ISO C types & structs or types and structs defined by avcodec.h
   * use void * or pointers to structs and make sure alloc/free/access is
     limited to either codec OR player
   * use void * or pointers to structs and clearly document the API/ABI
     implications if they change

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090227/d2e662c1/attachment.pgp>

More information about the ffmpeg-devel mailing list