fix(linux/pipewire): avoid video stream freeze (on display switch)#5249
fix(linux/pipewire): avoid video stream freeze (on display switch)#5249Kishi85 wants to merge 1 commit into
Conversation
Kishi85
force-pushed
the
workaround-video-stream-freeze-on-display-switch
branch
2 times, most recently
from
b29d83a to
d633d52
Compare
Kishi85
force-pushed
the
workaround-video-stream-freeze-on-display-switch
branch
4 times, most recently
from
bb8e6da to
1003b5d
Compare
ReenigneArcher
force-pushed
the
workaround-video-stream-freeze-on-display-switch
branch
from
1003b5d to
f8bb8ae
Compare
Bundle ReportBundle size has no change ✅ |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #5249 +/- ##
=========================================
Coverage ? 17.82%
=========================================
Files ? 111
Lines ? 24179
Branches ? 10700
=========================================
Hits ? 4310
Misses ? 17909
Partials ? 1960
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report in Codecov by Harness.
|
|
Does this resolve #4943 then? And, do you want to merge this or wait for tester feedback (it's unclear from the PR description)? |
|
It's the fix for the second issue that I've identified in #4943 after commenting out the frame flush (still waiting on feedback in #4943 for that). The video stream freeze issue can occur independently although I'm unsure about the root cause as it's some kind of race condition with an extremely tight timing. It would probably be good to have someone else look at this if possible but I'd also rather not delay this too long in case it also helps with #5241. Maybe @psyke83 could check this if his time permits? By itself this shouldn't break anything as it is only adding 100us to the display switch capture loop return (and only to that specific case). I can also add the removal of the frame flush to this PR depending on the final verdict in #4943 if you want to wait for that. |
Kishi85
force-pushed
the
workaround-video-stream-freeze-on-display-switch
branch
from
f8bb8ae to
f4d7ea3
Compare
This is a trial-and-error workaround to avoid video stream freezing when display switching that somehow happens when not using the added thread sleeps due to a racecondition that needs to be further diagnosed. Pipewire state change logging is also move to information log level to improve initial issue analysis without enabling debug logging
Kishi85
force-pushed
the
workaround-video-stream-freeze-on-display-switch
branch
from
f4d7ea3 to
db9699b
Compare
|
|
To speed this up I've removed the logic order change (as that's the thing I was really unsure about) for the capture timeout case (as it is working as it is now). If someone ever finds and fixes the root cause or has a better solution to avoid the video stream freeze the workaround can/should be replaced/removed. The way it is now I'm good with merging the change. Still needs a fix for the FFmpeg segfault to fully handle #4943 for that see #5257, otherwise it needs to be fixed in upstream FFmpeg. |
|
You mention that the issue can't be reproduced when Sunshine debug is active, but have you tried checking (only) the pipewire debug output for any clues when this happens? Adding PIPEWIRE_DEBUG=4 into Sunshine's runtime environment should do the trick. |
|
Pipewire debug output (although it is a lot) shows the following right before the stream freezes: If I'm reading this correctly then pipewire should be streaming already (first line) but whatever happens in Sunshine's video capture loop gets stuck without that tiny delay (Audio still plays, further display switching breaks likely due to As already noted I've not found a way to properly debug this yet as even the debugger (or debug logging) throws the timing off enough to not trigger the issue. With this PR applied I'm getting the same Pipewire debug output but this time the encoder properly creates and starts up: The only difference on pipewire debug output I've seen once after was (and that only because I've been button mashing CTRL+ALT+SHIFT+F1 as hard as possible): The freeze only happens on portal-/kwingrab, not on kmsgrab and I've also tested both vulkan and vaapi encoders to make sure it's not related to them. I'm not fully satisfied with adding a microsleep to workaround this issue but so far it's the best thing I could come up with and it's the only thing that has proven to reliably work. Therefore I've marked this as a workaround in code until a better solution is found. |
|
Can you see if the issue can reproduce with active content on the host? Leave vrrtest running, for example. When troubleshooting mode change hangs there was one specific case where a hang occurred only when changing modes on an idle desktop. |
|
Also happens on non-idle stream. Tested with running a YouTube video. That's where I noted audio continuing despite the video stream freeze. |
|
To clarify: The issue does not occur on every display switch but has a noticeable chance to occur (like 3 in 10 switches). It can also be force by button mashing any display switch button repeatedly (Note: you might trigger #4943 as well without the proper fix in place). |
3 participants
Description
This is a trial-and-error workaround to avoid video stream freezing when display switching that somehow happens when not using the added thread sleeps due to a racecondition that needs to be further diagnosed and might even be outside Sunshine's control. Adding a 0.1ms sleep at the relevant codepoints (see changes) seems to fix the issue reliably without creating unwanted behaviour/other issues.
Also the log level for pipewire state changes to ease initial analysis of future issues without having debug logging enabled.
This issue was identified after working around the FFmpeg segfault in #4943 but might occur independently from that. Unsure if this can also help with #5241 but should be tested as it might be the same root cause.
Note: This issue is almost impossible to pinpoint as it is only occurring when running as a systemd user service without having debug logging enabled (so
BOOST_LOG(debug)does noop). If run with debug logging enabled, the added runtime by BOOST_LOG is sufficient to allievate the issue. Same is true if running with a debugger attached. The only way to figure out the relevant code segment was by changing the loglevel for each log statement inpipewire.cppand trying to trigger the issue. After doing that the following codesegment was found to fix the issue when using log level info:Sunshine/src/platform/linux/pipewire.cpp
Lines 866 to 869 in 1f0455c
That is why the workaround now adds a 0.1ms sleep right before the return (and does so also for the timeout case).
Screenshot
Issues Fixed or Closed
Roadmap Issues
Type of Change
Checklist
AI Usage