[everforward]

Eh, storing and arranging physical media is a pain, as is dealing with scratches.

I find it roughly equal as things go.

The buffering thing genuinely confuses me. I get why it happens at a technical level, but the failure mode is odd. None of the content is live, just buffer the next 5 or 10 minutes to disk and have the player read from the disk buffer.

That should never buffer unless the network is degraded for a long while.

The full solution would be to just let people cache the entire video and watch directly from disk, but I believe that’s intolerable to the IP folks.

[Macha]

I remember when YouTube switched from it's original method of streaming to DASH. The old method was to basically pick a file and buffer up to N time in advance (I think it was based on the media length).

But the original DASH implementation was very aggressive about keeping a minimal buffer size and downgrading quality at the slightest hiccup. I was also on a not particularly great internet connection at the time, so I used to pause 720p at the start and let it buffer enough for uninterrupted playback, but YouTube's changes meant that just buffered like 15s and then shifted down to 360p. There were add-ons to force dash off to mitigate the problem but iirc YouTube was starting to make higher qualities dash exclusive.

Clearly someone at YouTube was optimising to reduce time-to-play and buffering but in a typical metrics driven approach, excluded the possibility that for some videos these were less bad problems than 360p videos. At that time I was watching a lot of let's plays and programming tutorials and most of the people were uploading content recorded and intended for 720p or 1080p, so unreadable text because of quality downgrades was a big problem for me at that time.

Nowadays I just brute force it by having comically excessive amounts of internet (2gbps ftth) so YouTube randomly deciding garbage quality is much rarer, but it still happens sometimes.

[alisonatwork]

I'm so happy someone has explained this, because it's a problem that has bothered me for years and I always assumed it was an issue on my end. It's incredibly annoying when you can't make out what's happening in a video, set a higher bitrate then pause to wait for it to download, and it just freezes a couple seconds past the current point, which ends up making the whole video unwatchable.

I don't know what kind of internet these Google engineers are working with, but for people on shared wifi, or in dense urban areas where there is a lot of interference, or tethering to a 4G phone, or sitting on a train, or a mountain, or using a VPN, or living in a country where the government messes with the traffic, it just isn't realistic to expect users to have a fat pipe that never drops out.

[gruez]

>YouTube's changes meant that just buffered like 15s and then shifted down to 360p.

If you're using the web player and manually set the quality, it should never downgrade the quality during playback. If your connection is too slow it'll just pause while it tries to buffer

[Macha]

This was ~5 years ago, all I can say was that it was definitely not the case then.

[actionfromafar]

Also, if it's a TV, they typically don't have disks, or at least not disks large enough, fast enough, and write wear tolerant enough, to cache data.

[everforward]

Is this still true in the age of the smart TV? I’ve never looked but always presumed they had essentially the guts of a crappy Android phone with the radio transceivers replaced.

They get apps and updates now so I would’ve assumed some semi-reliable persistent storage. This really doesn’t even need to be persistent; resetting on reboot would be perfectly fine.

I’ve no doubt they would struggle to cache “real” 4K, but at the bitrate most of this 4K stuff is sent at, 1 GB of cache should be at least 5 minutes. Netflix recommends at least 15 Mbps for 4K streaming. Even doubled to 30Mbps, that’s ~4MB/s, or about 256 seconds of content cached per GB.