Buffering issues - is there a way to buffer ahead multiple segments?

[glennguy]

I'm having an issue with a VOD provider in Australia that has very inconsistent download speeds/response times. It's being delivered through akamai cdn. Other providers that have higher bitrates have no issues. The android app for this service has no problems either, as it seems to fetch around 50 segments or so at a time so any sort of intermittent speed drop doesn't affect playback, whereas in Kodi it almost seems to have a buffer of 1 segment, and some of the 400kb segments can take up to 2000ms to download causing loss of continuous playback.

Is there a way to implement a segment buffer, whether it be manually or dynamically sized, in inputstream.adaptive? Or is this the responsibility of the inputstream interface itself?

I'm on a 60Mbps connection, I'm certain that it's not the issue.

[peak3d]

Yep, it's a point on my todo list

[DjDiabolik]

I have a similar question about buffering........ i know the imputstream.adaptive it's also used by Recent version of youtube addons by jdf76.

I have tryed to make this question of official thread (here my question -> http://forum.kodi.tv/showthread.php?pid=2526482#pid2526482) and it's suggest to me to try to ask to imputstream boys and i'm here for this:

I have so many problems whit youtube video...... i obtain so various buffering problems almost of 90% of video i try to watch. Sometime it's impossible also get back to beginning of video....... the only ways to obtain a watchable video it's to remove if from playlist of kodi and try to re-load and sometime it's work.

But the problems it's..... previously when youtube addons doesn't use the imputstream i never obtain buffering problems (i have a italian 20MB/s adsl... every my speedtest it's pass the 15MB/s at media and sometime i reach 18/19MB/s) and i thinks it's probally i have wrong configure the imputstream..... for example:
What's the exact value i need to put in max and mix bandwidth ? On Max i have put 20.000.000 and i thinks this is my maxium speed but how it's work the min ?
How i can correctly set this value ?? I have tryed to put this value to 1.000.000 and buffering problems.... i have tryed to set at 10.000.000 buffering problems...... i have also tryed to put at 0 but nothings can help me.
On Max Resolution i have set to 720p because also when no imputstream has been used i ever use the youtube addons whit this max resolution and i never obtain problems whit caching (even at a time I could make the video full caching as soon immediatelly after the reproduction start) but now it does not seem to cache even for 10 seconds.....

[peak3d]

In most cases not the bandwidth of your home connection is sthe issue, its the bandwith from the provider (youtube servers).

Normally you let all at default settings (0,0,Auto) and things work Ok.
But as written above, the field of improvements regarding buffering is hugr (currently only the 8 sek. internal kodi buffer is used), but as long most major VOD's run finde with this implementation I don't feel such a pressure.

Because I have heared off the YT issues in the last time, I'll fucus on it next (after a rough buffer improvement inside inputstream.adaptive wich comes together with bitrate switching)

[matthuisman]

I just struck this issue as well with a provider (DStv) which use akamai.
They are using MPD with Widevine for live streams.
KODI cache settings have no affect (as others have found)

Just real choppy. Almost like it's just slightly not keeping up.
Plays for a few seconds, shows buffering for a second and repeat.

Oddly, changing the quality of the stream has no affect.

[dgktkr]

I'm running into buffering issues with plugin.video.netflix which uses inputstream.adaptive. I believe increasing the buffer size for incoming video streams would fix the problem. If I can find where in the code this is done, I'm inclined to edit my instance of the plugin.

Can anyone give me a pointer to where this is done in the inputstream.adaptive code?

[basrieter]

I had users reporting similar issues.

[V10lator]

Any news about this two years old issue? It's really annoying when DRM content hangs every few seconds on a kodi box while it runs just fine in browser or the official mobile app of the content server.

Just as @dgktkr I would be willing to help code / create a pull request but I don't have the time to read me into the codes, so a hint about where to look would be great.

[peak3d]

It's not only buffering which solves issues here, it the combination of bit stream switch to lower bandwidth / resolution streams bundled with more buffering on good times.

Its not as simple as you may thing, you have ~10 different streams with different resolutions / bandwidth, which one do you want to buffer ahead? Most likely not the best one, because it is most likely to slow.

What happens if you download a low quality one and during that the speed increases? Skip the low res onse and start again with higher res? Go backwards and replace all slow res with already buffered high res?

There are tons of things to respect if you want to make it smart. If you don't have time to read in code, you most likely have no time to make an approach which is futur safe @V10lator .

Because of the complexity / my limited time for this I'm looking for dev power with some experience and lot of time :-)

[V10lator]

Thanks for the reply. I think a valid (I think youtube in the web browser does this, for example, but take this with a grain of salt) but maybe quick&dirty solution would be (simplified pseudo code) :
Try the best resolution possible and measure the incoming bandwith.
If minimum resolution is lower than maximum resolution execute the following in a loop:
If data gets in too slow and we're not at minimum resolution switch to next lower resolution stream.
Else if data gets in too fast and we're not at maximum resolution switch to next higher resolution,

Again, this is quick&dirty but should work and should be fairly simple to implement (again: I don't know the codes, so sorry if I'm wrong about that). After that implementation has been done it can be exchanged with some better algorithm at any time. It would just be nice for the users to have something until a better solution pops in.

//EDIT: Also you could make this adaption algo an optional setting in case some weird content providers or bad internet connections switches bandwith too fast or maybe even detect bandwith changes per timeslice (maybe minute?) and if it's too much just go lower but not higher anymore.

//EDIT²: Or remove the else if completely and just go lower from the beginning as it's unlikely for the bandwith to get higher and stay stable at that new, higher bandwith. In any case you might want to measure the average bandwith over some time as small fluctations are normal and should be ignored (except the buffer gets almost empty after being fully filled, that may be a corner case to handle).

//EDIT³: Or maybe even simpler: Start with highest. After buffer is filled > some % (maybe 50%) check fill state and if gets too low (<10% or something like that, so it's likely to interrupt the stream anyway) switch to next lower stream and start from the beginning. Also check if buffer needs to long to get filled to the initial 50% and if so go lower, too.

[peak3d]

Biggest issue is, that the code is grown. At the time I started with this project, my only goal was to get amazon back. I have't realy expected that it will be used by > 100 content providers nowdays.

-> Cleanup required, Even I did already some cleanup and preparation steps, you'll have to analyze the full workflow including decryption (which is affcted by stream changes, too).

There is no real way to hack things into it without respecting the final goal. I believe, that this year will be done some work on it, there are dev options which haven't been there before.

[yoshimo]

@peak3d has the situation with the code cleanup become good enough to justify work on this issue again?

[glennguy]

Closing in favor of newer issue #392