Jump to content

Kodi not using cache when video is transcoded


tojo2503
 Share

Recommended Posts

tojo2503

Hi there,

 

I have an Emby Server that is capable of transcoding. When transcoding and watching the transcoded stream in a browser everything is perfectly fine.

However I have a RPi3 with Kodi, that is connected via Wifi and one that is connected over the Internet. Both play videos, that are not transcoded perfectly fine. For some videos however, I need transcoding and these videos keep on stuttering.

 

I tried to enable the Kodi cache in the advancedsettings.xml, cause it seems like a caching problem for me. Caching works fine for videos that are not transcoded. The cache is filled up to the desired value.

When I start a transcoded video the cache is not filled and the videos stutters every now and then because the Wifi speed sometimes drops under the bitrate value (but is a lot over that in average). Is this a known behaviour?

 

Might be connected to the fact that transcoding produces lots of small .ts-files. I couldn't find anything in the search. Are there workarounds so the transcoded files are cached as well and can be watched smoothly over Wifi?

 

Thanks for your help!

Edited by tojo2503
Link to comment
Share on other sites

tojo2503

Hi, best thing to do is discuss an example and attach the information requested in how to report a media playback issue. thanks !

Hi Luke,

 

thanks for the answer. Actually I tried to give an example and discuss it. I don't see how logs would help here. The Emby Server seems to work, but Emby for Kodi doesn't cache the files properly when the video is transcoded and it stutters. I don't see which log would be helpful? Kodi.log? Emby.log? Transcode log?

 

Best regards

Link to comment
Share on other sites

tojo2503

The add-on does not cache anything. Playback is all Kodi. You'll have to play with your advancedsettings and adjust it for your setup. You may also want to reduce the video quality set in the add-on settings > playback.

http://kodi.wiki/view/HOW-TO%3AModify_the_video_cache

 

Hi,

 

thanks for the answer. I already adjusted the advancedsettings.xml but the cache is only used if the video is NOT transcoded (using "Example 4" in the link you gave). If it's transcoded, the cache does not fill and is not used... reducing the video quality makes it worse, because more videos are transcoded and are therefore not cached.

I still assume it has got something to do with the small .ts-files that Emby produced. I think Kodi just can't handle these files or caches only one of it and not those, that are supposed to be played next.

So you'd suggest to open a thread in the Kodi forum? Can you reproduce the behaviour?

Edited by tojo2503
  • Like 1
Link to comment
Share on other sites

tojo2503

Hi,

great thanks. I tried to narrow down the problem:

 

- Kodi doesn't seem to cache m3u8 playlists properly.

- Emby transcoding uses m3u8 playlists.

- Emby produces very small chunks of .ts-files when transcoding, so I suppose that Kodi only caches the single .ts file played at the moment.

- I read that (by default) Kodi caches 8-10 seconds of m3u8 files and this doesn't seem to be adjustable.

 

Workaround (or test):

- Is there an option to influence the size of the .ts files? It should be something in the ffmpeg command but I couldn't find it... then we could check out if the behavior is better if the parts are like 50 Mb or something

 

More ideas:

- Convince Kodi to use the cache for m3u8 files for more than the .ts file that is played at the moment. Other platforms (VLC, Browser,...) seem to be able to handle these files better than Kodi does.

 

Thanks for your support! Let's see if we can track this down... :-)

  • Like 1
Link to comment
Share on other sites

Every transcoding session is unique. When you play a second time it will have a different query string, so this isn't going to work.

Link to comment
Share on other sites

The url is supposed to have a unique playSessionId, although if you're building your url's manually then yours might not have this.

 

Is this code actually being used?

https://github.com/MediaBrowser/plugin.video.emby/blob/708d3d7f3972d874f224360a7e30ec4f4ca1d052/resources/lib/playutils.py#L492

 

I thought you hadn't gotten around to completing this yet. In any case, if you were to complete that, then all of your transcoding urls would contain a unique playSessionId and this will prevent any caching from being effective. And no, it's not optional, you can't strip that value out without causing side effects. Sorry.

 

