Results 1 to 4 of 4

Thread: DVR and http origin mode.

  1. #1

    Default DVR and http origin mode.

    When using the server as a CDN caching device, DVR does not work.

    Communication with the Wowza Media Server HTTP caching origin is sessionless (session-based communication doesn't work). This has the following ramifications: URL query parameters in player requests aren't supported. This includes wowzaplaystart and wowzaplayduration for VOD playback and wowzadvrplayliststart and wowzadvrplaylistduration for nDVR playback.
    Is there any workaround to this? From the way i see it the binary media chunks are already on the CDN from the live playback. So referencing them again should be possible. If the manifest requests weren't cached at all and allowd to hit wowza this should work fine. Why the need for sessions in creating the dvr manifests?

    Thanks,

    Joe

  2. #2
    Join Date
    Dec 2007
    Posts
    21,962

    Default

    Joe,

    A work-around is to use StreamName alias so you can use different names that resolve to same stream. Each new request using a new alias should create a new request to Wowza. The more you do this the less like an origin Wowza is.

    Richard

  3. #3

    Default

    Quote Originally Posted by rrlanham View Post
    Joe,

    A work-around is to use StreamName alias so you can use different names that resolve to same stream. Each new request using a new alias should create a new request to Wowza. The more you do this the less like an origin Wowza is.

    Richard
    I am not following this but I'll write out my understanding.

    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.

    FOR HDS

    The first request goes to http://cnd.domain.com/dvr/dvr/stream...nifest.f4m?DVR

    the cdn passes the request and it responds

    <?xml version="1.0" encoding="utf-8"?>
    <manifest xmlns="http://ns.adobe.com/f4m/2.0">
    	<id>streamnamedvr.16</id>
    	<width>80</width>
    	<height>60</height>
    	<mimeType>video/mp4</mimeType>
    	<streamType>dvr</streamType>
    	<deliveryType>streaming</deliveryType>
    	<dvrInfo windowDuration="3600"> </dvrInfo>
    	<media width="80" height="60" url="DVR_b125000_w885375480_qRFZS.abst/">
    	</media>
    	<bootstrapInfo profile="named" url="playlist_b125000_w885375480.abst?DVR"/>
    </manifest>
    streamnamedvr.16 = not sure why there is an additional .16 on the streamname?

    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.

    now

    http://cdn.domain.com/dvr/dvr/stream...eg1-Frag113350

    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..

  4. #4
    Join Date
    Dec 2007
    Posts
    21,962

    Default

    I'm not sure I understand what you are trying or expecting. Sounds like it is working for you now? In any case, if you playback "myStream" for the first time from the CDN cache, where Wowza is an HTTPOrigin, the CDN will start pulling those chunks if they are available, any querystring params will be used for that request, and that client will playback the stream as the cache is filled. Then following clients will playback from the CDN cache, and any querystring relevant to Wowza from those following clients will not have any affect, will never reach Wowza, playback is direct from the cache. If some playback client then plays "someAlias" from the CDN for the first time, the same sequence occurs, any querystring wlll be evaluated to fill the cache for myStream2.

    If someAlias is an alias for myStream, they would have the same source but with different querystring params the CDN cache will be different for myStream and someAlias, for example when using a nDVR Playlist Request Delegate. This is the only work-around I know. There is no other cooperation between Wowza and the cache.

    Richard

Similar Threads

  1. Live Repeater Origin-Edge and HTTP Caching Origin
    By vjagannathan in forum General Forum
    Replies: 3
    Last Post: 06-18-2014, 02:56 AM
  2. Live HLS fragments getting cached by the browser (HTTP Origin mode)
    By Florent.T in forum Live Streaming and Encoders
    Replies: 5
    Last Post: 06-08-2014, 07:51 PM
  3. nDVR with origin-mode set to ON
    By tavius in forum AddOn: Wowza nDVR
    Replies: 1
    Last Post: 06-25-2013, 07:35 PM
  4. Authenticate access to application in HTTP origin mode
    By jay_charles in forum General Forum
    Replies: 2
    Last Post: 06-24-2013, 07:59 AM
  5. HTTP Origin and DVR Delegate
    By tavius in forum AddOn: Wowza nDVR
    Replies: 6
    Last Post: 04-29-2013, 12:02 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •