[FFmpeg-devel] [PATCH][VAAPI][2/6] Add common data structures and helpers
Gwenole Beauchesne
gbeauchesne
Thu Feb 26 18:02:06 CET 2009
On Thu, 26 Feb 2009, Michael Niedermayer wrote:
>>>>>> 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
No problem to use int/void *, I already did the changes locally. ;-)
>> 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
Depends on which. ;-) I still don't know a clean means to do so from
MPlayer since it's dealing with mp_image_t which has no AVFrame in it.
More information about the ffmpeg-devel
mailing list