If you haven't completed the above yet, and if your urls don't have a unique playSessionId, then disregard everything I've said.

Link to comment
Share on other sites

Angelblue05

No that isn't plugged in yet.

 

This is what is still in. I am disregarding what you are saying because it's not applicable.

https://github.com/MediaBrowser/plugin.video.emby/blob/708d3d7f3972d874f224360a7e30ec4f4ca1d052/resources/lib/playutils.py#L323-L352

 

I saw this in the wiki:

https://github.com/MediaBrowser/Emby/wiki/Video-Streaming

 

Would another extension (rather than using master.m38u) work better or am I mixing things here?

Edited by Angelblue05
Link to comment
Share on other sites

No, what you're currently doing offers the best playback experience. It sends back an m3u8 playlist along with the video chopped up in lots of little pieces. It's quite possible that caching isn't working simply because there is some complexity here and the kodi team has just never tested caching HLS output.

 

I think ultimately this would require a client-side feature rather than just relying on the kodi core. Even if you get it to work in it's current form, suppose later you finish the new playback code and now you have cache busting params in your video url's. It will definitely break then.

  • Like 1
Link to comment
Share on other sites

Andy777

No, what you're currently doing offers the best playback experience. It sends back an m3u8 playlist along with the video chopped up in lots of little pieces. It's quite possible that caching isn't working simply because there is some complexity here and the kodi team has just never tested caching HLS output.

 

I think ultimately this would require a client-side feature rather than just relying on the kodi core. Even if you get it to work in it's current form, suppose later you finish the new playback code and now you have cache busting params in your video url's. It will definitely break then.

 

Indeed Kodi does NOT cache HLS streams. There has been some discussion about on Kodi forums since 2013. For HLS, Kodi offloads the work to ffmpeg libraries and the stream completely bypasses regular Kodi video cache (it uses maximum of 8 seconds of buffer, which is different from video cache). There is also a philosophical view that HLS streams are for live broadcasts and thus large cache should not be used (see this discussion in iptvtalk).

 

Some suggestions of ways that could overcome this:

  • Switch Emby transcoding to use MKV (as it does with Emby Android mobile client) single file instead of chuncked HLS.
  • Get ffmpeg development team to add caching directly to ffmpeg HLS decode (unlikely).
  • Wait for inputstream.adaptive to support HLS and caching (it is in the works for Kodi 18) and use inputstream methods. Although caching is not in the highest priority of the developer (discussion in this github issue and facebook example here). It's unlikely that HLS support will be backported to Kodi 17.

BR,

Andy777

  • Like 1
Link to comment
Share on other sites

tojo2503

Some suggestions of ways that could overcome this:

  • Switch Emby transcoding to use MKV (as it does with Emby Android mobile client) single file instead of chuncked HLS.
  • Get ffmpeg development team to add caching directly to ffmpeg HLS decode (unlikely).
  • Wait for inputstream.adaptive to support HLS and caching (it is in the works for Kodi 18) and use inputstream methods. Although caching is not in the highest priority of the developer (discussion in this github issue and facebook example here). It's unlikely that HLS support will be backported to Kodi 17.

BR,

Andy777

 

Hi,

 

great to see some nice ideas here. Would it be a big adjustment to use suggestion 1 (transcode to MKV instead of HLS) and what would be the disadvantages of that method? Seems legit to me... maybe the Kodi addon could "ask" for a HLS or MKV stream?

 

Is the inputstream.adaptive support of HLS a feature for Kodi 18 or is it just the discussion? I suppose it's not implemented yet, so we can't test it with Milhouse builds?

 

Thanks so far for the discussion, support of cache would really be a nice feature.

Link to comment
Share on other sites

Jdiesel

Indeed Kodi does NOT cache HLS streams. There has been some discussion about on Kodi forums since 2013. For HLS, Kodi offloads the work to ffmpeg libraries and the stream completely bypasses regular Kodi video cache (it uses maximum of 8 seconds of buffer, which is different from video cache). There is also a philosophical view that HLS streams are for live broadcasts and thus large cache should not be used (see this discussion in iptvtalk).

 

