1898579 - video doesn't play on ring.com

Status: NEW

(Web Compatibility :: Site Reports, defect)

Description

[mycomputor56]

Attachment: Screenshot 2024-05-23 at 12-12-21 Activity.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:126.0) Gecko/20100101 Firefox/126.0

Steps to reproduce:

rebooted tried website again, video's still do not work

Actual results:

cannot view anything to do with live views from camera or saved videos in history

Expected results:

should have been able to view live feeds from ring.com products and also should be able to view saved videos from past events.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Audio/Video: Playback' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Jim Mathies [:jimm]]

Is there anything in the js console that seems related (ctrl-shift-i, view console)

Comment 4

[Jim Mathies [:jimm]]

(In reply to Kevin Frost from comment #0)

Created attachment 9408473 [details]
Redacted browser console text, I have deleted other tab info.

Steps to reproduce:

This is a password protected site and I'm not able to share the details unless strictly necessary as it is set for 2FA.

Using Firefox Nightly 129.0a1 in trouble shoot mode, goto https://ring.com/users/sign_in and login. The page will display the Dashboard. Click on History and you will have a list of available videos on the left and a black/grey rectangle on the right. It should start playing the video that has been saved from the cameras.

Actual results:

The page displays in red "There was an error in playing the video" after a few seconds and the rectangle now displays a camera icon with a line through it. Clicking on each of the list of video does the same.

I have used mozregression-gui to test various builds back to the 2024-06-01 (image attached) and sometimes it worked and mostly not. When it stopped, it made reference to:

Bug 1900114 - Add signaling for Baseline H264.;r=bwc

Differential Revision: https://phabricator.services.mozilla.com/D212312

I have also attached the browser console text which shows what happened when I refreshed the page.

Expected results:

The video should have played.

Comment 5

[Byron Campen [:bwc]]

It is possible that this has been fixed in bug 1901752; we may want to uplift that fix?

Comment 6

[Dan Baker[:dbaker]]

We should have the other fix uplifted.

For this issue could you retest with the latest Nightly build. While the issue is occuring navigate in a new tab to about:webrtc and expand the RTCPeerConnection Statistics then select Copy Report for the Ring tab. I'm curious to see the SDP(s) and what is being signaled to/from Firefox.

Comment 7

[Kevin Frost]

Attachment: As requested webrtc report file

Comment 8

[Dan Baker[:dbaker]]

Unfortunately that did not have any SDP, lets jump to a profile if that's ok and we can debug from there hopefully.

To Get a Profile:

• On about:logging select the WebRTC preset and click Start Logging.
• In another tab reproduce the issue
• After reproducing, back on about:logging click Stop Logging.
• In the new tab that appears with the Firefox Profiler, in the top right corner, click the button to upload the profile.
• Please include hidden threads!
• Share the link to the uploaded profile here, please.

Comment 9

[Kevin Frost]

Profile as requested https://share.firefox.dev/3KUbkur

Comment 10

[Dan Baker[:dbaker]]

If this is related to the Baseline H264 change then could you try with the following pref media.navigator.video.disable_h264_baseline and set it to true. Grabbing another profile with the pref might be useful as well. Maybe try enabling the profiler before even having the ring tab open.

Are there any console errors as well when this happens?

Comment 11

[Kevin Frost]

Setting the pref media.navigator.video.disable_h264_baseline to true and then going from Dashboard to History on Ring.com to view the recorded video works as expected.
Profile as requested [https://share.firefox.dev/4bgGmYi]

Comment 12

[Kevin Frost]

Setting that pref in beta version 128.0b6 as well.

Comment 13

[Kevin Frost]

Setting that pref in beta version 128.0b6 works fine as well

Comment 14

[Dan Baker[:dbaker]]

I don't see any webrtc call threads in the profile. To verify, did you select WebRTC for the logging preset?

Comment 15

[Kevin Frost]

Sorry, was rushing so totally forgot that bit. Will do it properly tomorrow.

Comment 16

[Dan Baker[:dbaker]]

(In reply to Kevin Frost from comment #15)

Sorry, was rushing so totally forgot that bit. Will do it properly tomorrow.

Sounds great, I really appreciate your help with this. If you have the time when you test again could you run the profile with the pref off and on? I'll try to compare those as well. Additionally not sure if you have another system maybe Windows or Mac and just test Nightly to see if it has the same issue.

It seems that ring is wanting to use Baseline H264 and that is not working.

Comment 17

[Kevin Frost]

Linux - With media.navigator.video.disable_h264_baseline set to false [https://share.firefox.dev/4cw3SSa] with WebRTC logging enabled.
Linux - With media.navigator.video.disable_h264_baseline set to true [https://share.firefox.dev/3xCgIPJ] with WebRTC logging enabled.

MacOS running Sonoma 14.5 - [https://share.firefox.dev/4c9Y4hb] with media.navigator.video.disable_h264_baseline false and with WebRTC logging enabled.
MacOS running Sonoma 14.5 - [https://share.firefox.dev/3RF15hp] with media.navigator.video.disable_h264_baseline true and with WebRTC logging enabled.

Hope this helps this time.

Comment 18

[Dan Baker[:dbaker]]

This was very helpful not sure why they are doing what they are doing or if something is wrong with the Firefox SDP causing it but this is my rough glance at the information.

We are offering with 4 H264

a=fmtp:126 profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1 (42e01f = Constrained Baseline level 3.1 packetization mode 1)
a=fmtp:97 profile-level-id=42e01f;level-asymmetry-allowed=1 (42e01f = Constrained Baseline level 3.1 packetization mode 0)
a=fmtp:105 profile-level-id=42001f;level-asymmetry-allowed=1;packetization-mode=1 (42001f = Baseline level 3.1 packetization mode 1)
a=fmtp:103 profile-level-id=42001f; (42001f = Baseline level 3.1 packetization mode 0)

With PT 126 and 103 the signaling recently added. The answer we get back is only one H264:

a=fmtp:105 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f  (42e01f = Constrained Baseline level 3.1 packetization mode 1)

Oddly they picked the same PT that we use for Baseline but signaling constrained so the subprofiles are different. In theory this should work as long as they are sending us either constrained packets with PT 126 or 97 or Baseline with PT 105 or 103 (assuming appropriate packetization mode).

When it works we are not offering Baseline(105 or 103 PT) and they are answering back with a=fmtp:126 profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1 (42e01f = Constrained Baseline level 3.1 packetization mode 1) which matches our PT for constrained.

My initial hunch is maybe one of the following is happening either Firefox is not liking PT not matching OR ring is getting confused and sending the wrong H264 data to us with PT 105.

I'll try to verify that Firefox can handle this kind of signaling Monday.

Thanks again for all the information.

Comment 19

[Donal Meehan [:dmeehan]]

:dbaker we are in the final week of beta for Fx128 so we have little time left for fixes.
Wondering if there are any updates from Comment 18?

Comment 20

[Jim Mathies [:jimm]]

Possible ride along in a point release if we happen to have something that's well tested, but it's unlikely we'll have something to uplift before the next merge.

Comment 21

[Dan Baker[:dbaker]]

(In reply to Donal Meehan [:dmeehan] from comment #19)

:dbaker we are in the final week of beta for Fx128 so we have little time left for fixes.
Wondering if there are any updates from Comment 18?

I've tested this signaling and Firefox is capable of handling an answer like we are seeing from Ring. This looks more and more like Ring is confused now with the change in our SDP and not handling it properly. If they send us H.264 Constrained with PT 126 as we signaled in the offer this should work. Not sure if we have some way to reach out to Ring but they it looks to me from the data I have and testing that they need to make a change on their end.

Comment 22

[Jim Mathies [:jimm]]

Hey Ksenia, we shipped a spec compliance improvement to try and get snapchat working (Bug 1892073), and that broke ring.com. Is there any way to add an intervention that disables the functionality behind 'media.navigator.video.disable_h264_baseline' for ring.com domains?

Comment 23

[Dan Baker[:dbaker]]

I was able to get a ring camera and test. They are sending us the constrained H264 with PT 105. This does not match as 105 is for Baseline and 126 is what we signaled to receive constrained on. This is not supported behavior and out of spec for Offer/Answer with SDP.

From RFC 3264:
The answerer MUST send using a media format in the offer that is also listed in the answer, and SHOULD send using the most preferred media format in the offer that is also listed in the answer. In the case of RTP, it MUST use the payload type numbers from the offer, even if they differ from those in the answer.
I've also tried swapping the preferred order we are signaling H264 in our offer. I also tried swapping the PT of Baseline and Constrained. None of these resolved the issue, Ring seems to have some parsing error that that I believe will need to be fixed by them.

One possible mitigation is if we could enable the media.navigator.video.disable_h264_baseline for the Ring site until their parsing issue is resolved.

Comment 24

[Jim Mathies [:jimm]]

FYI we're going to flip the pref to false to address this in 128.

Comment 25

[Donal Meehan [:dmeehan]]

Setting Fx128 to Fixed since Bug 1905125 has landed on central

Comment 26

[Jim Mathies [:jimm]]

Note we kept the the spec compliance fix that broke this in Nightly, so this bug still exists in that build. We're trying to find a contact at ring to see if they can fix it on their end.

Comment 27

[Dennis Schubert [:denschub]]

(In reply to Jim Mathies [:jimm] from comment #22)

Is there any way to add an intervention that disables the functionality behind 'media.navigator.video.disable_h264_baseline' for ring.com domains?

Sadly, we can't. We'd absolutely love to have that ability, but Firefox doesn't work that way. about:config flags are always "global", and there is no way to set a pref to a specific value for a given tab, a given root URL, or a given content process. :(

In the past, we've had a couple of prefs with domain blocklists/allowlists, but the only way to do this is to implement that logic inside the consumer of that pref. So you'd have to manually create a pref media.navigator.video.disable_h264_baseline.blocklist and somehow get the current page origin here, which is probably a lot of pain.

Supporting per-site prefs would essentially be a "rewrite how the entire pref system works" kind of project, so I don't have hopes of that changing anytime in the foreseeable future.

Comment 28

[Liz Henry (:lizzard) (relman/hg->git project)]

Dennis, did anyone reach out to ring.com for the remaining issue that affects Nightly? Can you help find an owner for this bug? Thanks!

Comment 29

[Dennis Schubert [:denschub]]

We're trying to get in touch with them.

Comment 30

[Liz Henry (:lizzard) (relman/hg->git project)]

I have a contact there I can try if you would like me to give it a shot!