On 25/04/2012 06:02, Amos Jeffries wrote:
On 25/04/2012 6:02 a.m., Eliezer Croitoru wrote:
as for some people asking me recently about youtube cache i have
checked again and found that youtube changed their video uris and
added an argument called "range" that is managed by the youtube player.
the original url\uri dosnt include range but the youtube player is
using this argument to save bandwidth.
i can implement the cahing with ranges on nginx but i dont know yet
the way that range works.
it can be based on user bandwidth or "fixed" size of chunkes.
if someone up to the mission of analyzing it a bit more to understand
it so the "range" cache will be implemented i will be happy to get
some help with it.
Thanks,
Eliezer
I took a look at it a while back...
I got as far as determining that the "range" was roughly byte-ranges as
per the HTTP spec BUT (and this is a huge BUT). Each response was
prefixed with some form of file intro bytes. Meaning the rages were not
strictly sub-bytes of some original object. At this point there is no
way for Squid to correctly generate the intro bytes, or to merge/split
these "ranges" for servicing other clients.
When used the transfer is relatively efficient, so the impact of
bypassing the storeurl cache feature is not too bad. The other option is
to re-write the URL without range and simply reply with the whole video
regardless. It is a nasty mapping problem with bandwidth waste either way.
they have changed something in the last month or so.
the was using a "begin"
and now they are usinn " "rang=13-X" 13 is the first..
i was thinking also on rewriting the address cause it works perfectly
with my testing.
will update more later.
Eliezer
That was a year or two ago, so it may be worth re-investigating.
Amos
--
Eliezer Croitoru
https://www1.ngtech.co.il
IT consulting for Nonprofit organizations
eliezer <at> ngtech.co.il
