Hello,
As i remember I already discussed this subject before mentioning that
Youtube several months ago added a new variable/URI "RANGE". I tried
to deny all URLs that comes with "RANGE" to avoid presenting the error
at Youtube Player butb tried to investigate more and came with a
solution like that :
--------------------------------------------------------------------------------
# youtube 360p itag=34 ,480p itag=35 [ITAG/ID/RANGE]
if (m/^http:\/\/([0-9.]{4}|.*\.youtube\.com|.*\.googlevideo\.com|.*\.video\.google\.com)\/.*(itag=[0-9]*).*(id=[a-zA-Z0-9]*).*(range\=[0-9\-]*)/)
{
print $x . "http://video-srv.youtube.com.SQUIDINTERNAL/" . $3 . "&" .
$4 . "\n";
# youtube 360p itag=34 ,480p itag=35 [ID/ITAG/RANGE]
} elsif (m/^http:\/\/([0-9.]{4}|.*\.youtube\.com|.*\.googlevideo\.com|.*\.video\.google\.com)\/.*(id=[a-zA-Z0-9]*).*(itag=[0-9]*).*(range\=[0-9\-]*)/)
{
print $x . "http://video-srv.youtube.com.SQUIDINTERNAL/" . $2 . "&" .
$4 . "\n";
# youtube 360p itag=34 ,480p itag=35 [RANGE/ITAG/ID]
} elsif (m/^http:\/\/([0-9.]{4}|.*\.youtube\.com|.*\.googlevideo\.com|.*\.video\.google\.com)\/.*(range\=[0-9\-]*).*(itag=[0-9]*).*(id=[a-zA-Z0-9]*)/)
{
print $x . "http://video-srv.youtube.com.SQUIDINTERNAL/" . $4 . "&" .
$2 . "\n";
--------------------------------------------------------------------------------------
I already discovered that by rewriting them and save them as
videplayback?id=0000000&range=00-000000 would solve the problem but
the thing is the cache folder would be increased faster because we are
not only saving one file as we are saving multiple files for one ID!.
AS for me , it saves alot of bandwidth but bigger cache . If you check
and analyze it more then you will notice same ID or same videop while
watching the link changes for example :
It starts [ITAG/ID/RANGE] then changes to [ID/ITAG/RANGE] and finally
to [RANGE/ITAG/ID] so with my script you can capture the whole
places!.
Ghassan
On 4/25/12, Eliezer Croitoru <eliezer_at_ngtech.co.il> wrote:
> 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
>
Received on Wed Apr 25 2012 - 17:39:41 MDT
This archive was generated by hypermail 2.2.0 : Thu Apr 26 2012 - 12:00:04 MDT