New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 751870 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Oct 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Feature

Blocking:
issue 753565
issue 769391



Sign in to add a comment

Implement software encoder fallback for WebrtcVideoEncoderGpu

Project Member Reported by gusss@google.com, Aug 2 2017

Issue description

Apparently, according to emircan@, VideoEncodeAccelerator implementations can crash somewhat frequently (which is partly why Chrome Media chooses to run them in gpu processes which can be easily restarted, I think). The base implementation of WebrtcVideoEncoderGpu does not handle hardware encoder crashes. There should exist a software fallback that can be switched to on-the-fly while the hardware encoder is coming back up (though note that software h264 will require licensing). Alternatively, simply handle the error and delay while the hardware encoder comes back up.
 
Blocking: 753565
Owner: ----
Status: Available (was: Untriaged)
Blocking: 769391
Owner: zijiehe@chromium.org
Status: Fixed (was: Available)
I have not observed the crashes on my Windows 10 machine. I have not verified it on Windows 7, Linux, Mac OSX, Chrome OS.

The fallback logic has been implemented, but VEA is still running in the same remoting_host process.

For on-the-fly switch, instead of implementing a software H264 encoder, which requires licensing, falling back to VP8 would be a safer choice. But currently host does not support restaring the video stream on-the-fly at all.

Sign in to add a comment