Some suggestions of ways that could overcome this:

  • Switch Emby transcoding to use MKV (as it does with Emby Android mobile client) single file instead of chuncked HLS.
  • Get ffmpeg development team to add caching directly to ffmpeg HLS decode (unlikely).
  • Wait for inputstream.adaptive to support HLS and caching (it is in the works for Kodi 18) and use inputstream methods. Although caching is not in the highest priority of the developer (discussion in this github issue and facebook example here). It's unlikely that HLS support will be backported to Kodi 17.
BR,

Andy777

I didn't not know that the Android Mobile client uses a mkv container versus a ts. That may be why I've always a much better experience with the Android client in regards to stream start up time and buffering.

Link to comment
Share on other sites

Andy777

I didn't not know that the Android Mobile client uses a mkv container versus a ts. That may be why I've always a much better experience with the Android client in regards to stream start up time and buffering.

 

@Angelblue:

 

Would it be a huge job to include MKV streaming as an option to the beta addon (as experimental) or is there any other downside to it? At least the community would provide feedback wether the user experience is better or worse than with HLS.

Link to comment
Share on other sites

If you switch to mkv you can't seek the transcoded stream so for most that will not be worth it. Can't really pause for too long either.

Link to comment
Share on other sites

tojo2503

If you switch to mkv you can't seek the transcoded stream so for most that will not be worth it. Can't really pause for too long either.

 

Hi,

 

thanks for all the answers. Am I right with my summary?

  • HLS files are the prefered and best method to provide transcoded streams. MKV works (and would work with Kodi buffer) but has some major other drawbacks.
  • Kodi handles HLS with a constant buffer of ~8 seconds but with a maximum size of the file in the m3u8 that is played at the moment.
  • Since the Emby .ts parts are a maximum of  ~1MByte Kodi only uses (maximum) 1 Mbyte of cache.
  • This might improve with Kodi 18 Leia, but the developers doubt that it's useful.

Would it be possible to increase the size of the .ts-parts that Emby produces to, let's say something like 20 MByte? This might be an option in the ffmpeg line?

Otherwise I'd say that waiting for Kodi 18 is the only option, let's see what the developers deliver, even though I still consider this a drawback of the Emby-Kodi combination.

 

Best regards! :-)

  • Like 1
Link to comment
Share on other sites

That will increase the time it takes to start playing and will lead to complaints in that respect.

Link to comment
Share on other sites

The addon can customize this using the query string, but remember what I said earlier that transcoded playback sessions are intended to be unique. The more the add-on strays away from guidelines the more difficult it will be help with any playback related problems.

Link to comment
Share on other sites

Jdiesel

I think that giving the user the ability to increase the segment size would be very helpful for those on high latency networks. I understand the current method works for most but having an option with a disclaimer that increasing the size over the default may increase startup times would still benefit all users.

 

In my case 20MB would be a little extreme but I would be curious to see how 2MB or 3MB works in my situation. 

Link to comment
Share on other sites

tojo2503

Yeah sure it would increase the startup time... bad situation for me in that case.

I suppose the ffmpeg command cannot be edited easily since it's hard coded in the Server and not a parameter? This means I would have to build the server from git and editing the file and parameter (is this even possible??). Or is this command issued by the Kodi-Addon and not by the Server?

Edited by tojo2503
Link to comment
Share on other sites

The segment sizes are based on number of seconds, not actual size. We use six or three seconds depending on the situation.

Link to comment
Share on other sites

Andy777
  • Since the Emby .ts parts are a maximum of  ~1MByte Kodi only uses (maximum) 1 Mbyte of cache.

 

This part is wrong at least with Kodi 17 (and earlier). HLS streams completely bypass the Kodi cache. Increasing the segment size would NOT help with current Kodi. It would possibly help with other clients that cache the HLS segment.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share

×
×
  • Create New...