Driver-dependent media capabilities

A usable media capability depends on the hardware and the driver/runtime/application path that exposes a particular operation and picture configuration.

Hardware can implement a media operation while a particular software path does not expose or use its complete configuration. The driver/runtime and application integration connect physical capability to a usable session.

This makes a capability claim more specific than “the GPU supports HEVC.”

Identify the layers in the claim

Evidence Scope
Manufacturer hardware table Listed product’s stated hardware capability
Driver feature table Operation exposed by that implementation/build
Native API query Selected device/context and requested configuration
Application build Interfaces and features integrated by the program
Initialized session Configuration the actual runtime accepted
Observed result Output/progress through the selected route

A failure at one layer should be related to that layer rather than silently replacing every other result.

A backend-build example is visible in the source

Intel's pinned Media Driver table separates Full-Feature and Free-Kernel rows. Its TGLx AV1 ten-bit entry supplies D in Full-Feature while leaving the Free-Kernel declaration blank. DG2/ATSM likewise has differing AV1 direction declarations between those builds.

That is a concrete implementation distinction. It can coexist with a hardware reference listing AV1 capability for the relevant product.

The application must use the actual installed backend and exposed operation. Copying another build's feature list does not create that operation.

Interfaces require compatible versions and resource contracts

A new codec/profile feature can require interface definitions, runtime support and application integration. A newer physical engine alone does not make an older wrapper supply those structures.

Surface formats and interoperable resource paths can change as well. The usable decoder and its next consumer need a matching accepted picture relationship.

This is particularly relevant to new chroma/bit-depth paths and explicitly queried video operations such as Vulkan Video.

A process comparison preserves selection

An original example has an interactive tool selecting adapter A and a full-feature backend, while the server process selects adapter B or another backend path.

Their different profile results describe different contexts. Both reports can be accurate for their own selection.

Library search, environment, device access and process identity are also part of the route. Those facts should be established before concluding that a supported stream became corrupt.

See Also

References