Results 1 to 4 of 4

Thread: httpOriginMode and nDVR playlists

  1. #1
    Join Date
    Jul 2013

    Default httpOriginMode and nDVR playlists


    I would like to use the httpOriginMode option, to allow end-users to seek back for forth more freely.
    I am using custom playlist, with specific url query parameters. I have a module which changes the setPlaylistStart and setPlaylistEnd on a DvrPlaylistRequest object.

    The documents say, the the httpOriginMode is not supported for url query parameters, because it require the connection to be seassion-less.

    From what I've seen, when a client connects to a stream, even with parameters, the stream itself in not changed for the entire duration of the session.

    Also, I tried enabling the httpOriginMode to a DVR application, and it works perfectly. When I watch a recording I get the buffering at first, but when I go back to the same spot it starts immediately. Also using fiddler, I made sure the client doesn't request the chunk again.

    So, what am I missing? Why the documentation says it shouldn't work? I understand that each session will be buffered again. Is this the reason?


  2. #2
    Join Date
    Dec 2007


    HTTPOrigin is used with CDNs. It does not have the benefit you describe


  3. #3
    Join Date
    Jul 2013



    I understand that the HTTPOrigin was intended to use by CDN, and I understand that from a CDN perspective, it will not work, because each time a user request a stream, it will be with a different url.

    But I look at it from the browser at the end user's perspective.
    When the player at the end-user request a chunk, the browser gets it like any other http object, and by default, the response header disable caching.
    But after I enable the HTTPOrigin, and the response header container cache-control, the browser known that it's in the cache, and does not download the chunk again.

    So, if the end-user is watching a stream, for example from time 00:00:00 until 00:10:00, and then returns to 00:05:00, that chunk is in the browser's cache, and the browser is not downloading the chunk again, which make the resuming very fast.

    Of course, if the user will jump to a point which he didn't watch in that session, it will still buffer.
    And of course, if the user will reload the stream, all the cache won't work.

    But still, it suffice for my project - to be able to seek to a point the user watched, in the same session.

    Still, although It seems to work, I would like to know if you think it shouldn't work, and why.


  4. #4


    it will only work if you have one user at the time. I've tested this many times. If you have HTTP Origin mode "ON", when first user request a DVR extract, let's say from 00:00:00 to 00:10:00, it will give you right extract of it, and you'll be able to play and seek through it. But while that user is playing, another one request from 00:10:00 to 00:20:00, it will get the same extract that first user got ... second user won't get right piece until the session of first extract is dropped. Meaning, it won't work for multiple customer environment.

    How did I solve this? I ended up developing my own module for HTTP Origin for CDN, which accepts queries.

    By the way, when you use CDN and HTTP origin, what browser caches is not much important ... it's what CDN caches, so another request of same content doesn't go to your Wowza but it's served out of CDN directly

Similar Threads

  1. httpOriginMode + DASH
    By karlrasche in forum General Forum
    Replies: 2
    Last Post: 12-16-2013, 05:01 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