The PR merged in
HLS-5 simplify something I've been debating implementing for a while.
If the script is configured to accept a comma seperated list of bitrates, we can generate multiple bitrate HLS streams and then create a top level playlist pointing to the relevant m3u8s.
Players that support adaptive streaming can then choose (and switch between) playlists in response to changing network conditions (e.g. going from wifi to 3G).
Activity
2015-06-11 12:08:42
Probably better to wait until getopt support has been written in so that they information can be provided in a command line option.
2015-06-11 18:04:58
With VoD we could potentially do the following
- build a top-level playlist containing references to each of the bitrate playlists
- Iterate through each of the bitrates, calling ffmpeg for each and then .
With Live that won't work, as the stream won't end, so the bitrates need to be generated in parallel.
The top-level playlist needs to be generated before calling ffmpeg so that it'll be present whether live or VoD.
2015-06-12 12:05:17
It's occurred that if we can get multiple bitrates transcoding at the same time (which we'll need to do anyway for live adaptive streams) there's no real benefit in drawing a distinction between VoD and Live in terms of whether we fork or not. It'd mean that for a VoD encode the different bitrates could be created in parallel
Though, probably worth providing a command line option so that the user can specify VoD should be transcoded sequentially (in case the hardware in use simply isn't capable enough to handle it)
2015-06-12 13:01:15
Webhook User-Agent
View Commit
2015-06-12 13:01:15
Webhook User-Agent
View Commit
2015-06-12 13:02:33
As that's working I'm going to look at implementing the parallel transcoding now, there will be a few other minor tweaks needed to be able to test it properly with linear (essentially finishing up HLS-8)
2015-06-12 13:34:14
- Must be able to disable it
- Script shouldn't exit until the jobs themselves are all complete
- must be able to be run as a background script (i.e. if we're going to be using fg bg etc need to do a set -m first)
2015-06-12 16:34:36
- Added a new Command line option -f so that the parallelisation can be disabled
- Script will wait for each bitrate to finish (and report whenever it sees a bitrate reach completion)
- Interrupting the script will stop the encoding process
The script doesn't do any kind of tweaking on the ffmpeg flags (such as NUMTHREADS ) which may, potentially want to be tweaked given you'll be running number-of-bitrates transcodes simultaneously (for example, perhaps let them use a core each rather than all trying to thread across all cores?). Might be best left to the kernel to handle scheduling though tbh.
But the basic parrallelisation functionality is largely in place
2015-06-12 16:55:15
Webhook User-Agent
View Commit
2015-06-12 16:55:15
Webhook User-Agent
View Commit
2015-06-12 16:57:40
Other than that, the encode works correctly, and insists on parallelisation if the stream is live (as of commit e7ffea7)
2015-06-12 16:59:15
Webhook User-Agent
View Commit
2015-06-14 23:49:58
2015-06-14 23:50:04
2015-06-14 23:50:04
2015-06-14 23:50:09