i thought that it showed up when SetClientCallbacks was removed from Initialize, but that's not correct.  it turns out that it's probably existed since AVDA started requesting compositor feedback.

i'm building back to 68ec57f3e3114 (Added PromotionHintAggregator, June 27) to see if it shows up there.

it does, once i apply https://chromium-review.googlesource.com/703931 .

i'm going to merge that fix to M62, and i'll include something to prevent this one.  probably is_null() checks and / or not requesting compositor feedback for sync init.  either one would do it.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4eac801c067dde1b0bc13555c9a793aa040a48c7

commit 4eac801c067dde1b0bc13555c9a793aa040a48c7
Author: liberato@chromium.org <liberato@chromium.org>
Date: Mon Oct 09 19:11:33 2017

Install callbacks for the AVDA sync init path.

Previously, we didn't bother to install callbacks for the sync
init path for |surface_chooser_|, because there wasn't any need
for the chooser to choose anything.  However, now that we request
compositor feedback for overlay promotion, we still might ask the
chooser to choose.  When it does, it'll crash without a callback.

This CL installs the callbacks so that the chooser is in a good
state even in the sync path.  Then, it doesn't matter if we ask it
questions, since it will (correctly) answer "use SurfaceTexture".
It also adds a check to the appropriate unit test.

Bug:  772899 , 772613
Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: Ie0eb6bf5febcdb21119b734d3f2483e4d5aa9d70
Reviewed-on: https://chromium-review.googlesource.com/706250
Commit-Queue: Frank Liberato <liberato@chromium.org>
Reviewed-by: Thomas Guilbert <tguilbert@chromium.org>
Cr-Commit-Position: refs/heads/master@{#507441}
[modify] https://crrev.com/4eac801c067dde1b0bc13555c9a793aa040a48c7/media/gpu/android/android_video_decode_accelerator.cc
[modify] https://crrev.com/4eac801c067dde1b0bc13555c9a793aa040a48c7/media/gpu/android/android_video_decode_accelerator_unittest.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/23634a33affce3a80d53f8aa18f0b2408794389e

commit 23634a33affce3a80d53f8aa18f0b2408794389e
Author: liberato@chromium.org <liberato@chromium.org>
Date: Mon Oct 09 20:55:38 2017

[M-62] Fix WebRTC when using AVDA.

RTCVideoDecoder didn't get updated to support overlay promotion
hints and the "is surface texture" flags.  This causes it to
try to promote video frames from AVDA to overlays.  This doesn't
work at all.  This is  crbug.com/769148  .

This CL also fixes a bug caused by receiving promotion feedback
when AVDA is initialized in sync mode (WebRTC), that wasn't visible
due to 769148.  The callbacks for AndroidVideoSurfaceChooser aren't
initialized, but promotion feedback can cause us to call into the
chooser.  That can cause the chooser to try to use one of the
unitialized callbacks.

Since the sync init path doesn't support overlays anyway, we simply
don't request overlay feedback when we use sync init.  This stops
AVDA from setting the unsupported Picture flags (769148), and
prevents it from asking the surface chooser while the chooser
doesn't have any callbacks (772613, 772899).

This is somewhat smaller than the ToT fixes, since the ToT code
has been changed a bit since M62.  It's less clear at ToT that
this simple fix is sufficient.

The ToT changes are here:
https://chromium-review.googlesource.com/703931
https://chromium-review.googlesource.com/706250

Tests on M62 were manual:

 - Clusterfuzz test case from crbug.com/772613 .
 - Test WebRTC url from  crbug.com/669148 
 - Non-WebRTC src= videos, switching between fullscreen and inline
   playback.  Also checked devtools inspection while in fullscreen,
   to be sure that fallback worked.  'dumpsys SurfaceFlinger'
   confirmed that overlays were in use at the correct times.

TBR=watk@chromium.org
NOPRESUBMIT=true
NOTRY=true

Bug:  769148 , 772613,  772899 
Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: I46c0c2c2c10f67a45cf7f72caf6fd59a949e4723
Reviewed-on: https://chromium-review.googlesource.com/707588
Reviewed-by: Frank Liberato <liberato@chromium.org>
Cr-Commit-Position: refs/branch-heads/3202@{#623}
Cr-Branched-From: fa6a5d87adff761bc16afc5498c3f5944c1daa68-refs/heads/master@{#499098}
[modify] https://crrev.com/23634a33affce3a80d53f8aa18f0b2408794389e/media/gpu/android_video_decode_accelerator.cc

It would be good to verify whether this fixes the VP8 variant of this bug:
https://bugs.chromium.org/p/webrtc/issues/detail?id=8362#c6
(Note: That bug also has an H264 variant)

Can someone try these repro steps on android?

1. My tests were done with Android version 7.0, build number NRD90M.G955USQU1AQDE on a Samsung Galaxy s8+ 
2. Open up https://appr.tc/?debug=loopback&audio=false&video=true&vrc=VP8&vsc=VP8
3. Click "Join".

Expected Result:
A successful loopback call with both the larger video element and the smaller video element showing live footage from the front-facing camera, without any freezing or lockups.

Actual Result:
The larger video element displays as all green and frozen, and the smaller video element does manage to display a single frame from the front camera, but it is also frozen and never updates.
The chrome page appears to be in a frozen state overall (e.g. No responsiveness to the "Hangup" button when I tap on it). I can only get chrome to respond by clicking the address bar. However, Chrome will freeze again when going into tabs parade view.

Emmm, my Chromium building(63.3237) works well with loopback testing. But Canary(63.3236.6) doesn't. Maybe you should wait to verify it with a later version.

@braveyao Does https://appr.tc/?debug=loopback&audio=false&video=true&vrc=H264&vsc=H264 work in your loopback testing with 63.3237? Wondering if H264 is fixed now, too.

The fix for H264 is under reviewing. So it works in my Chromium build only. :)

@braveyao Ok thanks. I'm really hoping the H264 fix makes it to M62 :)

@braveyao Can you point me to the code review link for the H264 fixes? I can't seem to find them.