Android - Unsuccessful WebRTC call using vp9 codec between Chrome and FireFox |
|||||||||||||
Issue descriptionChrome Version : 58.0.3026.5 / Dev / Chrome Canary 64-bit / Arm 64 Operating System : Android 7.1.1 What steps will reproduce the problem? 1. On one Android device browse to https://appr.tc on a Chrome browser, enter a room name and join 2. On another Android device browse to https://appr.tc on a Firefox browser and join the same room name What is the expected result? Verify that video and audio flows between the devices What happens instead? step 1: Chrome device: No audio or video from step 2 remote party device, no selfview icon in lower left hand corner and hang up icon missing step 2: Firefox device: Audio heard and video seen from step 1 device, self view icon seen in lower left hand corner and all call control icons seen Please provide any additional information below. Attach a screenshot if possible. The bug is first seen on Chrome 58.0.3000.0 (i.e 58.0.2999.0 does NOT have the bug) I see the video codec being used is vp9 (chrome://webrtc-internals & about:webrtc on Firefox) Devices Step 1: Google Pixel XL Marlin (OS: Android 7.1.1) Step 2: Samsung Galaxy S6 (OS: Android 6.0.1) Note: Bug also seen if step 1 device is Samsung S6 (OS: Android 6.0.1) Firefox version: step 2: Firefox 51.0.3 Forcing codec to vp8 does NOT give the bug i.e do: 1. On one Android device browse to https://appr.tc/?vsc=vp8 on a Chrome browser, enter a room name and join 2. On another Android device browse to https://appr.tc/?vsc=vp8 on a Firefox browser and join the same room name
,
Mar 20 2017
Philip, this might be related to what you're already looking into.
,
Mar 20 2017
+emircan who landed https://chromium.googlesource.com/chromium/src.git/+/33a70a137b5635e13d60c66d3666d7f6167fe831 which affects VP9 and likely was picked up in 58.0.3000.0. Could you test this setup?
,
Mar 20 2017
+cc braveyao@ I thought VP9 wouldn't be picked on Android, see https://bugs.chromium.org/p/chromium/issues/detail?id=687650#c4. Can you check what is happening here?
,
Mar 20 2017
I tried Chrome dev 58.0.3029(on my N9+7.1.1). It works well with FF on N5X and Chrome on Linux desktop. Could you please try again? BTW: given that no local preview in step1, some other failure may happen on Pixel. If you can reproduce it, could you please get the logcat info on Pixel?
,
Mar 30 2017
braveyao@: I've just had time (today) to see your post, so just to update. The bug still exists on Chrome 58.0.3029.11 Canary on 1st device and FF 51.0.3 on 2nd device: 1st: Google Pixel XL Marlin / 7.1.1 2nd: Samsung Galaxy S6 / 6.0.1 I'll get back if with the Pixel XL logcat info
,
Mar 30 2017
braveyao@: The bug still exists on Chrome 59.0.3050.4/canary on 1st device and FF 51.0.3 on 2nd device: 1st: Google Pixel XL Marlin / 7.1.1 2nd: Samsung Galaxy S6 / 6.0.1 The logcat info (i.e adb -v long) can be found at: https://drive.google.com/a/google.com/file/d/0BzevCB72sdnCc1NDUEowWUJqQVE/view?usp=sharing (Note: the call starts on the Pixel XL at around 03-30 13:58)
,
Mar 30 2017
I did some tests again on all platforms(Android/Win/Mac/Linux) with all Chrome versions. Some results: - The problem happens on all platforms. So it's a generic problem of VP9 SW decoding, given no VP9 HW decoder is available on the platforms in my tests. - VP8/H264 works well between Chrome and FF though. - When problem happens, there are tons of PLI sent from Chrome side. - Sometimes Chrome can start decoding VP9 from FF, either freezing a lot or even smoothly. - Same problem with latest AppRTCMobile app. PS: the FF side is 52.0.1 (64-bit) on Linux in my tests. So hand over back to philipel@ :)
,
Mar 31 2017
I am fairly certain this is unrelated to the new jitter buffer since both 58.0.2999.0 and 58.0.3000.0 use the old jitter buffer, but I will take a look.
,
Apr 3 2017
Here are my findings sending VP9 using Firefox 52.0.1. FF --> Desktop linux 58.0.2999.0 Works badly. It takes several seconds until the first frame is rendered. Most of the time the stream stutters badly and sometimes it's smooth. FF --> Desktop linux 58.0.3000.0 Same behavior as 58.0.2999.0. FF --> Nexus 6 AppRtc Same behavior as 58.0.2999.0. FF --> Pixel XL AppRtc With HW decoding the stream is incorrectly decoded (mostly black). With SW decoding it's the same behavior as 58.0.2999.0. I'm not sure what is causing it though...
,
Dec 18 2017
Old, please reopen if this is still a problem.
,
Dec 18 2017
|
|||||||||||||
►
Sign in to add a comment |
|||||||||||||
Comment 1 by tommi@chromium.org
, Mar 20 2017