[mythtv-users] more than 2 simultaneous HLS transcodes

[Chris Pinkham]

* On Mon Aug 20, 2012 at 05:25:56PM -0400, George Nassas wrote:
> I'm curious about how this is going to work. Right now you get an
> m3u8 file with the requested resolution/bitrate plus a second audio-only
> stream; it would be nice if we got a m3u8 file with all the common h.264
> levels/dimensions/bitrates and the client could decide which to request
> based on its abilities and available bandwidth. Not really making feature
> requests, just wondering if I'm in line with what you're thinking.

Yeah, that's along the line of what I'm thinking.  Basically looking at
something like this for the filenames which you could request from the
backend:

Example of a meta playlist
/HLS/ORIGFILENAME.hlsd.m3u8
- contains auto-generated links to multiple playlists such as (these
  are not any indication of the defaults, just an example of naming):
  - /HLS/ORIGFILENAME.hlsd.1920w.2800kv.128ka.m3u8
    - 1920 wide (auto height), 2.8Mbit video, 128Kbit audio
  - /HLS/ORIGFILENAME.hlsd.1024w.2000kv.96ka.m3u8
    - 1024 wide (auto height), 2.0Mbit video, 96Kbit audio
  - /HLS/ORIGFILENAME.hlsd.640w.1000kv.64ka.m3u8
    - 640 wide (auto height), 1.0Mbit video, 64Kbit audio
  - /HLS/ORIGFILENAME.hlsd.0w.1000kv.64ka.m3u8
    - Audio-Only stream with 64Kbit audio

Example of a stream playlist
- /HLS/ORIGFILENAME.hlsd.1024w.2000kv.96ka.m3u8
  - contains auto-generated links to segments in the playlist
  - /HLS/ORIGFILENAME.hlsd.1024w.2000kv.96ka.00000001s.ts (segment #1)
  - /HLS/ORIGFILENAME.hlsd.1024w.2000kv.96ka.00000002s.ts (segment #2)
  - /HLS/ORIGFILENAME.hlsd.1024w.2000kv.96ka.00000003s.ts (segment #3)

All files would be created on demand.  I'm still thinking about the
queuing logic.  Currently all state is only stored in memory, so if
the transcoding daemon was restarted, it would just handle the next
request automatically.  It should be trivial to add a flag to tell
the daemon to auto-create all segments for a given playlist for use
cases like yours.  I'd have to think about the deletion, files
created this way could not be setup to auto delete, they would have
to be deleted via the API.  With the normal on-demand encoder, I
could 'expire' a segment after a certain period of time since it
would be regenerated on demand if necessary.

A few things have driven me towards this architecture.  Integration
with external clients will be much simpler.  I've played around with
HLS support in MythWeb via JW Player.  I have a hack patch but nothing
that was good enough for committing.  Then I played around with playing
MythTV generated HLS streams on my Roku box.  Then I talked with
Jean-Yves Avenard about it for a while and his experience with
AirVideo.  With on-demand encoding, MythWeb integration is as simple
as providing a .m3u8 link and JW Player hookup.  It's just as easy on
the Roku and any other client, no need for the Add/Stop/Remove
API calls.  No need for pausing and resuming stream generation.  Leave
it up to the client to start at a certain position in the stream
rather than having the transocder skip forward and leaving a 'partial'
playlist and set of .ts files around.   There are lots of other
advantages as well, the more I think about it the more I like it.  Now
I just need to find time to put ideas to code.

--
Chris