Hacker News new | past | comments | ask | show | jobs | submit login

Exactly. I'd much rather wait a minute and buffer more video at reasonable resolution and bitrate, rather than switching to something unwatchable.



> I'd much rather wait a minute and buffer more video at reasonable resolution and bitrate, rather than switching to something unwatchable.

A full minute of buffering would only give about 5% more bandwidth for a typical 22 minute TV show. That’s not going to transform it from “something unwatchable” to the higher bitrate video you want.

It will, however, cause a large majority of people to give up on the stream. The number of people who would actually prefer 1 minute of buffering for negligibly higher quality is almost nonexistent.

This is why buffering is futile: Once a stream gets to the point of stopping to buffer, the mismatch between available bandwidth and the encoded bitrate is just too great to reasonably overcome.


> That’s not going to transform it from “something unwatchable” to the higher bitrate video you want.

YouTube is very aggressive about switching to bad quality if it thinks the connection is bad, which happens often due to transient issues on cell networks or occasionally wifi. All of a sudden a video will drop to 240p, for instance, reminding me "ah, it reset itself to 'auto', I never ever want 'auto'".

A minute of buffering isn't enough to make an incredibly slow connection fast. But a minute (or potentially less) of buffering is enough to paper over transient connection issues.


This might be true on a wired link, but on wifi, it's not unusual to see bandwidth drop well below the mean throughput for 10s of seconds. One minute of buffering is enough to hide those issues. In many cases the quality drops during those times and then never goes back up again, so I'm stuck looking at giant macroblock artifacts for the rest of the movie (unless I hit stop and start playing it over again).


What streaming service falls back to lower bitrates and stays there? YouTube and Netflix are both usually very aggressive at switching back up to the higher bitrates as soon as it detects the connection has recovered to higher speeds.


Amazon Prime video is the worst at this; Netflix also does this when I play on my old BluRay player, but not in the browser.


I think you're talking about a different use case then OP.

For your point, an example is viewing 1080p on 64kbit/s is unreasonable and nothing will fix it.

For OP's point, I can imagine viewing 1080p (10Mbit/s) on a 1Gbit/s connection means a little buffer will solve the need for ABR as random packet loss or minor drops can be recovered with retries seamlessly as opposed to dropping quality to ABR.

So buffering is futile only when bandwidth is not sufficient, and even there its questionable, perhaps user might just want to download and view after that's complete rather then have poor quality.


You still have buffering with abr.


I believe this post covers the most common use case of Twitch, which is live streaming. You don't want to be a minute behind the video when chat is live.


I’m not sure, since most people don’t interact with chat.

Personally I use yt-dlp with mpv and have the buffer set very large. This allows me to pause the stream when I take a toilet break or similar. When I come back I can also skip ahead through ads or idle times on the stream, or watch at increased speed to catch up if needed.


You're saying "exactly' but then state the opposite...


Clearly I misinterpreted what the post I was replying to meant by "stutters". More importantly, I misread that post's "Yes, absolutely. Vastly. Hugely." as a response to the rest of the post before that, rather than a response to the question at the end of "Am I in the minority here?".

I was thinking of experiences on YouTube where it refuses to buffer enough to allow playing the whole video, leading to inevitable stutters.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: