I work on a team that is developing a browser based video application. We have been experiencing an occasional severe degradation in the quality of our video starting around November 2022. It happens during a call and continues until the call is ended (the connection is ended), and appears to be a decoding issue (the screen looks pixelated/discolored but you retain some idea of the 'shape' of objects on the video feed).
We use Pexip which acts as an MCU between participants, and have validated from Pexip's outbound packets that it is sending a clear video stream, however on the browser we see the issue nonetheless. This is only seen on a single participants video stream.
The issue has only been seen on Chrome and Edge which default to VP8, and has not been reproduced on Firefox (defaults to H.264). This leads me to believe it is an issue with Chromium.
I have struggled to find any logs that relate to the start of the issue, and am asking if you have any suggestions on where to look on Chrome's logs to find any indication that an issue has started or to understand more about why the issue is happening?
We have tested on Chrome/Edge/Firefox browsers, and the issue only happens in Chrome or Edge (Chromium based). We have tested on a wireless or wired connections and the issue shows in both cases. We have tested on Windows and macOS and it happens on both. We have also tested on a freshly rebooted computer with no other applications running, and the issue still shows. There is nothing interesting happening on CPU/Memory/Network utilization when the issue begins.
Related
I'm running three Icecast servers, all streaming the same content. Since about two weeks, I got some users reporting that they cannot listen to the stream anymore. Their browser is trying to load the stream but it never starts playing. I started to dig into this a bit and I am able to reproduce the issue.
It's interesting that this issue does not occur on all devices. I got two PCs here, both on Windows 10, both running on the latest Firefox. One can stream without any issues, one starts downloading audio data but never plays it. Opening the Icecast mountpoint in VLC works in all cases and the stream starts within a second or so. On a device that is not playing the stream in Firefox, it neither works in Chrome. On the other hand, devices that are able to stream in Firefox also are in Chrome. I guess it has something to do with the OS..?
I started Wireshark on one PC that is affected by the issue and was able to see that the browser starts to download the audio data from the Icecast server but instead of playing it, it's caching it. I believe that the browser somehow "thinks" this is a download, not a stream. When I restart the Icecast process on the server during this caching period, the caching of the browser stops and it starts to play - but only for a few seconds, until the end of the cached stream is reached.
I assume that some browsers are waiting for some kind of EOF instead of just playing the stream. Of course, an EOF is never sent in a live stream.
Here is the link to the mountpoint of one of the Icecast servers: http://185.80.187.35/live
It seems that it doesn't matter which one of the three Icecast servers you use. If one works, the other two also work. If one doesn't, opening the stream from the other servers fail as well.
I have no idea what's happening there. Since the issue occurred, nothing in the setup has been changed. I tried to switch the audio format from MP3 to OGG, but this didn't fix the issue - so I switched back to MP3. I'm currently streaming at 64 kbps. I don't think this might be an issue since this worked for years, but might it be that such a low bitrate is not supported by some browsers any more? Should I raise the bitrate? Maybe add some HTTP headers to the Icecast config? I'm confused and running out of ideas.
PS: I just noticed that I got the same issue in Edge and IE. It really seems to depend on the PC, not the browser.
When the embedded player doesn't work on a device, the stream on its' own tab doesn't play either.
This is not the behavior I'm seeing.
The site is HTTPS, yes, but the stream isn't.
Due to new security restrictions, this is no longer valid. If you open your browser's developer tools, you'll see errors about it.
You need to enable HTTPS on your Icecast server, or downgrade your site to HTTP if you want to play from non-secure origins.
I have no idea where can I actually get help for this, so I'm hoping I'll get some pointers on where should I post my issue.
So we're supporting a radioplayer application that lets you play streams on chromecast devices. We've received more and more reports of streams stopping after a few seconds.
Inspecting the chromecast receiver application we found an error:
error: MediaError {code: 3, message: "PIPELINE_ERROR_DECODE: Format conversion failed."}
Ok, so it has an issue with decoding the stream. Just to keep the fun in funeral it turns out that it works on a chromecast gen1, but not on a chromecast gen3 or a home mini.
So we did what every normal developer would do: gave up and went to work at McDonalds created a sample webpage, with the streams (to leave out all the mess that comes with casting stuff). Tested this page in different browsers and browser versions: works everywhere except chrome. And not just chrome. If your chrome version is 66 or below, happy days. If its 67 or newer, the playback will stop. In the browser we get a slightly different error message, but since stops pretty much at the very same point where the chromecast does... I seem to see a common factor there.
Here is the sample page: http://chromecast.radioplayer.aerian.org/test.html
To tell a couple of radio stations to go and fix their streams would be feasible... but we're talking about potentially 50-90 stations, who's streams are otherwise working, except on a chromecast.
Is this a bug? Is this a feature?
If its a bug, where should a raise it? If its a feature would you like onions with your burger?
I've raised a bug report with chromium, turns out it's a bug. It's being fixed in V75. More details here: https://bugs.chromium.org/p/chromium/issues/detail?id=956027#c7
Hi I'm getting the error
Error creating WebGL context.
Uncaught TypeError: Cannot read property 'getExtension' of null
This is happening on google chrome 71 but I find it odd because if I open up dev tool and refresh the page it works perfectly fine I'm at a loss to what is causing this any idea's ?
It's worked perfectly fine untill today nothing has changed on the PC or browser. My drivers are all up to date, webgl is enabled...
if you have two GPU installed on your system you might want to try to enable
Override software rendering list
in chrome://flags/
I'll leave this here for anyone else apparently it's a browser and graphic card issue
mrdoob: The graphics card is only one of the reasons why the context
can't be created
https://github.com/mrdoob/three.js/issues/4927
This seems to be why unless anyone else has any other ideas...
The issue is on going and not fixed it would be interesting to know why this happens though and why opening dev tools and refreshing resolves the issue for me.
EDIT-
Apparently for me this was due to my graphic card being blacklisted because it's old.
The fix for me was manually enabling WebGL acceleration under Chrome’s feature flags: chrome://flags/
I have encountered this several times with THREE.js. It arises for me once memory resources are shared, abandoned, or overwhelmed, for example:
I have a good render loop but then I introduce long tasks.
I perform extensive, continuous testing. As I modify live settings in Chrome Inspector, THREE does not reflect all changes without fail. Memory may not be released until I restart.
I leave the program running overnight. The next morning the browser is froze, black, OOM...
I use multiple instances of a resource, for example
Web Audio and Magenta Music. The quality may perceptibly degrade and
throw its own errors, but... I will also encounter worse silent
errors. For example when I also steam music in another tab, or click
audio/video media on Twitter... frozen browser, black screen, WebGL
context loss.
I just wanted to comment that I saw this due to other unrelated errors in my app that got thrown first.
I updated my graphic drivers (NVIDIA) and didn't restart chrome nor the PC, and was having this issue.
I just restarted the PC and now it's fine.
This was resolved for me by simply installing the latest and restarting my browser - thought I'd add it here to hopefully save some future soul from wasting an hour like i did.
Error creating webGL Context in three.js.min ver 93
I had the same problem with Chrome version 104.5112.102 and managed to fix it by going to Chrome, Settings, and switching off the
Use hardware acceleration when available.
the graphics card is an old GE Force 8600 card running on Windows 10.
For me, I restarted my computer and the error did not appear again. You can try doing this before you do anything more complicated.
Chrome (on Win and Linux) was unable to load https://apscatalog.com.
Though all other browsers and Chrome on Mac was able to load site with no warnings or errors.
Even external tools say that everything is fine: https://www.ssllabs.com/ssltest/analyze.html?d=apscatalog.com
How can I fix this issue?
Update
It seems to be a Chrome bug. Chrome v.33 works fine while v.32 fails
I would say, that the they have some broken appliance (firewall, load balancer...) in front of it. From wireshark I see the Client Hello from Chrome, but it never gets a response, not even an ACK that the packet was received. That's why it's retransmitting the Client Hello again and again until it finally gives up. I've seen such problems with older F5 BIG-IP load balancers (it's fixed in the meantime, but there are still some broken ones out there) but this does not seem to be the case here. So it's probably yet another broken appliance :(
In case you have knowledge of the infrastructure there I would really like to know what device this might be.
Interesting that https://apscatalog.com works if chrome is started with ssl-version-max=tls1:
google-chrome --ssl-version-max=tls1
this is one that is confusing me completely.
This issue doesn't happen with IE, Firefox, Safari ONLY with Google Chrome. (I haven't tested other browsers).
Basically I run my own web server, IIS 7.5, and have a number of development websites on it which will be published and used in production from the same server. As there are a number of websites I must use Dynamic Idle times for Application Pools as resources are restricted.
Usually this wouldn't be an issue and is the way to do things seemingly based on Microsoft's best practices however there seems to be a problem with Chrome loading pages once the application pool has timed out/gone idle.
Now I understand that it takes time for the application pool to restart, which they do within seconds and serve content not long after, but with Chrome the application pool takes close to a minute to start.
This doesn't happen on first load of the website however - it only happens with subsequent loads within the same browser/session.
As I said this does not happen with IE, Firefox or Safari, the other browsers I have tested, the application pool restarts almost immediately.
I had thought that maybe this was a server side issue but since the other browsers work fine I can only figure that it is Chrome at fault. Yet I still want to make sure it isn't actually a server side issue.
Any one have any ideas?
I've just realized I posted this on Stack where it should be on Server Fault.
Sorry.
Anyway, something I wrote in the question prompted me to investigate further and I found this doesn't seem to be an application pool issue, although it could be, but more so a PHP-CGI issue. It might even be localized to my own machine.