[FFmpeg-devel] [PATCH][VAAPI][2/6] Add common data structures and helpers
Gwenole Beauchesne
gbeauchesne
Thu Feb 26 17:43:57 CET 2009
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 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. ;-)
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.
More information about the ffmpeg-devel
mailing list