Issue metadata
Sign in to add a comment
|
Headless: WebRTC video fails to render incoming h.264 streams
Reported by
char...@tokbox.com,
Jan 22 2018
|
||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36 Steps to reproduce the problem: 1. Launch headless chrome *without* --disable-gpu 2. Open apprtc room with vrc=H264 in queryparams (you'll need another peer up and running for this step) What is the expected behavior? Received video is rendered and available for local recording What went wrong? * Video is not rendered (viewing through devtools screencast / chrome-devtools-frontend.appspot). * A MediaRecorder with mimeType: 'video/webm' will only receive audio data. Did this work before? Yes Repro steps are working in 63.0.3239.132 Chrome version: 66.0.3328.0 Channel: stable OS Version: OS X 10.13.2 Flash Version: * getStats/webrtc-internals seem to confirm receipt of video data (positive/nonzero fps and bitrate received) * Adding --disable-gpu works * Receiving VP8 works, regardless of gpu flag While receiving video, console spams messages: [0122/113634.032509:ERROR:video_resource_updater.cc(780)] Not implemented reached in void cc::VideoResourceUpdater::AppendQuads(viz::RenderPass *, scoped_refptr<media::VideoFrame>, gfx::Transform, gfx::Size, gfx::Rect, gfx::Rect, bool, bool, float, int, gfx::Rect)
,
Jan 23 2018
,
Jan 23 2018
Unable to check this issue on 66.0.3328.0 using Mac 10.13.1 with below steps as seeing error in console and chrome doesn't get invoked. 1. Tried launching chrome through terminal using /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --headless --remote-debugging-port=9222 https://apprtc.com 2. Seeing error on giving above command in terminal. Attaching screencast for reference. As this is related to Headless chrome, adding Internals>Headless label. Could someone from dev team please have a look at this issue. Thanks!
,
Jan 23 2018
I wonder if there's some limitation in Swiftshader re: video formats? This needs some more investigation I think.
,
Jan 30 2018
As issue is not reproducible from TE end, could someone from Internals>GPU>SwiftShader team please have a look at this issue. Thanks!
,
Jan 30 2018
Just some notes on that repro comment, I apologize I didn't give more comprehensive steps in the OP: 1) Navigate to https://appr.tc/r/804420?vrc=H264 in the CLI kickoff for canary 2) In a separate browser (doesn't matter which but we'll say Chrome Stable), open http://localhost:9222 - follow the only link on the page and make sure the headless client has joined the call. We'll call this "Browser B Tab 1". Publishing audio/video will probably fail for lack of getUserMedia, but the more important issue here will be with incoming video. 3) In browser for 2, open a second tab with https://appr.tc/r/804420?vrc=H264 - make sure this browser joins the call as well. This is "Browser B Tab 2" 4) Back on Tab 1, you should see the video surface as blank, via the screencast. 5) Repeat 1-4 without vrc hint. I may have run into a different issue with the MediaRecorder, so it's probably safe to ignore it for now, but the video rendering still seemed broken last time I walked through these steps.
,
Dec 4
|
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by char...@tokbox.com
, Jan 22 2018