ChromeOS NACL SDK issue: H264 HW encoding for NACL not working in V65 (was working fine in V64).
Reported by
elise...@elisescu.com,
Mar 29 2018
|
|||
Issue descriptionChrome Version : 65.0.3325.184 Steps to reproduce the problem: 1. Have a simple ChromeOS app which uses NACL SDK (Pebber 49) for calling video encoder APIs (#include "ppapi/cpp/video_encoder.h") 2. Probe the encoder to see the supported formats: pp::VideoEncoder::GetSupportedProfiles What is the expected result? H264 HW encoding is part of the supported profiles, returned by the API above, as it was in previous Public release of ChromeOS (V64). What happens instead? Only VP8 and VP9 are available in this ChromeOS version. Before updating the Chromebook to V65, the app was able to encode a video using h264 HW encoder (the ::GetSupportedProfiles API was returning H264 next to VP8 and VP9 as available codecs). The new Public release of Chromium (v65) seems to have broken the H264 HW acceleration which was available to ChromeOS Apps, built on top of NACL SDK. I have an application which is built on top of NACL SDK (Pepper 49), and which uses the the pp::VideoEncoder class to encode video using the h264 HW accelerated encoder. Before updating the Chromebook to V65, the method pp::VideoEncoder::GetSupportedProfiles was returning an array with supported codecs which was including H264, but now, after updating to V65, H264 is not there anymore (there's only VP8 and VP9). This is reproducible every time on a Lenovo 100s Chromebook (and potentially others as well - need to double check). If relevant, note that going to chrome://gpu in the browser, I can see h264 encoding being available for "Video Acceleration Information".
,
Apr 5 2018
,
Apr 10 2018
Any updates on this one? I can see it hasn't been triaged yet, but still it sounds like a big breaking change since the last public version. I should also mention that the problem can be reproduced with the NACL SDK sample for encoding, available in: `$NACL_SDK/pepper_49/examples/api/video_encode`. Serving the app with `make serve` (need to change the server to use https, for the capture to work), shows up the h264 codec on the previous ChromeOS release, but not in the latest one (where only VP8 and VP9 is available). I tried enabling more logging in `/etc/chrome_dev.conf/`, by adding: ``` NACLVEROSITY=3 !--log-level --log-level=5 --vmodule=*/media/*=4 --vmodule=*/ppapi/*=4 --vmodule ``` but without any success in finding something useful. I would be happy to assist with further details, in order do figure out what's wrong, so let me know if there's anything I should try out on my side.
,
Apr 10 2018
The situation is unfortunate: h264 encoding seemed to be relying on a broken feature -- usually Chrome doesn't offer "accelerated" encoding if there is no "software" encoding fallback. Moreover, no usage was reflected in the UMA (which is strange since CrOs users tend to opt in more often than not; even now its usage show solid 0s). I can think of some mitigations on our side, but they won't make it to the users until M67: one is wiring sw h264 encoding. (sw encoding is comparable to hw in efficiency in CrOs processors). elisescu@ On your side, you could use VP8/VP9 or just migrate to Media Recorder (which supports all platforms and Firefox as well): https://www.w3.org/TR/mediastream-recording/#example2 It might be heading for Safari soon as well: https://bugs.webkit.org/show_bug.cgi?id=85851#c6
,
Apr 10 2018
,
Apr 20 2018
Also seeing this in our app on all of our Chrome devices: Toshiba (Snow), Samsung (Swanky), Acer (Relm), Lenovo (Hana). We've switched to VP8 for now. |
|||
►
Sign in to add a comment |
|||
Comment 1 by viswa.karala@chromium.org
, Mar 29 2018