Distinguish intent from execution
An application can prefer hardware processing yet fall back, reject a configuration or use another path according to its implementation. The setting name expresses a policy, not a performed measurement.
The current WebCodecs draft explicitly describes hardware-acceleration preferences as hints. Android separately exposes detailed codec capabilities. These are platform examples, not a universal account of every player's internal behaviour.
Record the exact configuration
Identify codec, profile, dimensions, frame rate and bit depth where known. A working sample in one profile does not establish hardware support for another. Include the app and device versions when asking the developer about a path.
Avoid inferring the decoder from the device's resolution badge, smooth-looking menus or the mere presence of a hardware option.
Use a controlled player comparison
If the player documents a relevant preference, record its original value and compare the same permitted sample. Watch picture, sound and stability. Revert an unhelpful change. Do not force an unsupported setting based on a screenshot from another application.
A performance difference is useful evidence but may not uniquely identify the decoder. Reliable diagnostic output or developer confirmation is stronger than guessing from processor activity alone.
Keep power and smoothness separate
A path can play successfully while using more power or dropping frames under particular conditions. The W3C Media Capabilities draft distinguishes support, smoothness and power efficiency. None is automatically established by the other two.
Do not turn one brief demonstration into a sustained benchmark. Record its duration and ordinary operating conditions when a real test is performed.
Ask the developer the narrow question
Provide the reference configuration and ask which decoder is selected and what fallback is expected. A source-specific failure may require an app fix rather than a new subscription or cable.
This article describes documented capability concepts and a proposed comparison. It does not inspect any player implementation, run a hardware benchmark or certify an IPTV Canada combination.
Keep fallback visible in a report
If a player exposes reliable decoder information, retain its exact field name and value rather than translating it into a broad hardware-supported claim. A fallback that works can be a useful compatibility result with a different power or performance profile. Ask the developer what the diagnostic means for that app build before comparing labels from unrelated players.
Sources and scope
Scope notes distinguish published documentation, supplied information and editorial methods. They do not report a hands-on service test.
- W3C WebCodecs draft — Official current draft excerpt: hardware acceleration preference is a hint; no inference of application support or rights bypass.
- Android codec capabilities — Official current API documentation excerpt: profile/level and format capability queries; developer mechanism, not a consumer menu or completed device test.
- W3C Media Capabilities working draft, October 2026 — Official current versioned draft excerpt: configuration-specific supported, smooth and power-efficient results. Not a delivered browser-support matrix or real playback test.
