An insight into live video streaming infrastructure at Twitch | Hacker News Reader

An insight into live video streaming infrastructure at Twitch

scaleyourapp.com

84 pointstechPackets27 comments

I remember when amazon acquired twitch. The fact that aws would offer twitch's video delivery platform never occurred to me, but that strikes me as supremely cool for whatever reason.

One random thing I've noticed which jumps into my mind every time I see twitch metioned is that I find youtube's player much better than Twitch's. I'm not even sure exactly what it is I object to about the twitch one, but whenever there is a choice between the two services I prefer the youtube one. Even stranger is that the best player I've personally ever experienced is the one from dood.watch which randomly shows up embedded on shady sites every once in a while. Its weird because I've never seen it used in a non-shady context, and yet it seems to get everything perfectly right: buffering is great, it always perfectly remembers where you are in the video, scrubbing / pausing / etc never randomly breaks it, etc. I'm not sure why it would be the case that this random player is so good, unless there's some weird incentives at play preventing other ones from being as good as they could be.

One thing that bothers me about the twitch player comparatively, is that YouTube will pause/play when you click the center of the video. Twitch requires you to navigate to a small icon

I think that might actually be the issue I have with it too now that I think about it.

Twitch also annoyingly darkens the video when it's paused.

It's also missing the frame-by-frame keyboard shortcuts that YouTube has (useful when inspecting frame perfect gameplay).

I think they stopped adding features in 2015 and it never occurred to them that it might need a change or refresh.

I was also really annoyed at the darker bits, so I wrote some custom css rules for the twitch site.

It also occasionally has React(?) elements fail to render when you go into theatre mode

You can't move the error message without tinkering with the dom in dev tools. Really would be nice if they could focus on the cool stuff in between milking viewers for cash haha

Could there be a patent involved?

Annoying as it is, a functionally better product isn't necessary desired. Twitch is a "free" product, and it's a complete guess, but I'd imagine they add slightly more friction to consume content in order to make them feel more engaged.

I think the percentage of subscribed (paying or gifted) users is way higher on Twitch than on Youtube.

I've always hated watching esports tournaments on twitch. On youtube you can watch them semi-live where you can pause after a game and do whatever, then you can just skip through the timeline to when the next game starts and catch up at 2x speed. On twitch you can sort of do that, but you have to go to switch from the livestream to the vod, and once you're at the end of the vod you have to refresh the page to get more of the vod, and you keep doing that until you're almost live and then you can start watching it live.

Yes, in short my summary would be: YouTube is intuitive, while Twitch's experience feels awkward. YT is also my gold standard.

You can do this with yt-dlp and mpv: Just feed twitch url to mpv, pause the stream and let it cache (not sure if you'd have to adjust cache size, I have it set to huge anyways), then adjust speed / skip anyway you want.

i find youtube '480p' much higher quality than twitch's too

This likely has everything to do with YouTube using VP9 vs. Twitch using h.264. Twitch has flirted with using other codecs like VP9, h.265, etc, especially in markets where consumption is incredibly Android mobile-centric, but ultimately I think they're making their big bet on an AV1 implementation for the next codec choice.

OP says Twitch uses AWS IVS. And IVS says:

> Codecs: Amazon IVS supports H.264 for video and AAC (LC) for audio.

> This likely has everything to do with YouTube using VP9 vs. Twitch using h.264.

There's nothing inherent about VP9 over h.264 that will make it look better. Especially when delivering a downscaled stream (480p when the source is 1080p or 4K) the pre-encode processing (scaling, filtering, etc) is going to matter more than the codec in most cases. Just in downscaling video, a Lanczos filter vs bicubic makes a lot of difference even using the same codec, profile, and bitrate.

I suspect it may have more to do with YouTube having higher bitrates. Video games during interesting moments (e.g. Vampire Survivors) don't compress well regardless of your codec choice.

https://support.google.com/youtube/answer/2853702?hl=en#zipp... (1080p60 goes up to 9k)

https://stream.twitch.tv/encoding/ (1080p60 goes up to 6k)

Youtube has higher quality and lower bit rates than Twitch.

Maybe due to saving computing-resources used for transcoding?

> I'm not even sure exactly what it is I object to about the twitch one, but whenever there is a choice between the two services I prefer the youtube one.

I know exactly what it is. Latency.

When I press play in Youtube, it plays. In Twitch it takes probably 3 seconds to get going. Worse still, this delay happens every time you seek in a video. Trying to find something you're interested in in a longer video on Twitch is an exercise in frustration.

This reads like a copy of https://blog.twitch.tv/en/2022/04/26/ingesting-live-video-st... with some IVS content marketing slathered on top

even has the same diagrams

Blogspam, in other words.

I wrote the article and I would disagree with you. The article that I wrote is a summary of three blog posts actually a series written by Twitch on their live streaming module. It isn't a copy of just one article.

The entirety of Twitch's git repositories (with commit history even) got leaked a while ago. If this post sparked your interest and you don't have any ethical concerns it might be wise to check them out.

Their web interface should use the <video> and <audio> HTML element pointing to an URL any noscript/basic (x)html browsers could pass to an internal or external media player. In case of non-live streaming, in the URL, seeking should be provided by standard URL fields (total time/and start time/maybe speed x0.25 for fancy), that to allow independent media players to know how to seek. I think apple HLS has standardized that.

Anyone else thought this was super light on details? My only takeaway was that they replaced their edge HAProxy with a custom proxy to do more intelligent load-balancing across data centers. Feels like a lot of text to describe this.

Not a single mention of ffmpeg, I assume they heavily relied on it until hardware encoder/decoder took over?

Reply on news.ycombinator.com