[FFmpeg-devel] [PATCH] AVHWAccel infrastructure v2 (take 3)

Michael Niedermayer michaelni
Mon Jan 4 15:11:08 CET 2010


On Mon, Jan 04, 2010 at 02:09:51PM +0100, Gwenole Beauchesne wrote:
> Hi,
>
> On Sun, 15 Nov 2009, Michael Niedermayer wrote:
>
>> On Fri, Nov 13, 2009 at 04:50:11PM +0100, Gwenole Beauchesne wrote:
>>> On Mon, 9 Nov 2009, Michael Niedermayer wrote:
>>>
>>>> [...]
>>>>> @@ -2526,6 +2527,14 @@ typedef struct AVCodecContext {
>>>>>       * - decoding: Set by libavcodec
>>>>>       */
>>>>>       enum AVChromaLocation chroma_sample_location;
>>>>> +
>>>>> +    /**
>>>>> +     * Hardware accelerator configuration attributes.
>>>>> +     * The array is terminated by HWACCEL_ATTR_NONE.
>>>>> +     * - encoding: unused
>>>>> +     * - decoding: Set by user
>>>>> +     */
>>>>> +    const uintptr_t *hwaccel_attrs;
>>>>>  } AVCodecContext;
>>>>>
>>>>>  /**
>>>>
>>>> uintptr_t is an optional type in C
>>>> and i really have a bad feeling about using it in public API, i bet this
>>>> will break several compilers
>>>>
>>>> and this way of passing information/attributes is very odd and there is
>>>> no support in AVOptions to deal with that
>>>> so i really think a int someflags would be better
>>>
>>> Do you mean I should use AVOptions directly + add an FF_OPT_TYPE_POINTER?
>>> The problem is I don't see any codec using av_get_*() so I don't think 
>>> that
>>> was what you meant or is there another API to access AVOptions?
>>
>>
>> i mean
>>
>> +   int my_flags;
>> } AVCodecContext;
>
> In the new model I wanted to use, hwaccel_context was to be solely 
> maintained by libavcodec. However, it still needed a way to get some 
> hwaccel context initialized by the user-application. e.g. a VADisplay (void 
> *), an LPDIRECTXVIDEODECODER, etc.
>
> I felt interesting to pass this information through hwaccel attrs along 
> with other int attributes.

We have existing means to pass information, that is through AVCodecContext
and using AVOption where appropriate
As well as using AVFrame instead of AVCodecContext where its per frame
data

I really dont want every developer to invent a new way to pass his data
It would be an unimagineable complex mess to work with


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.
-------------- 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/20100104/bc986747/attachment.pgp>



More information about the ffmpeg-devel mailing list