Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Youtube probably have stats on viewer-happyness vs bitrate.

I would take a guess that a higher bitrate = longer loading times, and viewers care far more about an extra few second of buffering than they care about audio quality, especially when they don't have the original to compare to.



The audio data is miniscule compared to the video data, and the size of it is tied to the video quality level. And everything is streamed in chunks. It'd only amount to milliseconds of extra buffering.


Not as insignificant as you might imagine, especially if you are talking about surround sound audio.

With newer codecs, doing 4k with 2Mb/s isn't unheard of.

For audio, on the other hand, 32 or 64kbps per channel isn't unheard of.


At 1080p60, YouTube uses 12Mbps, and 251Kbps Opus or 192Kbps AAC. That's a factor 50 smaller. Insignificant.


> At 1080p60, YouTube uses 12Mbps

It does not. That's a recommended bitrate for a live streamer (Streamer -> youtube).

Coming out of youtube, the numbers are quiet different.

For example, a random 4k video I just pulled had a video bitrate of 4.5Mbps.

A 720p video I pulled of a talking head had a 369kbps video stream.

That is to say, a podcast style video is likely to have a nearly 50:50 split on audio/video.


But now you're comparing median video bitstream with peak audio bitstream.

YouTube uses variable bitrate for audio, which can vary dramatically in size. Your example of podcasts or "talking heads" is actually perfect. Most encoders are extremely efficient at compressing voices, as they will only have to encode 30-300Hz, and voices have less data variation than images.

Image encoding is just very complex. It'll get better and better, but audio encoders of the same generation will also improve.


251 is codec format ID. Real bitrate is around ~135 kbps


Totally missed that, thanks!


Couldn’t you do adaptive Bitrate and start streaming low-bitrate for a few seconds and then switch to higher quality once the video is already playing?


Yes it's very possible to do this. Without seeking support it's trivial, just instruct the encoder to encode with a low bitrate for a few seconds and then increase it.

To support seeking you could encode a low bitrate stream, and a high quality stream, and then a number of ramps between these. So when you seek you start with the low bitrate stream and then after a few time units go on the ramp to the high quality stream.


The stream is already being split into chunks (identified in the m3u8 file) so encoding tricks like this won't be necessary.


While nothing that's been said here is inherently wrong per se, a sample YT page load is ~5s to DOMContentLoaded, and without counting the video content, transfers ~7 MiB worth of requests & ~95 requests for me, and visually, the entire page feels like it loads twice. (I thought it was redirecting, but the inspector says nope, that's a single page load.)

… while yeah… a lower bitrate upfront might lower the required bandwidth and thus, latency, to get enough of a buffer to start playback … all the bloat on the page would be a better first port of call.


I assume most viewers will already have most of the youtube javascript warm in the cache...

How much is loaded for a navigation from one video to the next?


YouTube’s most common audio codecs Opus and AAC use variable bitrate (VBR) by default.


pretty sure they already do this.




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

Search: