Issue metadata
Sign in to add a comment
|
WebRTC H264 video sometimes gets stuck in a failing state where it can't encode frames |
||||||||||||||||||||||||
Issue descriptionhttps://build.chromium.org/p/chromium.webrtc.fyi/builders/Mac%20Tester/builds/30978/steps/browser_tests/logs/stdio - WebRtcVideoQualityBrowserTest.MANUAL_TestVideoQualityH264 test spams the log with "Failed to encode frame. Error code: -1" and then times out. https://build.chromium.org/p/chromium.webrtc.fyi/builders/Mac%20Tester/builds/30979/steps/browser_tests/logs/stdio - it outputs RESULT Unique_frames_count: 720p_H264= 0 RESULT Max_repeated: 720p_H264= 150 RESULT Max_skipped: 720p_H264= 1 per phoglund@: "This effectively means video isn't working - no video frames are making it through. The test still succeeds because it's a performance test. So H264 is completely broken in WebRTC on that particular bot at least. The graph shows the bot sometimes succeeds with h264 video and sometimes it fails and gets 0 unique frames pushed through: https://chromeperf.appspot.com/report?sid=07ee6b33d24b839360fbfd6458f4c694c5fbf810f72d11737b01bd897937e4ad And here's an example of it happening on the main waterfall bot as well: https://build.chromium.org/p/chromium.webrtc/builders/Mac%20Tester/builds/55821/steps/browser_tests/logs/stdio "
,
Jun 14 2016
Looks like an issue with VideoToolbox/VideoToolbox interaction: [09:11:36.154] VTCompressionSessionCreate signalled err=-8973 (err) (VTVideoEncoderStartSession failed) at /SourceCache/CoreMedia_frameworks/CoreMedia-1562.238/Sources/VideoToolbox/VTCompressionSession.c line 967
,
Jun 14 2016
Looks like a duplicate of Issue 612120 ?
,
Jun 14 2016
It is a VideoToolbox issue that I cannot address directly. Either we can disable HW encode for this test via kDisableWebRtcHWEncoding and solve flakiness, or work on getting better HW support on these bots? WDYT?
,
Jun 14 2016
What does "getting better HW support on these bots" mean? If this is failing on the bots it must be failing for users as well?
,
Jun 14 2016
phoglund@, I have this related bug coming from VideoToolbox in issue 619183. As far as I parsed the logs, there are more errors pointing to AppleIntelHD4000GraphicsVADriver. I was referring to that by better HW, and I should have explained it. However, there are still some crashes with HD5000 as well, so it isn't a 100% solution. Also, from my search on limited sources on this particular error(-8973 codecOpenErr), I found it might be related to not having access to HW. Are there things running in parallel on these bots? As far as the users, I think it should fallback to SW H264 if these error happen. Do these bots have the buildflag RTC_USE_H264?
,
Jun 14 2016
Btw, I was referring to Peter in my earlier reply. Sorry for the mixup.
,
Jun 14 2016
Should those be blacklisted and not claim to support it? Otherwise I we'll need a fallback on these systems.
,
Jun 14 2016
(Don't blacklist too early.)
,
Jun 14 2016
The HW actually supports it mostly. Considering we try to create a session to see HW encode support each time GPU process starts-which means all MAC users out there-, those crashes aren't high at all. However, these bots are crashing much more often than the regular case. So related to it, 1) Are there things running in parallel on these bots? 2) Do these bots have the buildflag RTC_USE_H264? I really would prefer not to use kDisableWebRtcHWEncoding, because that would mean no test coverage :(
,
Jun 15 2016
Re #10: 1) Not really. The tests run sequentially on the bot and nothing else runs at the same time. However, note that the tests open two tabs which each run WebRTC, so maybe we are using two sets of encoder/decoder? 2) Yes.
,
Aug 1 2016
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by phoglund@chromium.org
, Jun 14 2016