[FFmpeg-devel] [PATCH] Add hwaccel_data infrastructure
Wed Mar 4 00:33:29 CET 2009
On Tue, Mar 03, 2009 at 11:12:32PM +0100, Gwenole Beauchesne wrote:
> Le 3 mars 09 ? 22:37, Michael Niedermayer a ?crit :
> > On Tue, Mar 03, 2009 at 01:29:17PM +0100, Gwenole Beauchesne wrote:
> >> Hi,
> >> This patch implements the suggested hwaccel_data infrastructure.
> >> - hwaccel_data is allocated by the player and matches what we
> >> currently
> >> name vdpau_render_state or vaapi_render_state. The aim is to
> >> replace the
> >> use of AVCodecContext::data (reserved for YV12 pixels -- future
> >> use).
> > is there an advantage over using data ?
> I don't see any actually. In either case, data (or hwaccel_data)
> needs to be filled in with e.g. mpi->priv in the mplayer case for
> >> - hwaccel_data_private is optional (check
> >> AVHWAccel::priv_data_size) and
> >> allocated by FFmpeg. This private data has the lifetime of the
> >> decoded
> >> AVFrame. It's deallocated through the ::close() function. I don't
> >> really
> >> like the name. For VA API, I implemented it as
> >> ff_vaapi_destroy_picture().
> > this looks asymetric
> > alloc by av_mallocz()
> > close by callback
> > why?
> Because I suggested open/close and you said only when needed. :) So I
> assumed it was the wrong route since, currently, VA API only needs
> av_mallocz() at frame buffer creation and do extra work at frame
> buffer destruction.
can you explain what this extra work is?
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If you really think that XML is the answer, then you definitly missunderstood
the question -- Attila Kinali
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel