+Video eng fyi...

+jansson@ who recently made some code changes to AppRTC.

As mentioned in this bug report, this issue is tracked in  https://github.com/webrtc/apprtc/issues/350

 Issue 637754  has been merged into this issue.

jansson@, I think this is related to the Real AppRTC loopback change[0]. I tried older chrome versions and it still doesn't work. Munge SDP works.

AFAIU, this is issue happens because texture backed frames are sent back to the encode path after cloning tracks in the new loopback. We cannot use the texture backed frames, so we hit the DCHECK on[1]. Note that disabling HW decode would solve this issue as it is the reason why we have texture backed frames in the tracks.

1) jansson@, can you explain the change in AppRTC again? I do not understand why we would have the decoded frames back again for encoding?
2) If my understanding is right, can we have the old AppRTC back as an option? debug=1pcloopback?
3) posciak@,wuchengli@ this is the same reason as issue 550638. Should we handle it by downloading the textures?

[0] https://groups.google.com/a/google.com/forum/#!topic/webrtc-eng/bKdhZuwmiZQ
[1] https://cs.chromium.org/chromium/src/content/renderer/media/webrtc/webrtc_video_capturer_adapter.cc?q=webrtc_video_capturer_adapter.cc&sq=package:chromium&l=230

jansson@ Are you the right person for this? Any update? We use apprtc loopback for ChromeOS testing a lot.

AppRTC is now reverted to the old behavior. Still, this isn't a really a bug in AppRTC, the real problem is that we can forward hardware decoded video tracks.

As mentioned in #8 the old AppRTC loopback behavior is back for now. It will be relanded once all outstanding issues has been resolved.

Filed  bug 642663  for the "forward hardware decoded video tracks" issue.

Verified 8530.77.0, 53.0.2785.87