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

[Michael Niedermayer]

On Fri, Feb 27, 2009 at 03:41:07PM +0100, Gwenole Beauchesne wrote:
> On Fri, 27 Feb 2009, Michael Niedermayer wrote:
> 
> >> 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
> 
> IMO, the simplest approach (requiring less code) is indeed that one: let 
> the user allocate *_render_state struct and pass it back to lavc through 
> .data[3] (or .data[0] if YV12 pixels are not needed) + if *_render_state 
> struct needs private data, let it be an extension to the public struct.
> 
> Really, this is the simplest approach. I tried others (amend AVFrame with 
> hwaccel data, split public/private, etc.) and it turned out the extra code 
> (both in lavc internal and in player) is no gain.
> 
> > [...]
> >> 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.
> >
> > AVFrame/AVPicture.hwaccel_codec_private
> 
> Why not but in case we push the public struct to AVFrame too, wouldn't 
> that become too crownded?
> e.g.
> .hwaccel_data for the public struct
> .hwaccel_privdata for the private struct, if any
> 
> Besides, if we separate both, this becomes somewhat unconvienent from an 
> HW accel codec implementation point of view. I mean, dealing with only one 
> struct at a time is very convenient (one function arg, single init from a 
> Picture, etc.). Splitting them would require to manage both, or link one 
> to the other, somewhere.

they are linked in an AVFrame/AVPicture, is there a problem with passing
AVFrame/AVPicture around instead of both structs?


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates
-------------- 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/7309bec9/attachment.pgp>