I am not following this but I'll write out my understanding.
Originally Posted by rrlanham
You're suggesting thatwe use streamname alias to uniquify the cdn accelerated links so that requests are always proxied to wowza but the chunks may already be on the cdn. As follows
cnd.domain.com accelerates wowza.domain.com in the normal fashion.
The first request goes to http://cnd.domain.com/dvr/dvr/stream...nifest.f4m?DVR
the cdn passes the request and it responds
streamnamedvr.16 = not sure why there is an additional .16 on the streamname?
<?xml version="1.0" encoding="utf-8"?>
<dvrInfo windowDuration="3600"> </dvrInfo>
<media width="80" height="60" url="DVR_b125000_w885375480_qRFZS.abst/">
<bootstrapInfo profile="named" url="playlist_b125000_w885375480.abst?DVR"/>
then it makes a request to the bootstrap playlist and this returns a binary so I am unable to determine what contains but one would expect the current sequence number.
this is followed by a few fragment requests (in sequence) may one or two and then another playlist request ad infinitum.
FWIW this is not how I thought HDS was supposed to work. I thought there was to be a single request at the beginning anf the frag requests are made by incrementing the current sequence number. , but hey ho.
is unique but could be cached on the CDN ( were it not for the no-cache directive in the headers )
the w1631144358 represents the wowza/session id.
Setting the app as HTTP origin and the w1631144358 vanishes as expected and the cache control goes to 60 mins
Everything carries on as normal. I did try to accelerate and it looks as though it works fine. The osmf player is able to see back to a moment in the past. Curioiusly it does send any params on the playlist request even for stuff that is in the past on the scrubber. I assume the player does all the magic.
Now to TEST HLS..