4 ms·
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?
by echoangle 2y ago
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?
- mungoman2 2y agoYes 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.
- kccqzy 2y agoThe stream is already being split into chunks (identified in the m3u8 file) so encoding tricks like this won't be necessary.
- KeplerBoy 2y agopretty sure they already do this.
- supertrope 2y agoYouTube’s most common audio codecs Opus and AAC use variable bitrate (VBR) by default.
- deathanatos 2y agoWhile 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.
- londons_explore 2y agoI 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?