[barberio]

VBR content, not being meant for streaming, doesn't get used on internet streams very often. So that kind of analysis is certainly overkill for the problem.

Check the bitrate of the transport stream on loading the stream. And if that would overflow the buffer in less time than the set number of seconds of content to buffer, grow the buffer till it can. If the buffer can't be grown because of lack of available system memory, put up a warning, and use as large as a buffer as you can.

[da-anda]

AFAIK we also buffer local network streams now (I at least noticed a buffer indicator on media played from my NAS in the nightlies) - so that peak monitoring stuff could at least be used there (if it brings any benefits on f.e. limited HW like the rPI).

[bobo1on1]

No, we don't actually

[DDDamian]

Still hope you add that PR bobo1on1 (or fix it up so it can be merged)

[da-anda]

No, we don't actually

I thought I read about a commit that added a buffer/cache for network media - and at least my XBMC build is now displaying a buffer indicator in the OSD timeline. It was something like "preload network stuff and fill available RAM with it"

[Sranshaft]

Speaking about buffering, and my apologies if this is too far off-topic, but I have two question that have always left me wondering. First, I've noticed my buffering actually go backwards quite a few times. How exactly does the buffering do that? One would tend to think if a particular piece was downloaded and added to the cache, there wouldn't be a reason for this to occur, barring cases where the piece was corrupt.

Second, I've always wondered why buffering was based on the percentage of cache filled and not based on the total size of the file vs how much was downloaded. When browsing sites like YouTube, for example, when I see the buffered percentage at 100% I know all of the video has been downloaded. Now, I know why XBMC displays what it displays but explaining this to my wife leaves me running in circles. She expects it to behave similar to what she sees in YouTube where if buffering says 100% she should be able to skip around to the very end without having to see 'Buffering...' again.

Would this be a case of Buffered vs Loaded and if so, could we see something like Player.CacheLoaded in the future? It's purely cosmetic but could tend to help alleviate some user confusion.

Just thought I'd see if I could get some perspective from the devs' side of things while I see a bunch of you jumping on this post. Sorry again for the kind of on-topic but completely off-topic post.

[barberio]

The user doesn't really care about how much of the cache is filled, and as above mentioned it's really entirely misleading because the cache should try to stay in it's sweet spot not "100%" full. May be better to display how many seconds of content are buffered.

After consideration, I really think that the idea of one single buffer is broken. It's fine for content from disk, it's even fine from content from a local network. It's not fine for internet streaming where there is bandwidth capacity but high latency, and where you want to set up a constant stream to something and never stop it if you can help it.

Multi-level caching is needed. In those terms, a L1 of 5MB is kind of okay. L2 should be much more substantial, very likely diskbased, and can grow based on the context. An L2 disk based ring buffer would be much more suitable, and provide substantially better skip-forward skip-back playback performance.

[DDDamian]

No, we don't actually

I thought I read about a commit that added a buffer/cache for network media - and at least my XBMC build is now displaying a buffer indicator in the OSD timeline. It was something like "preload network stuff and fill available RAM with it"

That's a pr bobo1on1 has in, but not merged yet. Hope he keeps at it

[Bstrdsmkr]

The percentage displayed isn't percentage of cache filled. It's the percentage of X where X is the amount needed to play all the way through without having to stop and buffer again, at the current average download speed. If the average speed drops, X gets bigger, thus the amount buffered is a smaller percentage of X so the displayed number gets smaller.

[Sranshaft]

The percentage displayed isn't percentage of cache filled. It's the percentage of X where X is the amount needed to play all the way through without having to stop and buffer again, at the current average download speed. If the average speed drops, X gets bigger, thus the amount buffered is a smaller percentage of X so the displayed number gets smaller.

Thank you for that description but if that's the case, the skinning wiki makes things confusing when:

• Player.CacheLevel - Players current cache fill percentage (if supported by the player)
  
• Player.ProgressCache - Shows how much of the file is cached above current play percentage
  

Your description of the process of determining the current buffer percentage seems, to me at least, really convoluted and counter-intuitive when taking into account common experiences outside of XBMC where buffering video streams are concerned. Player.ProgressCache seems to imply that from the point the user is currently in the video to the end, 100% of the video stream should be completely download and available. Likewise, Player.CacheLevel completely contradicts what you said regarding percentage of cache filled.

