Chrome 75 Beta Released With Low-Latency Canvas Contexts, RTC Improvements

[phoronix]

Phoronix: Chrome 75 Beta Released With Low-Latency Canvas Contexts, RTC Improvements

Following the recent Chrome 74 web browser update, Google has now promoted Chrome 75 to its beta channel...

http://www.phoronix.com/scan.php?page=news_item&px=Chrome-75-Beta-Released

[andyprough]

If you like the performance of Chrome but don't like the incessant Google data slurping, you might want to try ungoogled-chromium. Downloads for several distros and an app-image are available here: https://ungoogled-software.github.io...mium-binaries/ . I've been having excellent experience with it.

[discordian]

Still waiting for the videos being decoded with hardware.

[Orphis]

It's not "RTC", it's "WebRTC".

Still waiting for the videos being decoded with hardware.

Which hardware decoder do you want to use? The one that fails to decode a valid bitstream or the one with a terrible latency? Or do you prefer the one that crashes randomly?

[discordian]

Which hardware decoder do you want to use? The one that fails to decode a valid bitstream or the one with a terrible latency? Or do you prefer the one that crashes randomly?

Latency doesn't matter for watching videos, otherwise I would be content with what tools like mpv are using.

Curiously the utter troublesome access to rendering hardware (lockups, resource exhaustion, driver bugs) via WebGL is available, so there kinda problems obviously aren't showstoppers for adding a feature.

[Orphis]

Latency doesn't matter for watching videos, otherwise I would be content with what tools like mpv are using.

Curiously the utter troublesome access to rendering hardware (lockups, resource exhaustion, driver bugs) via WebGL is available, so there kinda problems obviously aren't showstoppers for adding a feature.

Latency does matter when you watch video! Especially to avoid desync between video and audio in a movie (I've seen related issues). Or when doing real-time communication (I've seen more issues there).

The trick is that WebGL related issues can be worked around usually and are well understood. The rendering part of the drivers is used a lot more on any device. The decoders (and encoders) though aren't as well tested by the HW makers and will often choke by parts of the spec they never or insufficiently tested (but claim to support).

To be honest, we find issues in SW decoders or encoders all the time, even for the current generation formats. Issues are fixed quickly. So I can't imagine the same with the HW ones.

[discordian]

Latency does matter when you watch video! Especially to avoid desync between video and audio in a movie (I've seen related issues). Or when doing real-time communication (I've seen more issues there).

Aslong the latency is stable and known, there is no issue when it comes to (noninteractive) video. you will need to do skew correction anyway between video/audio.

The trick is that WebGL related issues can be worked around usually and are well understood. The rendering part of the drivers is used a lot more on any device. The decoders (and encoders) though aren't as well tested by the HW makers and will often choke by parts of the spec they never or insufficiently tested (but claim to support).

To be honest, we find issues in SW decoders or encoders all the time, even for the current generation formats. Issues are fixed quickly. So I can't imagine the same with the HW ones.

Would have helped if formats are developed in an open consortium, with multiple implementations and conformance checks. I was able to play youtube videos on my Sony PSP's webbrowser 15 years ago, its mind-boogling that this is still an issue.

Let me guess, the problems are not with the formats I referenced (h264/h265), but actually allowing HW-acceleration, even as manual opt-in would make the VP8/VP9 "our buggy bought source is the spec" disaster a bit too transparent?