Implement QUIC (HTTP/3) support for media streaming

[rootbeerdan 4]

The main thing that would need to change to implement this feature:

• Client apps need to check for a DNS HTTPS RR or respect server Alt-Svc

I would say this is the most important part of the feature request, as anyone who really cares about squeezing the most performance will already be using a reverse proxy like Caddy or NGINX, which have both implemented QUIC already.

The "nice to have" feature for people who don't use their own web server (and also probably a ton of work):

• Built-in web server needs to advertise alpn=h3,h2 and bind to UDP

This seems like an inconsequential feature, but it's actually incredibly useful for folks who like to connect to their Emby server far away or over networks with high jitter and packet loss like LTE/5G (increasingly common with 5G FWA becoming mainstream). Connection ID tracking would be even cooler (although AFAIK not completely implemented in .NET as of late), so folks moving between networks don't have their stream drop. I spent some time implementing it for an internal app for live video streams at <job> using quic-go and the performance impact is noticeable and significant on congested networks (and more importantly, not worse than http/2 in low-loss scenarios like a local network). The one thing I was caught on is WebSockets, I'm not sure how much Emby uses WSS (outside of knowing that it uses them), but this feature request is mainly about reducing the amount of time Emby is spending loading the menu or media itself on iffy or otherwise congested networks, so it might be outside of the scope. Unencrypted HTTP is also out of scope, since there's no such thing as unencrypted HTTP/3 (IIRC local connections use IPv4 + HTTP only).

I noticed that the Emby Web Client will happily work over HTTP/3 with my Caddy server in front of it, and it even shows up in the Activity dashboard as HTTP/3 when I log in, so I hope that it's a simple change on the rest of the Emby clients (we can all dream). Also happy to help out testing/implementing if it would speed things along.

[Luke 37110]

HI, in terms of Emby clients, there's nothing we really need to do as we don't handle the low level networking ourselves. That sort of improvement will generally come for free when the device/browser/operating system supports it.

There are some exceptions where we embed our own player. For instance on android we use exoplayer, so that would need to support it. On iOS and Windows we use mpv, so it depends on whether that supports it or not.

In terms of the server, we're currently running .net 6 and http3 is marked as experimental with it. We haven't enabled it though. When we move to .net 7, we'll reevaluate that.

[shorty1483 453]

On 10/4/2023 at 1:50 AM, Luke said:

HI, in terms of Emby clients, there's nothing we really need to do as we don't handle the low level networking ourselves. That sort of improvement will generally come for free when the device/browser/operating system supports it.

There are some exceptions where we embed our own player. For instance on android we use exoplayer, so that would need to support it. On iOS and Windows we use mpv, so it depends on whether that supports it or not.

In terms of the server, we're currently running .net 6 and http3 is marked as experimental with it. We haven't enabled it though. When we move to .net 7, we'll reevaluate that.

Does .NET 8 implementation on beta server support it?

[Luke 37110]

17 minutes ago, shorty1483 said:

Does .NET 8 implementation on beta server support it?

The runtime does but haven’t had a chance to test in Emby yet.

[shorty1483 453]

Will test if current beta goes into stable. QUIC support is the only thing holding me back from ditching Caddy and use Emby without reverse proxy.