########################################################################################## HLS-27: Ability to define resolutions with bitrates ########################################################################################## Issue Type: Sub-task ----------------------------------------------------------------------------------------- Issue Information ==================== Priority: Major Status: Closed Resolution: Done (2019-07-26 09:03:44) Project: HLS Stream Creator (HLS) Reported By: btasker Assigned To: btasker Child of: HLS-25 - Additional flags/features to aid Low Latency Streaming Components: - Transcoding - CLI Options - Adaptive Streams Targeted for fix in version: - 1.0 Time Estimate: 120 minutes Time Logged: 0 minutes ----------------------------------------------------------------------------------------- Issue Description ================== It'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 btasker ----------------------------------------------------------------------------------------- I don't know how trivial it'll be to be able to defined both bitrate and resolution (though it may be do-able). 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 btasker ----------------------------------------------------------------------------------------- I _think_ a good starting point would be to look at implementing the ability to specify a resolution along with the bitrate, something like -b 2000,1024-1280x1080,512-400x300 with the resolution being left untouched for any bitrate that doesn't have a resolution specified (though we'll still need to probe the video to find out what resolution to write into the manifest). 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 300x200 div. VideoJS will detect that the highest resolution it currently needs to fetch is 600x400, which is the 768k stream. It won't fetch a higher bitrate as the resolutions are higher than currently displayed (and video-js-hls will only go up to one size larger than the current container). All well and good so far (as there's no point in fetching a 1080p stream for a 300x200 window). 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 600x400 video stretched to fill your screen - even if you then have the bandwidth to fetch the 1080p content. Not exactly pleasant. 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 VideoJS as an example, it won't be the only player that does this. So we'll need to find a (much) more concise way to note that in the README too. ----------------------------------------------------------------------------------------- 2018-02-03 09:52:23 btasker ----------------------------------------------------------------------------------------- Getting back to it, though. If we want to implement the ability to specify resolution as part of the bitrate (i.e. -b 2000-1280x720 then there are a few locations that'll need changing within the script. - Function appendVariantPlaylistentry will need adjusting to check for the resolution being specified, and acting accordingly - The iterative loop will need adjusting to check for presence of resolution and acting accordingly - Function createStream will also need adjusting do that it can set the resolution It's probably fine to let the manifest suffix follow the input values, so we'd end up with stream_2000-1280x720.m3u8 as a variant bitrate manifest ----------------------------------------------------------------------------------------- 2018-02-03 10:40:07 git ----------------------------------------------------------------------------------------- -- BEGIN QUOTE -- Repo: HLS-Stream-Creator Commit: 2cac89e5184c89f4f4634d222bd99214feb86c5a Author: B Tasker