Screenshare with audio enabled breaks video quality #528
Comments
|
FPS and resolution drops because of insane low bitrate when selected audio source. |
|
This is a footage of the actual screenshare output from another computer. test.mp4Audio was enabled later on. Absolutely perfect before as you can see. GPU Encoding was working fine for 30% of usage, after the audio was enabled, dropped to 0%. |
I also have noticed this on the developer console when a stream w audio is started. Doesn't happen otherwise. If that can be useful |
|
Could happen because the screen share picker for audio adds an audio track - maybe the video properties are reset here somehow? |
|
About stream preview error I think it's okay because I received it even when my bitrate was ok. |
|
Hi, As soon as someone joins the stream, the bitrate goes to 28kpbs. This issue is not present when streaming without an audio source. |
That's what I thought as well ^^ |
@PolisanTheEasyNick Maybe that's caused by the same discord call that messes with the video source shortly after it's started (for which you added the setTimeout call) |
|
fedora 40 gnome 46 latest update I'm using the PR where the bitrate fix was added to the main branch, I can confirm it has the same issue. I haven't run a git pull until now. I'm using the same versions of the latest merge fix for the main branch so far. however, crashes and delays are fixed when launching from the terminal. any changes to the main branch do not come from any changes to the source code. Maybe it's something related to the discord side. When using the flags the problem is fixed on my side:
If anything gets confusing, I apologize, after all, it's not my native language. but the latest merges do not affect the problem of lags in streams, after all, the PRs that corrected this are also affected by problems with lags and crashes. i use amd 6750 xt freeworld vaapi |
|
this is the pr I'm using, #489 the most recent ones suffer from the same problem. some also do not play sound in the case of the "main branch" currently. something interesting to say is that when using the official web discord my friends got lags. "https://discord.com/channels/@me" something I've never seen when using discord web through Google Chrome.
audio not capture in vesktop error main branch: I hope it helps |
|
In case you want to hear a funny story to tell your friends or family, here is one So for some reason today I was not able to reproduce the issue anymore And... I couldn't reproduce it anymore... I was starting to think my account was limited yesterday somehow, BUT then the only thing that changed from yesterday was the discord client where I was testing the stream output with my discord alt account... It turns out when I use my other computer I just fixed today which has Vesktop, the stream mostly looks fine, then if I try again using an android device the stream messes up the same way as yesterday, it also messes up with a web client... AND with ANOTHER computer using a regular discord client on Ubuntu. So to be sure I'm not crazy, I had an old windows install, I started a screenshare from a regular discord install, then joined again with my other account on the phone I was testing the stream with, and it was working fine from all those devices. Then again, I switched to the official discord client on my laptop which was showing the stream just fine with Vesktop, then the issue came back again. So long story short, it all depends from the client you are using to watch the stream, AND if you have selected an audio source... I also tried an old version of Vesktop and fired up a stream the same way, so it always happened for me. What changes when looking at the RTC debug, is the following:
Also I noticed that the bitrate section disappears and reappears after a couple of seconds, meaning it may be resetting itself somehow? |
|
Red stripe is when my android phone joined the stream. Dropped the bitrate to ~30Kbps I'm re-testing with a couple of friends, totally client dependent, I had my friend join with a Windows discord client first, and he was watching the stream correctly, then another friend with an android phone joined, the stream was still fluent. Re-made the stream with the same friend with the android client ONLY and the bitrate was back to 30 Kbps~ and quality totally crap. Also, if my friend with the Windows computer joins later, the entire stream bitrate fixes itself.
I made them also change the connection from wifi to LTE but nothing changes. Probably depends on the phone capabilities and what video or audio decoder they use... I suppose EDIT: |
|
@sysrq-reisub Can confirm. EDIT: I tried streaming from my alt account (Vesktop) to my main account (Official Discord) and the bitrate drops again. |
i believe the bitrate drop only occurs when someone starts watching |
|
Retested with friend on Windows and when he started watching stream bitrate dropped to 30, so most probably it's not depending on client. |
It does but from what I have experienced happens only when a client has a specific decoder.
So far 100% of the times the stream fixes itself whenever I join with the Vesktop client on my laptop with my alt account or with a Windows client with hardware acceleration enabled (but in this case depends from the video card decoder I suppose) Tried with Windows myself, also found another Discord bug whether the Hardware Acceleration its not enabled anymore after toggling it off an on, and requires local user data to be deleted... But in any case the windows client acts differently every time, I couldn't 100% reproduce it, sometimes the decoder is ffmpeg, other times "electron" as seen from the debug page and hardware usage However, one thing I am certain of is Vesktop uses 100% of the times WebRTC as video decoder, and the stream is always perfect in that case, and fixes it for everyone else |
|
Attempt using NOTE: Uncertain if the |
I built the latest vesktop version and now there is no audio channel, even if I choose it in the audio source list. |
|
try building #531 instead |
Thank you! EDIT: My brother installed Vesktop on his Windows 11 PC and my stream works perfectly with audio source. |
|
i have been able to confirm that the bitrate is lowered to 29.17kbps on my machine when streaming with audio AND someone is watching, but as soon as someone else starts watching (total of 2 viewers) the bitrate gets raised to around 1400kbps. This issue is even more strange than before, and I am entirely at a loss as to how we should go about fixing this. Here's to hoping someone has an idea lol. |
Also, I cannot confirm that this is the case, as it was very sporadic as to whether or not it happened, but it seemed to not be an issue when I had someone watching from a web client. This needs more testing to be solidified as a cause though, but if it is, it may be an issue/change to discord's server systems. |
Oh yeah you're right. Audio indeed does not work. My apologies. |
|
So I upgraded to the latest git repo, audio now works fine "Bad" clients:
"Good" clients:
Also, apparently you just need one of the "good" clients to fix the stream for everyone. I made my alt join my streams so everyone can look at them without it being a slideshow This is what you see when using Vesktop as a client, then rejoining the stream with a regular discord client on a Linux dsitro, and joining again with Vesktop fixing the stream again. 34f1234f1.mp4This is what was happening on my computer where the screenshare started while I was recording the previous video, you can see the drop to 30Kbps then it up again. f3wwdfsd.mp4 |
With the latest commit audio should work |
I am lost for words lmao |
This might be more of an issue on Discord's side than Vesktop or really anyone; besides the audio issues I suppose. There's literally an ongoing bug in Discord Canary which makes voice chats absolutely unusable as it plays back garbage, unintelligible data. |
It was caused by a broken build of discord_voice and was fixed in ~24 hours. Anyone who still has the issue has not updated since. An irrelevant point nonetheless as it does not pertain to WebRTCMediaEngine. |
This worked for me on the latest Vesktop flatpak. As weird as the workaround is, at least there's something we can do until this gets fixed. |
|
has anyone found a solution to this? |
This issue was not present before #489 though. Now the issue is completely different. |
This bug is not regression after #489 because Discord did something on their side right after we fixed almost all of screensharing. You can try to install Vesktop at df05d12 commit before #489 merge, and you will get the same bitrate drop. Also, as mentioned upper, this bug is reproducible even in native discord web version without Vencord and/or Vesktop. |
Oh shoot, you're right. |
We actually had perfect streaming while developing for about 2-3 days :D |
YES! Then I'm not crazy!!!! |
Specifically for Web Clients, but it looks like it. I was trying to stream to 3 unmodified, desktop Windows discord clients, at least one of which is using hardware acceleration. One of the windows users tried to stream the same thing instead, absolutely zero issues for anyone. I know this isn't a very detailed report, I haven't really chased down the others for their discord settings that much. Either way, this last week there's been plenty of streaming in my group, and I'm the only one having issues. I am also the only one using Linux & Vesktop. I'm a little more pessimistic about Discord fixing it quickly, personally. How big is the user-base of 'web client users that are trying to stream' ? I vaguely estimate it's less or equal in size of 'Linux users trying to stream'. That user-base has not been able to stream properly for years, Discord doesn't seem to care. (1) The only way to stream with audio on Linux is through the awesome community effort of Vencord and other 3rd party clients. (1) They acknowledge as much on their support site, near the start: |
Have you submitted a bug report to Discord? I haven't found anyone talking about this issue outside of this thread. |
I submitted, but I do not believe that they will do anything about it. |
I hope they do, as this is quite a large problem for all web users |
|
I though my laptop performance magically just died until i found this, glad to know im not crazy! Im totally experiencing the same main deal, screensharing was perfectly working until i switched from fedora 37 to 40 and gnome 6, because of this i was already blaming the entire os Having discord releasing update almost after fedora 40 came out really blured up everything |
Vendicated
added
wontfix
|
Okay, here are some updates. |
It looks to me like the consensus is that this is entirely fixed. I think this is ready to close :3 |
|
Awesome :D |
|
Looks like it was fixed between Vesktop and some Android clients, a week ago, but now I'm reproducing the issue again, same with Vesktop and Firefox, Vesktop and Windows works fine though. |
|
I'm also having this issue, turning off audio on the stream makes the bit rate go back up. |
|
This is still a problem. Using Fedora KDE with latest version of Vesktop |
|
I'm also experiencing this problem in Bazzite Fedora KDE, using Vesktop. Updating Vesktop to the latest did not fix for me. Viewers of my streams say the picture looks much better when audio is disabled. |
Same issue in my setup, looks like Discord upstream broke screensharing again. |
|
Yes, the issue came back, but it does not to seem as problematic as before. |
|
So I found a workaround for this problem. When you start a stream with audio on vesktop a new audio node is created called Stream with Stream with |
|
While this is a little dumb we could also automate this (wait until Bitrate Hits a specific threshold and only then start Venmic) |
I have the same problem, and your solution helped me, maybe, to reopen the issue? |
I do believe that the issue should be reopened. It is still clear that people still suffer from this, including me. |
This is not something we can fix. This is either a discord web (more likely) or electron / chromium issue - I don't see why this issue should be re-opened, raise an issue on the corresponding project-side instead |
and others
Describe the bug
I can stream fine with or w/o Hardware Acceleration enabled until I turn on the audio source for any application, choosing entire audio or specific applications does not matter
To Reproduce
Expected behavior
Video quality remains the same when an audio source is selected.
Screenshots
Those are the streams output, in both cases the frame rate is terrible, a single frame is refreshed after a couple of seconds
Quality changes depending whether "prefer smoothness or "prefer clarity" is selected
Screenshare without selecting an audio source
Frame rate is stable, quality is excellent, tried a fast pacing video game, encoding works correctly as nvtop shows.
This is after selecting an audio source after the screenshare was started, with "Prefer clarity" choosen
You can see a sudden drop in frame rate
This is when "Prefer smoothness" is choosen, video resolution drops to 480x270
This is the audio section. Doesn't change much I think.
Desktop (please complete the following information):
My setup also includes
Vesktop versions tried:
Command line output
Started with the following parameters, also enabled venmic debug in case you need it:
VENMIC_ENABLE_LOG=1 pnpm start
Output too long. The rest is here:
cmdline_output.txt
Additional context
What I tried excluding was:
Also
OBS correctly records with audio when using the VA-API Video encoder, looks like only Vesktop is affected.
vainfo output:
However, it looks like even after disabling "hardware acceleration" on the settings and turning off the encoding support cmdline flags in index.ts the issue is still present.
May not be related to VA-API video encoding.
I haven't found any issue similar to mine
Sorry for the TL;DR
The text was updated successfully, but these errors were encountered: