"Trickle Caching" for HD Content Streaming

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.

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).

No, we don't actually

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

(2012-05-09 20:50)bobo1on1 Wrote:  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"

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.

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.

(2012-05-10 10:52)da-anda Wrote:  

(2012-05-09 20:50)bobo1on1 Wrote:  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

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.

(2012-05-11 03:53)Bstrdsmkr Wrote:  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.