Cache busting parameter added to fragment request

[somerobmitchell]

Hi All,

A cache buster is added to every dash fragment requested by the player.
This can been seen here.

The reason given for this is that cached responses can ruin the bandwidth estimation but it has caused another issue with our dash stream.

We are using Unified Streaming to stream a dash manifest that is created on the fly.
This means that fragment generation (especially with encrypted streams) can take >1s. To overcome this we use the Level3 CDN to cache the fragments, this reduces the load on the origin server and makes the fragments available quicker. The cache-buster parameter meant that Level3 was treating every fragment request as a new request.

I can ask Level3 to ignore any query strings and just look at the path but wanted to understand the reasoning behind adding the cache buster param.

[kkarablinkbox]

Hi,

Just wanted to say that we've done exactly the same thing, asked Level3 to ignore the query string params and it has worked for us. We've tried other approaches but none really worked in an easy way. I'll let Joey respond to the reasoning, if there's any other than what you've already mentioned around bandwidth estimation.

[somerobmitchell]

I am leaning towards removing the code. We are using the dash.js player as well and have not seen any problems with not having the cache buster.

[tdrews]

Hi,

Thanks for your input on this. We added the cache-busting feature to simplify our bandwidth estimation code, as without it we found it difficult to get reliable estimates using our weighted average approach; however, as we now support custom bandwidth estimators and plan on supporting custom bit-rate managers (see #48) this is something that we will revisit for <= v1.4.0.

[joeyparrish]

The cache-busting parameter has been a pain point for others, as well. If there were a way to reliably detect when segments are being served from the local cache, we could do away with cache-busting and simply discard throughput measurements for cached responses. If anyone has ideas on this point, I would be very happy to hear them.

[joeyparrish]

Oh, and to add context, if you never seek, cached segments will never trouble you, even without cache-busting params.

The trouble is when you have very little bandwidth and have downloaded a bunch of 360p segments, then you seek backward and suddenly you appear to have enough bandwidth for 1080p and the player adapts up. Since you don't actually have the bandwidth for that, the player adapts back down, possibly after a stall. Then you get cache hits again for your 360p segments, then you adapt back up, etc.

[joeyparrish]

v1.4.0 is out now, including a new method on IBandwidthEstimator so that a custom implementation can disable cache-busting. Please let us know whether or not the new APIs resolve this issue for you.

[tdrews]

Please feel free to re-open this issue if you have any issues with IBandwidthEstimator.supportsCaching().