I guess this brings me back to the point I made in my last post regarding Buffered vs Loaded. Does one prefer to know how much of the total stream has been downloaded and therefore available; or, know how long until the video can be watched until buffering needs to occur? Which one offers more information to the user? Which one is going to offer the maximum benefit with the less amount of confusion?

Using my wife as an example, which I tend to do when it comes to programming for the common user, I would venture to say the displaying the percentage of the total filesize is the best solution. As you will see on just about every video streaming site, the percentage filled is always the total amount of the video download. To my knowledge, this is the current recognized behaviour when the user interacts with the seekbar.

[Bstrdsmkr]

I'm referring to the "Buffering XX%" bar, not the playback bar shown in most skins, they are separate. Find a large file to stream with a bit of lag to induce buffering. If the file is large enough, but the connection is sufficient, the buffering bar will reach 100%, but the shaded portion of the playback bar will not reach the end. When looking at the playback bar, the user generally wants to know how much of the file has been made local, so that's what's displayed. When looking at the "Buffering XX%" bar, the user generally wants to know what percentage of that process is complete (thus that's what's displayed there).

You can also induce a situation that will show this more clearly. In advancedsettings.xml, restrict your buffer size to 1mb. Stream a large file and throttle your connection back to induce buffering. When 1mb has been buffered, you'll receive a warning stating that the maximum cache size was reached before buffering was complete

[barberio]

I don't know that users would "want to know what percentage of the buffering process is complete", it seems to be confusingly presented information no one really asks for that merely misleads the user into making assumptions about what the magic percentage number shown means.

It's not actually showing a meaningful figure, since a bare percentage of a variable total is not helpful. What it's actually showing would be better named "Buffer under-run protection".

Also, I'm confused about the caching strategy. Back near the start of this thread someone says XBMC does use sweet-spot high/low watermark caching, with throttle above the high watermark and release below it. But now you're saying it uses some other kind of caching strategy that involves estimating the time to download over the time to playback?

What exactly *is* XBMC's network stream caching strategy?

[barberio]

I think variation of throttle and release based on estimated time left in playback to the head of the buffer only makes sense if you are going to make a full local cache of the entire content[1]. But I don't see it's utility at all in a buffer that only keeps a seconds of content and throws the rest away.

XBMC's caching strategy needs to be looked at again from the point of view of streaming videos from high latency but high bandwidth WAN sources. One failure state I've observed with XBMC is that if you pause some kinds of internet streamed content, you risk having the video stop midstream after you unpause, because XMBC apparently came to a stop with downloading and the content server eventually times out the connection. This suggests that a layer of disk caching to try and prevent ever stopping the download is actually a requirement for these kinds of services.

[1] Live streams being a special case where you'd be saving a large amount for PVR like skip-back function.

[Martijn]

* Martijn request a full written code from barberio so we could test it

[Bstrdsmkr]

I don't know that users would "want to know what percentage of the buffering process is complete", it seems to be confusingly presented information no one really asks for that merely misleads the user into making assumptions about what the magic percentage number shown means.

It's not actually showing a meaningful figure, since a bare percentage of a variable total is not helpful. What it's actually showing would be better named "Buffer under-run protection".

I disagree. When a stream is buffering, I don't care how many megabytes of a file have been buffered, I care how long I have to wait before I can watch the stream without interruption.

Also, I'm confused about the caching strategy. Back near the start of this thread someone says XBMC does use sweet-spot high/low watermark caching, with throttle above the high watermark and release below it. But now you're saying it uses some other kind of caching strategy that involves estimating the time to download over the time to playback?

I think there is a difference in terminology here. As demonstrated above, xbmc does in fact calculate the amount of data that needs to be buffered in order to play back smoothly, but it is subject to a maximum cache size (5mb by default).

If I understand correctly, the problem from your perspective is that xbmc should endeavor to use one continuous connection to buffer the stream, by varying the amount of bandwidth available to xbmc. It seems to me that the devs are open to this idea and would accept a patch.