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

Gwenole Beauchesne gbeauchesne
Fri Oct 29 14:52:41 CEST 2010


Hi,

Here is a new patch that applies to current SVN tree with some further 
cosmetics (comments) added.

Regards,
Gwenole.

On Mon, 20 Sep 2010, Gwenole Beauchesne wrote:

> It seems I didn't reply to this one or the message got lost because I had a 
> v5 lying around for some time. Here is a v6 anyway, that intersects with the 
> tidsp needs.
>
> On Mon, 22 Feb 2010, Michael Niedermayer wrote:
>
>> On Mon, Jan 04, 2010 at 04:39:02PM +0100, Gwenole Beauchesne wrote:
>>> Hi,
>>> 
>>> On Mon, 4 Jan 2010, Michael Niedermayer wrote:
>>> 
>>>>> 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
>>> 
>>> OK, I nuked the hwaccel attrs and replaced it with
>>> AVCodecContext.hwaccel_{id,flags}. hwaccel_flags is handled by AVOption. I
>>> left hwaccel_id as is to match existing practise (pix_fmt et al.).
>>> 
>>> I haven't tested with MPlayer yet but this new approach still works with 
>>> my
>>> modified ffplay.
>>> 
>>> So, HW accelerator selection works as is:
>>> - Set AVCodecContext.hwaccel_id to the desired accelerator
>>> - Set AVCodecContext.hwaccel_flags to HWACCEL_CAP_GET_PIXELS if the user
>>> wants AVFrame.data[0-2] populated with YV12 or NV12 pixels
>>> 
>>> This means we can handle multiple accelerators automatically at once.
>>> Anyway, this lived in an ideal world without practical use since the
>>> user-application would still have to handle the HW accelerator
>>> specifically.
>>> 
>>> Regards,
>>> Gwenole.
>> 
>> ]...]
>>> @@ -2497,7 +2498,7 @@ typedef struct AVCodecContext {
>>>       * provided by the user. In that case, this holds display-dependent
>>>       * data FFmpeg cannot instantiate itself. Please refer to the
>>>       * FFmpeg HW accelerator documentation to know how to fill this
>>> -     * is. e.g. for VA API, this is a struct vaapi_context.
>>> +     * is. e.g. for VA API, this is a VADisplay.
>>>       * - encoding: unused
>>>       * - decoding: Set by user
>>>       */
>> 
>> hunk ok probably
>> 
>> [...]
>>> +    /**
>>> +     * Called in codec initialization.
>>> +     *
>>> +     * This is used to initialize the AVCodecContext.hwaccel_context
>>> +     * hardware accelerator context.
>>> +     *
>>> +     * @param avctx the codec context
>>> +     * @return zero if successful, a negative value otherwise
>>> +     */
>>> +    int (*init)(AVCodecContext *avctx);
>>> +
>>> +    /**
>>> +     * Called in codec finalization.
>>> +     *
>>> +     * This is used to clean-up any data from the hardware accelerator
>>> +     * context. Should this function be implemented, it shall reset
>>> +     * AVCodecContext.hwaccel_context to NULL.
>>> +     *
>>> +     * @param avctx the codec context
>>> +     * @return zero if successful, a negative value otherwise
>>> +     */
>>> +    int (*close)(AVCodecContext *avctx);
>>> +
>>> +    /**
>>> +     * Called at the beginning of each frame to allocate a HW surface.
>>> +     *
>>> +     * The returned surface will be stored in Picture.data[3].
>>> +     *
>>> +     * @param avctx the codec context
>>> +     * @param surface the pointer to the HW accelerator surface
>>> +     * @return zero if successful, a negative value otherwise
>>> +     */
>>> +    int (*alloc_surface)(AVCodecContext *avctx, uint8_t **surface);
>>> +
>>> +    /**
>>> +     * Called to free the HW surface that was allocated with 
>>> alloc_surface().
>>> +     *
>>> +     * @param avctx the codec context
>>> +     * @param surface the HW accelerator surface
>>> +     * @return zero if successful, a negative value otherwise
>>> +     */
>>> +    void (*free_surface)(AVCodecContext *avctx, uint8_t *surface);
>>>  } AVHWAccel;
>> 
>> iam not in favor of these. What are these good for?
>> Why are they needed?
>
> This is used to allocate the HW surfaces (VdpSurface, VASurface, etc.) from 
> within FFmpeg. i.e. the AVFrame.data[3] part, hence the uint8_t * instead of 
> the void *.

Those functions are also used to help user implement 
AVCodecContext.get_buffer() and release_buffer() if he wants to do so 
manually.

e.g. by default, AVCodecContext.get_buffer() will point to 
avcodec_default_get_buffer(). If a user overrides that function, he will 
lose automatic data[3] handling. So, two possible cases:
1) He really knows how to do so, so he allocates the HW surface himself
2) He can delegate that to FFmpeg that will know how to do that just fine 
too. e.g. calling the right vaCreateSurfaces(), VdpVideoSurfaceCreate(), 
etc.

>>> +/** Identifies the hardware accelerator */
>>> +enum HWAccelID {
>>> +    HWACCEL_ID_NONE,
>>> +    HWACCEL_ID_VAAPI,           ///< Video Acceleration (VA) API
>>> +    HWACCEL_ID_NB
>>> +};
>> 
>> this needs a any or auto for autodetection (which should be 0)
>
> I finally forgot about autodetection because it's too complex to handle at 
> the FFmpeg level and delegated that to the player level. In particular, 
> HWAccel context may depend on upper level info, like an X display...
>
>>> +
>>> +/** Identifies the hardware accelerator entry-point */
>>> +enum HWAccelEntrypoint {
>>> +    HWACCEL_ENTRYPOINT_VLD = 1, ///< Variable-length decoding
>>> +    HWACCEL_ENTRYPOINT_IDCT,    ///< Inverse discrete cosine transform
>>> +    HWACCEL_ENTRYPOINT_MOCO,    ///< Motion compensation
>>> +    HWACCEL_ENTRYPOINT_NB
>>> +};
>> 
>> as said previously this is ambigous
>> 
>> HWACCEL_ENTRYPOINT_VLD could mean the hw does just VLD and leaves IDCT/MC
>> to software
>
> Actually, I didn't find the exact meaning. But from a pipeline point of view, 
> this would mean XXX and above. i.e. VLD and above, motion compensation and 
> above. Flagging those would lead to more player work (well, just OR'ing more 
> flags).
>
> I tried to express that in the comment.
>
>>> +/**
>>> + * The hardware accelerator can fetch the pixels from the decoded
>>> + * frames. If the user requested it, avcodec_default_get_buffer()
>>> + * will then allocate the data buffers.
>>> + */
>>> +#define HWACCEL_CAP_GET_PIXELS 0x00000001
>> 
>> might need a AV prefix
>
> OK.

Regards,
Gwenole.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ffmpeg.hwaccel.v2.8.patch
Type: text/x-diff
Size: 11629 bytes
Desc: 
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20101029/26a02e42/attachment.patch>



More information about the ffmpeg-devel mailing list