Dale, do you know who could have a look at this? This doesn't seem to be a WebRTC issue, but if you think otherwise please throw it back.

Will take a look, +liberato, watk who are working on this code.

How did you get that log output? I clicked a couple links in #16854 and don't see that log message. Do you know what the test that's failing is doing?

IIRC WebRTC never uses SurfaceView so it should always be configured with SurfaceTexture and that's about the only thing we've changed recently.

You have to click the "stack_tool_with_logcat" one. Doesn't look like the mentioned build # has this crash though. But this one does: https://build.chromium.org/p/chromium.webrtc.fyi/builders/Android%20Tests%20%28dbg%29%20%28L%20Nexus9%29/builds/16887/steps/stack_tool_with_logcat_dump/logs/stdio

Sorry for the unclear information. It seems like most of Dale's questions have been answered now.

Different tests are failing, but I presume there's a common piece that fails on all of them.

phoglund@: could you explain what the test does?

magjed@: can you comment on WebRTC and SurfaceView?

Re #5: Don't know, haven't seen this test before.

Chromium does not use any Android code at all from WebRTC. All Android rendering for Chrome is Chrome specific code.

Hmm, I think this is a WebRTC rendering issue. Assuming frames are always rendered in order this check should be impossible to hit. The only way I can think of to hit this is if WebRTC sometimes renders frames out of order.

I.e. Say we have frames [f0, f1, f2, f3]; f0 is in the front buffer of the SurfaceTexture and f1 is in the back buffer. WebRTC then renders f2 which promotes it to the front buffer, then later decides to render f1 to the front buffer. Instead this frame should have been dropped.

The simplest workaround is that we disable early-rendering for WebRTC. The correct solution is for someone on the WebRTC team to debug why frames might be getting rendered out of order. +qiangchen@ who's worked with the WebRTC rendering path before.

Probably the easiest way to test this is to add some logging in the compositor (WebMediaPlayerMS?) which prints out the unique_id() for each received VideoFrame and checks to see if they appear out of order. I'm unable to reproduce on my local system thus far, so I can't test this; I don't have an N9 either unfortunately. I'll keep trying, but wanted to update this ticket with the latest info.

=>grunell@ who asked me to assign back if I thought this was a WebRTC issue. It's also possible emircan@'s recent changes will help with this if there was a bug in the delivery code.

Actually was able to repo and the test I suggested passes, so WebRTC probably isn't the one rendering out of order. I think AVDACodecImage might be doing that when GetTextureMatrix() is called at an odd time.

Actually back to grunell@, my guess and experiment were wrong. These frames are going somewhere else other than WMP compositor. Here's the out of order issue:

[ERROR:avda_codec_image.cc(203)] Rendering to back buffer: codec_buffer_index=0
[ERROR:android_video_decode_accelerator.cc(759)] SendDecodedFrameToClient : codec_buffer_index=0 (picture_buffer_id=2)
[ERROR:rtc_video_decoder.cc(437)] Assigning picture_buffer_id=2 to unique_id=39
[ERROR:android_video_decode_accelerator.cc(863)] ReusePictureBuffer : (picture_buffer_id=1)
[ERROR:android_video_decode_accelerator.cc(759)] SendDecodedFrameToClient : codec_buffer_index=1 (picture_buffer_id=4)
[ERROR:rtc_video_decoder.cc(437)] Assigning picture_buffer_id=4 to unique_id=42
[ERROR:avda_codec_image.cc(201)] Rendering to front buffer: codec_buffer_index=1
[ERROR:avda_shared_state.cc(141)] Fulfilling previous wait while releasing codec_buffer_index=1
[ERROR:avda_codec_image.cc(216)] Waiting... codec_buffer_index=1
[ERROR:avda_codec_image.cc(210)] Waiting for back buffer promotion: codec_buffer_index=0
[ERROR:avda_codec_image.cc(216)] Waiting... codec_buffer_index=0
[FATAL:avda_shared_state.cc(93)] Check failed: !release_time_.is_null(). 

The issue is that even though we've delivered the frames 0 and 1 in that order to WebRTC, for some reason it's trying to use them in the order of 1 then 0; this isn't possible with the way zero-copy works on Android. RTCVideoDecoder is getting the frames in order, so it's not a problem up to that point. From there I lose track of things inside the WebRTC internals.

The test I proposed above doesn't work since the frames don't seem to be rendered by the WebMediaPlayerMS_Compositor. I'm not sure what's rendering them, but if you can figure that out add add a CHECK() that VideoFrame::unique_id() is monotonically increasing, it'll crash there -- since frame 0 has unique_id=39 and frame 1 has unique_id=42.

And a note on reproduciblility: Had to use a debug build with the following:

./out/Debug/bin/run_content_browsertests --gtest_filter=WebRtcMediaRecorderTest.PeerConnection/* --gtest_repeat=5

Less than that wouldn't reliably crash.

Magnus F, can you re-assign as appropriate? According to Dale's investigation (thanks Dale!) this should be a WebRTC issue, see in particular comment #10.