H264 constrained profile levels are not HW accelerated
Reported by
andreas....@gmail.com,
Jul 10
|
|||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0 Steps to reproduce the problem: 1. Use a test machine which provides full hardware decoding capabilities for H264 up to level id 420031. 2. Connect to a WebRTC peer which offers only a single h264 profile: a=rtpmap:98 H264/90000 a=fmtp:98 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42E01F 1. Start video playback What is the expected behavior? Video decoding is done on the GPU, as 42E01F is a subset of the (less restrictive) profile level 420031. 0x42 = baseline 0xEF / 0x00 = constraint bits, less restrictive if not set 0x1F / 0x31 = macroblock limit What went wrong? Decoding is performed in software instead. When disabling software decoding, error can be narrowed down to failed mapping. Profile level 420031 is not recognized as a legal super set of 42E01F. Did this work before? No Does this work in other browsers? N/A Chrome version: 67.0.3396.99 (Official Build) (64-bit) (cohort: Stable) Channel: stable OS Version: 10.0 Flash Version:
,
Jul 11
andreas.ringlstetter@ Thanks for the issue. Request you to provide a sample site/URL where this issue can be reproduced which will help in further triaging of the issue. Also request you to provide a screen cast of the steps followed which will help in better understanding of the issue. Thanks..
,
Jul 11
Providing a publicly available sample would be difficult, as it's a CCTV RTSP IP camera peered via Meetecho Janus. It provides a single H264 stream with (non-negotiable) profile level id 428031 (which Chrome fails to match at all, despite being a subset of 420031), so Janus rewrites this either to 420031 or 42E01F (illegal conversion, but e.g. necessary for Firefox), depending on which level IDs the corresponding peer is accepting at all. Set chrome://flags/#enable-webrtc-h264-with-openh264-ffmpeg to Disabled to turn failed HW acceleration into a fatal error. You may just peer Chrome (on Windows) and Firefox via https://appr.tc/r/085966435?vsibr=10000&vrc=H264&vsc=H264&audio=false&hd=true With the only common level being 42E01F (untested, don't have a second video source available), this should also results in Chrome failing to use HW acceleration for decoding.
,
Jul 11
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 12
,
Jul 13
magjed@ can you triage further?
,
Jul 20
As per comment#3 seems it isn't possible to provide the requested sample file publicly, hence adding label "TE-NeedsTriageHelp" and requesting someone from respective team to have a look into this and help in further triaging it. Thanks!
,
Aug 20
,
Dec 1
I can replicate the issue on Huawei Honor 8 (Kirin 959) and there is no software rendering fallback.
,
Dec 4
SDP negotiation is sendrecv, so both encoder and decoder need to have the same profile level id. In order to make things simpler in WebRTC and avoid too much thorny codec specific logic, the design in WebRTC is like this: Both the encoder and decoder should list all the H264 profiles they support. This means that it's not enough for the decoder in this case to list 420031, it also needs to list a constrained baseline profile such as 42E031. Hope this helps.
,
Dec 4
|
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by susan.boorgula@chromium.org
, Jul 10