video doesn't play on ring.com
Categories
(Web Compatibility :: Site Reports, defect)
Tracking
(firefox-esr115 unaffected, firefox-esr128 disabled, firefox127 unaffected, firefox128+ disabled, firefox129 disabled, firefox130 disabled, firefox131 disabled, firefox132 disabled, firefox133 disabled)
Tracking | Status | |
---|---|---|
firefox-esr115 | --- | unaffected |
firefox-esr128 | --- | disabled |
firefox127 | --- | unaffected |
firefox128 | + | disabled |
firefox129 | --- | disabled |
firefox130 | --- | disabled |
firefox131 | --- | disabled |
firefox132 | --- | disabled |
firefox133 | --- | disabled |
People
(Reporter: mycomputor56, Unassigned)
References
(Regression, )
Details
(Keywords: regression, webcompat:contact-in-progress, webcompat:site-report)
Attachments
(2 files)
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•5 months ago
|
||
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•5 months ago
|
||
Is there anything in the js console that seems related (ctrl-shift-i, view console)
Comment 4•4 months ago
|
||
(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.
Updated•4 months ago
|
Updated•4 months ago
|
Comment 5•4 months ago
|
||
It is possible that this has been fixed in bug 1901752; we may want to uplift that fix?
Comment 6•4 months ago
|
||
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•4 months ago
|
||
Comment 8•4 months ago
|
||
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•4 months ago
|
||
Profile as requested https://share.firefox.dev/3KUbkur
Comment 10•4 months ago
•
|
||
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•4 months ago
|
||
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•4 months ago
|
||
Setting that pref in beta version 128.0b6 as well.
Comment 13•4 months ago
|
||
Setting that pref in beta version 128.0b6 works fine as well
Comment 14•4 months ago
|
||
I don't see any webrtc call threads in the profile. To verify, did you select WebRTC
for the logging preset?
Comment 15•4 months ago
|
||
Sorry, was rushing so totally forgot that bit. Will do it properly tomorrow.
Comment 16•4 months ago
|
||
(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•4 months ago
|
||
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•4 months ago
|
||
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•4 months ago
|
||
: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•4 months ago
|
||
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•4 months ago
|
||
(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•4 months ago
|
||
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?
Updated•4 months ago
|
Comment 23•4 months ago
|
||
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•4 months ago
|
||
FYI we're going to flip the pref to false to address this in 128.
Updated•4 months ago
|
Comment 25•4 months ago
|
||
Setting Fx128 to Fixed since Bug 1905125 has landed on central
Updated•4 months ago
|
Comment 26•4 months ago
|
||
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.
Updated•4 months ago
|
Updated•4 months ago
|
Updated•4 months ago
|
Comment 27•4 months ago
|
||
(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.
Updated•4 months ago
|
Updated•2 months ago
|
Updated•2 months ago
|
Comment 28•1 month ago
|
||
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•7 days ago
|
||
We're trying to get in touch with them.
Comment 30•7 days ago
|
||
I have a contact there I can try if you would like me to give it a shot!
Updated•5 days ago
|
Description
•