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

[Michael Niedermayer]

On Thu, Feb 26, 2009 at 05:43:57PM +0100, Gwenole Beauchesne wrote:
> On Thu, 26 Feb 2009, Michael Niedermayer wrote:
> 
> > On Thu, Feb 26, 2009 at 03:51:04PM +0100, Gwenole Beauchesne wrote:
> >> On Thu, 26 Feb 2009, Michael Niedermayer wrote:
> >>
> >>> On Thu, Feb 26, 2009 at 02:20:34PM +0100, Gwenole Beauchesne wrote:
> >>>> On Thu, 26 Feb 2009, Michael Niedermayer wrote:
> >>>>
> >>>>> i think the struct placed in data[0] should be designed so that it does not
> >>>>> need any vaapi headers, that is contain pointers to structs instead of
> >>>>> vaapi structs.
> >>>>> then this "data[0] struct" can just be placed in avcodec.h and vaapi.h wont
> >>>>> be needed.
> >>>>
> >>>> It's hard because VADisplay, VAConfigID, VAContextID, VASurfaceID are not
> >>>> structs but either void * (VADisplay) or unsigned int (VA*ID). I think
> >>>
> >>> neither void * nor unsigned int would need a #include va.h
> >>
> >> Though they are primitive types, a change in the VA API definitions would
> >> mess the things up if we want to maintain several versions of the API.
> >> Highly unlikely, but it's a case that might happen.
> >
> > ok but why do we need to use them in the public interface between lavc and
> > the player?
> 
> The player must fill them, since that's display dependant data.

i still dont see the problem with just using int/void *
yes it might change on a API bump but if it does VADisplay / VAConfigID
wont help you, this will break fatally if lavc & the players differ.
alao distribution package maintainers will hate VAAPI if these ever change



> 
> >> I see two solutions:
> >>
> >> - Make data[0] a linearly increasing ID just to make sure any allocated
> >> AVFrame::data[0] is different
> >
> > what about p->data[0] = p->hwaccel_data ?
> 
> Yes, that's what VOs currently do. ;-)

not completely ;)
there is no p->hwaccel_data currently
and it would be nicer to access things ...


> 
> But, I'd also like to handle cases where the user requests pixels readback 
> and those should lay in data[0-2] as ususal. And having data[0] be either 
> hwaccel_data or real pixels could be quite confusing.

well if you just document it as "some non null pointer" then 
hwaccel_data or real pixels should be no problem
the player can access hwaccel_data through p->hwaccel_data

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin
-------------- 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/20090226/70eaa73a/attachment.pgp>