Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jittery Video in Firefox 119 #1025

Open
TheMegamind opened this issue Oct 27, 2023 · 15 comments
Open

Jittery Video in Firefox 119 #1025

TheMegamind opened this issue Oct 27, 2023 · 15 comments

Comments

@TheMegamind
Copy link

TheMegamind commented Oct 27, 2023

This is most likely a bug in Firefox, but I'm posting here because I've only encountered this with Wyze-Bridge and was curious if others have seen similar behavior.

Starting very recently, coinciding I believe with the Firefox 119 update, the live video from all of my cameras (from a V2 Pan to as V3 and even a V3 Pro) has become jittery as per the video below. The time stamp jumps around and occasionally (though not in this video) the window flashes green for a fraction of a second).

I tested with both Chrome and Edge and the video was smooth and unaffected. So, going back to FF, I tested with another existing user profile as well a brand new, wholly untouched profile and the jitter issue was present with both. With further tinkering, I observed that disabling Hardware Acceleration in Firefox under Settings → General → Performance and restarting the browser eliminated the issue.

Capture.mp4

Windows 11 w/NVIDIA GeForce GTS 1050 Ti

Edit: Found this link

@mrlt8
Copy link
Owner

mrlt8 commented Nov 2, 2023

Interesting. Could be related to the way the video is encoded by the cameras which is causing issues with hardware decoding.

@TheMegamind
Copy link
Author

It's only become an issue on with Firefox with release 118 or 119, and (so far at least) with Wyze-Bridge. I do not have the same issue with Hardware Acceleration enabled in Edge and Chrome. It's very frustrating. I guess I'll wait and see if there's a fix in FF 120, then take it from there.

@d-allin
Copy link

d-allin commented Nov 8, 2023

Man, do I ever feel dumb now. I've spent hours troubleshooting this, assuming it was a problem with one of the bridge's dependencies, my network, or just wyze being wyze. Of course, I never thought to check the playback outside of Firefox.

Looks like this is moving on bugzilla.

NVENC-encoded H.264 sent over WebRTC to Firefox 119 on Windows results in a glitching stream - a problem which doesn't exist in Firefox 118 and 120.0beta.

@TheMegamind
Copy link
Author

TheMegamind commented Nov 8, 2023

@d-allin Yeah, I spent a lot of time troubleshooting this as well before posting here. Thanks for the bugzilla link. Maybe I'll post a link back to here just in case it might be useful to someone.

@peinchka
Copy link

I've posted some quick-fixes for this issue at the Bugzilla link. Hopefully, I've also now provided enough info to Mozilla to quickly and fully resolve this problem in Firefox 110, 119 and 120.

@TheMegamind
Copy link
Author

@mrlt8 As Firefox has given this bug low priority, is there any way to implement an optional temporarily fix for those of us affected? I know it's not your issue, but I've had to deal the jittery video for too long now.

For anyone else experiencing this issue, if you’re able to modify the HTML code of the webpage, slightly blurring a single pixel has been found to completely remedy the glitching problem in all affected Firefox versions. A line like this is all you need:

<div style="width: 1px; height: 1px; position: fixed; backdrop-filter: blur(0.01rem)"></div>

@mrlt8
Copy link
Owner

mrlt8 commented Dec 27, 2023

@TheMegamind Can that go anywhere in the page or do we need one near each video tag?

@TheMegamind
Copy link
Author

Good question. I'm not sure since it's not my solution, but rather was borrowed from the bugzilla link. There are a couple of references to that and similar workarounds that might be helpful.

I see the commit. Is there an easy for me to test?

@mrlt8
Copy link
Owner

mrlt8 commented Dec 27, 2023

Changes should be in the dev branch which you can pull using the dev image mrlt8/wyze-bridge:dev.

@TheMegamind
Copy link
Author

Okay, that works in multi-camera view, but not for a single camera full-screen.

@mrlt8
Copy link
Owner

mrlt8 commented Dec 27, 2023

Single camera full-screen page is part of mediamtx, so we'd need to do a PR to the html that mtx generates.

@TheMegamind
Copy link
Author

Given that this a bug in Firefox, not mediamtx, is that something one can reasonably do? It feels like that might be pushing things, but either way, I don't have a working knowledge of mediamtx or feel sufficiently qualified to submit a proper PR. I'll just have to follow your lead on what's best. At least the latest commit above gives us a partial workaround for now, so thank you for that much!

@mrlt8
Copy link
Owner

mrlt8 commented Dec 28, 2023

I modified the fix to use CSS so that the pixel only displays in firefox. Can you pull a fresh dev image to test?

edit: does this also affect the HLS video?

@TheMegamind
Copy link
Author

Pulled the dev image and it is working as expected with both webRTC and HLS.

mrlt8 added a commit that referenced this issue Jan 11, 2024
* Drop late audio frames to keep sync #388

* show running architecture

* Don't log failed tutk if stream is down #990

* Use valid FPS for sleep #388

* Refactor

* Adjust sleep_interval #388

* Increase sleep time between frames #388

* Set larger buf size #388

* add SLEEP_INTERVAL_FPS #388

* Adjust sleep interval #388

* use genpts #388

* avoid conflicting names with errno module

* refactor _audio_frame_slow

* LOW_LATENCY mode

* show github SHA on dev build

* substream support and more refactoring #388

* div tag for jittery video in Firefox #1025

* Re-encoding audio for WebRTC/MTX

* reduce sleep time for audio thread #388

* Target firefox for jittery video fix in css #1025

* Use K10050GetVideoParam for FW 4.50.4.x #1070

* Use K10006 for newer doorbell #742 and refactor

* Reduce audio pipe flushing #388

* show gap when audio out of sync #388

* don't include ARCH in version

* Update iotc.py

* reset frame_ts on clock sync

* update auth api

* Restructure and cleanup

* remove unneeded files

* update path

* Forget alarm/siren state #953 #1051

* use addon_config for Home Assistant

* Additional refactoring to auth api

* don't skip keyframes #388

* Update ffmpeg.py

* delay audio when ahead #388

* format iotc logging so we know what cam is late

* drop late video frame and speed up audio #388

* Add Floodlight V2

* Set default sample rate for all cams

* Delay audio by 1 second if ahead of video #388

* tweak ffmpeg buffer #388

* Retain MQTT Discovery Message #920

* Update change log

Special thanks to @carlosnasillo!
@TheMegamind
Copy link
Author

@mrlt8 This issue appears to have been resolved in Firefox 123 via 1817617.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants