Re: [squid-users] anyone knows some info about youtube "range" parameter?

wouldn't be better if we save the video chunks ? youtube is streaming
files with 1.7MB flv chunks, youtube flash player knows how to merge
them and play them....so the range start and end will alaways be the
same for the same video as long as user doesn't fast forward it or do
something nasty...even in that case , squid will just cache that
chunk...that is possible by rewriting the STORE_URL and including the
range start & end

On Wed, Apr 25, 2012 at 8:39 PM, Ghassan Gharabli
<sounarose_at_googlemail.com> wrote:
>
> 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:48:47 MDT