1374297 - [WebRTC] Firefox does not render H264 video received from Chrome

Status: RESOLVED WORKSFORME

(Core :: WebRTC, defect, P2)

Description

[mparisdiaz]

Attachment: firefox_webrtc_internals.pdf

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0
Build ID: 20170612122310

Steps to reproduce:

1 - Open https://appr.tc/r/1122334455?vrc=H264 in Firefox
2 - Open https://appr.tc/r/1122334455?vrc=H264 in Chrome


Actual results:

Chrome renders video received from Firefox,
but Firefox does NOT render the video received from Chrome.


Expected results:

Firefox should render video received from Chrome.

In addition, I am attaching a PDF with Firefox WebRTC internals where you can see that video RTP packets are received.

Comment 1

[Randell Jesup [:jesup] (needinfo me)]

Please attach a log with the RTP logging info described in Nils's blog post at https://blog.mozilla.org/webrtc/debugging-encrypted-rtp-is-more-fun-than-it-used-to-be/

Thanks

And attach about:webrtc data by using the "Save" button...

Comment 2

[Randell Jesup [:jesup] (needinfo me)]

What version of Firefox?  What version of Chrome?  OS running on?  and very important - you're running these on two separate machines, right?  Two browsers can't access the camera on the same machine in  most OSes.

I did a quick 1-machine test (with Firefox not being able to access the camera, since I started Chrome first), using Chrome Release (59) and Firefox Nightly, and Firefox had no problems decoding Chrome's H264 stream.

Comment 3

[Randell Jesup [:jesup] (needinfo me)]

We tried this between two machines, and I tried on FF Nightly/56 and FF/Beta 55; in all cases it worked in both directions.

Comment 4

[mparisdiaz]

Attachment: apprtc_not_working: cactus not seen in Firefox

Comment 5

[mparisdiaz]

Attachment: apprtc_working: cactus seen in Firefox

Comment 6

[mparisdiaz]

Hello Randell,
sorry I forgot saying the related versions:
 - Chrome 59.0.3071.115
 - Firefox 54.0.1
 - OS: Windows 7

I tested it with separate machines and using the same machine, but I have 2 cameras connected: Chrome uses one of them and Firefox the other one.

I have an app to test an SFU and after realizing that H264 was not rendered by Firefox, I used apprtc to check if it also happened, and it did, because of that I opened this bug.
After performing more tests, it seems that I am suffering something quite tricky:
 1 - Start a new instance of Firefox
 2 - Using the SFU-app, Firefox DOES NOT render H264 video received from Chrome - FAIL
     - Cactus is not seen in Firefox
 3 - Using apprtc, Firefox DOES NOT render H264 video received from Chrome - FAIL
 4 - Restart Firefox
 5 - Using apprtc, Firefox RENDERS H264 video received from Chrome - SUCCESSFUL
     - Cactus is seen in Firefox
 6 - Using SFU-app, Firefox RENDERS H264 video received from Chrome - SUCCESSFUL

Any idea about why could this happen?

Comment 7

[Randell Jesup [:jesup] (needinfo me)]

No... that's very odd.  Is it repeatable, and is it dependent on which one you use first?  In general, I prefer tests on multiple machines...   it avoids possible issues with camera access.  

The "doesn't work" image tells me the call is only half-connected -- note that the Firefox side doesn't have a hangup button.

Please do this: set env variable  MOZ_LOG=signaling:4,jsep:5 and MOZ_LOG_FILE to some temp file, then start firefox and do the "fails" sequence.  Quit, save the log file(s) -- it will use the MOZ_LOG_FILE as a base name for content processes.

Then after saving off the files, do the same for the "works" sequence.  Zip all these up (and label which set failed) and attach here.

Thanks!

Comment 8

[mparisdiaz]

Hello again Randell,
I have set the env variables you told me in Ubuntu but I couldn't reproduce the problem.

In Windows I can reproduce it but I wasn't able to get the logs you required. I used about:networking tab as explained in [1], the log file is created but it is always empty.
I used both Firefox 54.0.1 and beta-55.0b6

What I was able to get is webrtc-internals (about:webrtc) where we can see that RTP packets are sent and received for both audio and video. I am attaching the failure cases related to the SFU-app and apprtc.

Refs
[1] https://blog.mozilla.org/webrtc/debugging-encrypted-rtp-is-more-fun-than-it-used-to-be/

Comment 9

[mparisdiaz]

Attachment: sfu-app_fails.pdf

Comment 10

[mparisdiaz]

Attachment: apprtc_fails.pdf

Comment 11

[Maire Reavy [:mreavy]]

Randell -- What are next steps here?

Comment 12

[Randell Jesup [:jesup] (needinfo me)]

You need to restart firefox on windows with "multiprocess" turned off in prefs to capture the logs

Also, it helps if you upload the about:webrtc logs as saved, instead of as a PDF

Is this still happening?

Comment 13

[Bulk Bug Changes for mreavy's org]

Mass change P1->P2 to align with new Mozilla triage process

Comment 14

[mparisdiaz]

It is not longer reproducible with Firefox 62 neither Firefox 63.

Comment 15

[Nils Ohlmeier [:drno]]

Thanks for checking again! Appreciated.

Comment 16

[mparisdiaz]

Thank you ;)