> The current implementation only works in Chrome. Before you assume we’re kool aid drinking Google evangelists, or simply just lazy, there is good reason for this — likely due in part to Google’s work on Project Stream, they have introduced “low delay” mode for MSE that sets up a push model for video frames rather than the traditional buffered pull model. This is also good for any kind of low latency video stream, not just game streaming. When in low delay mode, Chrome begins to break the rules of MSE and no longer requires buffered playback. It also starts to ignore certain timing information and keyframe requirements.
> ...
> This is not to say that one couldn’t get a decent working implementation in Firefox, but Chrome’s low delay mode works in the ideal way without having to complicate the implementation or diverge too heavily from the way Parsec’s native applications behave. And while we love Firefox, the harsh reality is that 82% of Parsec users are using Chrome, with only 5% using Firefox, which made us more comfortable starting with a Chrome only implementation. For Firefox users, you can always use the Parsec native applications, which will probably perform better anyway .
I think this is quite sad to see. It’s not really game streaming tech in a web browser, it’s game streaming tech in Google Chrome.
What happens if Google decides they don’t want to play with other streaming services? They’re only a quick auto update of locking Parsec services out.
I know both people from both the MSE team and the Project Stream team.
Project Stream doesn't use MSE (it uses WebRTC) and the code in Chrome to detect live streams and optimizing them has been around long time, (see, for example, this change from almost 4 years ago: https://codereview.chromium.org/692323002) and they've steadily added better support for live streams over the years. It's not "game-streaming tech in a web browser". It's just a few simple heuristics to function better for low-latency streams. You can read the code for yourself if you'd like:
Coincidentally, we're at FOMS right now talking to other browsers about standardizing an explicit signal that will provide additional effects on MSE buffering and audio preroll size.
Other than escaping the bloodthirsty data-slurping of the Google ecosystem, I don’t see that solution being much better.
If they have to make their own proprietary browser, the situation will just be streaming “with a client you need to download” rather than “in the browser” generally.
(Disregard this if I’m misunderstanding and by “their own browser” you meant an existing project like Firefox.)
> ...
> This is not to say that one couldn’t get a decent working implementation in Firefox, but Chrome’s low delay mode works in the ideal way without having to complicate the implementation or diverge too heavily from the way Parsec’s native applications behave. And while we love Firefox, the harsh reality is that 82% of Parsec users are using Chrome, with only 5% using Firefox, which made us more comfortable starting with a Chrome only implementation. For Firefox users, you can always use the Parsec native applications, which will probably perform better anyway .
I think this is quite sad to see. It’s not really game streaming tech in a web browser, it’s game streaming tech in Google Chrome.
What happens if Google decides they don’t want to play with other streaming services? They’re only a quick auto update of locking Parsec services out.