[FFmpeg-devel] [PATCH][VAAPI][2/6] Add common data structures and helpers
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 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)
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
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel