This page is documenting a work in progress feature do not assume it is available on the mainline branch.

You may find it developed on a topic branch

Rationale

Our current Hardware Acceleration support is lacking and unwieldy:

The following proposal aims at providing a simpler access to hardware acceleration, a more regular interface and provide "under the hood" access ONLY when needed.

API Design

The new api tries to stay fully compatible with the previous one while moving in Libav the boilerplate code needed to setup the global context and render the opaque frames back to memory.

Simplified usage

Some users do not have the need to use opaque AVFrames and render/scale/deinterlace on screen. In that case setting the codec AVOption hwaccel to the specific method and hwaccel-device to the specific device is all that's needed:

Uniformity

Utility functions

There is no need to provide custom callbacks nor initialize by hand the backend-specific context, yet is possible to override the defaults after avcodec_open2.

AVScale will be able manipulate directly opaque AVFrames using hw accelerated scaling/conversion if available.

// allocate an empty hwaccel context
c->hwctx = avhwaccel_alloc();

// common options
av_opt_set(c->hwctx, "hwaccel", "mfx", 0);
av_opt_set(c->hwctx, "hwaccel-device", "/dev/drm/card0", 0);
av_opt_set_int(c->hwctx, "hwaccel-render", 1, 0); // If left as 0 the AVFrame will use a specific custom pixel format

//  initialize the hwaccel global context using the options stored in hwctx and the codec parameters
if (avcodec_open2(c, codec, opts) < 0) 
...

Functions in detail

TBD

Workflows

CPU memory rendering

GPU buffer handover

Device handover

Architecture Design

Structure

Internal helpers

AVScale Interaction

AVScale should able to accept opaque frames and render them to system memory leveraging the hardware accelerated scalers if present.

This way the frame could ideally not move from the video memory at all.


CategoryBlueprint CategoryBlueprintActive