DescriptionIt's currently possible to create a multi-bitrate HTTP Adaptive Stream by using the -b flag.
However, if the video is high-resolution (say 720p or 1080i) then lower bitrates simply increase the compression, leading to diminished playback quality.
It'd be good to be able to instead (or if possible, as well) pass in a list of resolutions instead so that the player can step down to a lower resolution instead (rather than getting more blocky video at the same res)
Activity
2017-07-19 09:45:20
For VoD streams, could potentially pass just the resolution in, then in post-processing calculate the average bitrate of the stream and update the master manifest, but that won't be an option for linear streams (as there's no post-processing stage).
Being able to drop resolution has some very useful applications to Ultra-low latency HLS though (which is why this is a child of HLS-25)
2018-02-03 09:42:28
I do have some misgivings about this functionality though, based on player behaviour.
VideoJS for example, when used with the HLS plugin, tries to be a bit too smart for my liking. IMO it risks degrading the user's playback experience:
Say we have a video with the following bitrates/resolutions available:
- 2Mbps at 1080p
- 1Mbps at 720p
- 768k at 600x400
- 512k at 300x200
and you visit a webpage where, by default, the player is contained in a
VideoJS will detect that the highest resolution it currently needs to fetch is
All well and good so far (as there's no point in fetching a 1080p stream for a
However, the issue starts when you click the fullscreen button. Your window size is now (say) 1080p, so the player decides it should try and get the 2Mbps stream.
Unfortunately, you're on a 1.5Mbps connection, so can't fetch it fast enough. You've now got (fullscreen) slightly stuttery playback until the player realises it's going to have to fetch the 720p instead. Equally badly, for a short period before that stuttering, you've had some
It could all be avoided by the player not being so damned smart. If it had been basing decisions on bandwidth alone, then there's a reasonable chance you'd have been on the 720p stream by the time you clicked fullscreen, and the resulting change in displayed resolution would have had no impact.
It is, of course, an exercise in saving bandwidth (as it is fairly wasteful to deliver 1080p if you're only going to display it in a small container), but speaking personally I much prefer the user experience without this behaviour present. I'd prefer (if anything) that certain bitrates were potentially discarded on the basis that the display can't handle that resolution (so a tiny phone will never try the 4K rendition, for example) but even that's less than perfect.
There's more information on this player behaviour (including how to neuter it) here - https://github.com/videojs/videojs-contrib-hls/blob/master/docs/bitrate-switching.md - but I guess the point I'm trying to make, is that caution should be used when using this feature (once implemented) as it may potentially degrade the playback experience. Although I've used
So we'll need to find a (much) more concise way to note that in the README too.
2018-02-03 09:52:23
- Function
- The iterative loop will need adjusting to check for presence of resolution and acting accordingly
- Function
It's probably fine to let the manifest suffix follow the input values, so we'd end up with
2018-02-03 10:40:07
Webhook User-Agent
View Commit
2018-02-03 10:43:43
Specifying the resolution for any given bitrate is optional, and should be appended to the bitrate in the format
Test encode ran well enough, though there are a few things I'd like to tidy up (see the commit message for more info).
We're also not currently writing the resolution into the master manifest for any variant where the res wasn't explicitly defined on the command line. Feels a bit incongruent so should consider whether that should be fixed. But, as we'd need to probe the input, that may be an issue for linear streams (or may not).
2018-02-04 12:28:06
Should give us a 4K stream at around 13Mbps and a 1080p at around 12Mbps, using a constant bitrate
FFMPEG has slightly undershot the bandwidth, but the resolutions are as they should be
ben@milleniumfalcon:/tmp/output$ ffprobe -hide_banner -i bbb_sunflower_native_60fps_stereo_abl.mp4_13495_00000.ts Input #0, mpegts, from 'bbb_sunflower_native_60fps_stereo_abl.mp4_13495_00000.ts': Duration: 00:00:10.70, start: 1.412000, bitrate: 11303 kb/s Program 1 Metadata: service_name : Big Buck Bunny, Sunflower version service_provider: FFmpeg Stream #0:0[0x100]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p, 4000x4500 [SAR 1:1 DAR 8:9], 60 fps, 60 tbr, 90k tbn, 120 tbc Stream #0:1[0x101](und): Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp, 198 kb/s Stream #0:2[0x102](und): Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 Hz, 5.1, fltp, 130 kb/s ben@milleniumfalcon:/tmp/output$ ffprobe -hide_banner -i bbb_sunflower_native_60fps_stereo_abl.mp4_12000_00000.ts Input #0, mpegts, from 'bbb_sunflower_native_60fps_stereo_abl.mp4_12000_00000.ts': Duration: 00:00:12.52, start: 1.412000, bitrate: 10610 kb/s Program 1 Metadata: service_name : Big Buck Bunny, Sunflower version service_provider: FFmpeg Stream #0:0[0x100]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p, 1920x1080 [SAR 1:2 DAR 8:9], 60 fps, 60 tbr, 90k tbn, 120 tbc Stream #0:1[0x101](und): Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp, 198 kb/s Stream #0:2[0x102](und): Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 Hz, 5.1, fltp, 130 kb/sSo, it looks like linear handles the resolution support correctly.
Next thing to do, then, is to get the README updated to note this new feature
2018-02-04 12:30:25
2018-02-04 12:36:07
Webhook User-Agent
View Commit
2018-02-04 12:43:49
2018-02-04 12:44:07
Webhook User-Agent
View Commit
2019-07-26 09:03:36
2019-07-26 09:03:44
2019-07-26 09:03:44
2019-07-26 09:03:50