Thats not going to work for numerous reasons.
Bummer. I trust you, of course, on Android.
Thats not going to work for numerous reasons. Android doesn't offer that kind of control (in fact, HLS itself doesn't specify any control whatsoever for Live playlists), and it would make seeks even slower, encoding 30 seconds or even 2 minutes before playback starts can actually take up to that time if your server can just about do real-time, thats not even close to acceptable.
The spec does allow for re-using segments already encoded and downloading for backwards seeking with an event-type playlist. This is the same exact thing as a Live playlist, but you can only append to the file (and not change what has already been streamed). So, if the server keeps track and knows the seek requested is within the pre-encoded buffered area, it just adds to the playlist re-uses the old segments and then keeps going.
Such as if, the original index is:
#EXTM3U
#EXT-X-PLAYLIST-TYPE:EVENT
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:10.0,
http://media.example.com/segment1.ts
#EXTINF:10.0,
http://media.example.com/segment2.ts
#EXTINF:10.0,
http://media.example.com/segment3.ts
And then, if the client requests a seek within the back-buffer, you just go "backwards" with the M3U8...
#EXTM3U
#EXT-X-PLAYLIST-TYPE:EVENT
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:10.0,
http://media.example.com/segment1.ts
#EXTINF:10.0,
http://media.example.com/segment2.ts
#EXTINF:10.0,
http://media.example.com/segment3.ts
#EXTINF:10.0,
http://media.example.com/segment4.ts
#EXTINF:10.0,
http://media.example.com/segment2.ts
#EXTINF:10.0,
http://media.example.com/segment3.ts
#EXTINF:10.0,
http://media.example.com/segment4.ts
#EXTINF:10.0,
http://media.example.com/segment5.ts
#EXTINF:10.0,
http://media.example.com/segment6.ts
The client just keeps reading forward. Now, of course, if you jump outside of the pre-encoded area (like to "segment zero" or "-4" in the above example), you'd have to shut it down and start over. But for little seeks it could work. There might be a lag with 10 second segments (if the player just started playing a particular segment), so you'd have to experiment. I bet 2-3 second segments might be acceptable though. How often would you seek
right at the beginning of a segment?
Or, does it really only support Live-type playlists, instead of Event (which is the same system as Live but doesn't re-write any old files)? How come? An Android limitation in the client? Or, is Android not using the M3U8 index at all and the URL is the file itself via HTTP? Otherwise, it seems like mostly server-side smarts, if the client does what the spec calls for... That's precisely the type of stream you need:
https://developer.apple.com/library/ios/technotes/tn2288/_index.htmlI'm not sure what kind of settings you're using to encode, of course. AirVideo basically throws quality to the wind and drives it as fast as it can, when live encoding. I'm not sure, but I think I get 200-300% of real-time performance on my machine (a stock 3770 Ivy Bridge), so pre-buffering 20 seconds would probably be tolerable. But, of course, if you're encoding a nicer quality output, then you wouldn't be able to get acceptable performance on that, for sure.