HLS encoding store and remove session info

[syadnom 24]

I've been experimenting with caching the HLS stream.  The caching works awesome, but it's effectively useless because the URL of the video has the session ID in it.

 

It would be great if the transcoded video was transcoded for any viewer that attached and that we could have Emby keep those transcodes around for some amount of time.

 

for example, say transcodes are valid for 48 hours, set the expires in the web server to 48 hours and allow any viewer to pick up the HLS URI if they start playing that content with settings within some acceptable range.  Say 1 viewer is set at 3Mbps and another at 2.5Mbps, stands to reason that we'd rather give them 2.5Mbps user a 3Mbps pre-encoded and ready-to-go stream than to transcode again.

 

example cached video segment path.

http://url/emby/videos/39/hls1/main/96.ts?DeviceId=x&PlaySessionId=y&api_key=z&VideoCodec=h264&AudioCodec=aac&VideoBitrate=1116000&AudioBitrate=384000&AudioStreamIndex=1&TranscodingMaxAudioChannels=2&SegmentContainer=ts&MinSegments=1&BreakOnNonKeyFrames=True&ManifestSubtitles=vtt&h264-profile=high,main,baseline,constrainedbaseline&h264-level=51&TranscodeReasons=ContainerBitrateExceedsLimit

 

note the PlaySessionId=, kills effective caching.

[Luke 37254]

Hi, yes there are other factors that can effect that though, for example, selected audio track or sometimes the subtitle track. So there's some trickiness there.

[syadnom 24]

If you look at a 10,000 foot view of possibilities, sure.  But when focusing on individual installs, language options don't tend to be that important.  *my* installs for instance are going to be all set for English.  If you have an immigrant/ESL family they will set their defaults to fit their preferences and that install will likely only operate within that narrow scope.

 

Most tracks will be the default language and most subtitles will be the default subtitle.  If the player device would check to see if there was a previously HLS transcoded option and prefer that, then they will have a faster experience not waiting on the server and the server can handle more requests.

 

What would be incredibly slick is if an HLS playlist file was created when you transcode and then if a new transcode with new settings was done it would get added to the original index with proper EXT-X-MEDIA tags.  Point the player at that index m3u8 and keep the encoded videos.

 

Maybe an option in the library to say 'complete HLS encodes once started' and 're-use HLS encodes'.

 

I'm personally most interested in Live TV/OTA for this though.  Creating an m3u8 playlist for a channel and running a long buffer and adding support to the players to 'jump' into that playlist from the EPG would be great.  If that was done, then that entire channel could practically be auto-DVR.  A bit of a pain to do a multi-level HLS on live but it's quite possible with fffmpeg.

[ebr 14959]

In general, we can't afford to make those kinds of assumptions.  The system would need to be able to handle most cases without problems and that would get quite complex quickly.  Not that it couldn't be done but it isn't something we could just slam in.

 

I thought I remembered this being asked before.  You are basically asking for this, correct: Server - Trancoding Cache