Results 1 to 10 of 10

Thread: Bandwidth consumtion

  1. #1
    Join Date
    Mar 2011
    Posts
    18

    Default Bandwidth consumtion

    I just switched to nDVR and currently have about 24 hour of nDVR window.
    Now, I couldn't help but notice difference in bandwidth consumption.

    With RTMP(JW), a 500k live stream consumes just about 500kbps.
    With SanJose (Strobe), a 500k live stream consumes about 1mbps average.
    With Cuptertino(iOS 5.0.1), a 500k live stream consumes about 4-5mbps average.

    I understand that the delivery mechanism is different from RTMP streaming (a burst for each chunk), but shouldn't the usage pattern average out to the stream's bitrate?

    What am I missing?

  2. #2

    Default

    Quote Originally Posted by misterd View Post
    I just switched to nDVR and currently have about 24 hour of nDVR window.
    Now, I couldn't help but notice difference in bandwidth consumption.

    With RTMP(JW), a 500k live stream consumes just about 500kbps.
    With SanJose (Strobe), a 500k live stream consumes about 1mbps average.
    With Cuptertino(iOS 5.0.1), a 500k live stream consumes about 4-5mbps average.

    I understand that the delivery mechanism is different from RTMP streaming (a burst for each chunk), but shouldn't the usage pattern average out to the stream's bitrate?

    What am I missing?
    I'm a little confused as to what you are comparing, what specifically you are doing and what are you comparing?

    Are you serving a 24 hour recording from your server to your player? Is the DVR 'live' (currently recording?)
    If so, you are probably using a lot of bandwidth b/c the playlist you are sending from server to client will be very very large.

  3. #3
    Join Date
    Mar 2011
    Posts
    18

    Default

    Quote Originally Posted by ScottKell View Post
    I'm a little confused as to what you are comparing, what specifically you are doing and what are you comparing?

    Are you serving a 24 hour recording from your server to your player? Is the DVR 'live' (currently recording?)
    If so, you are probably using a lot of bandwidth b/c the playlist you are sending from server to client will be very very large.
    Let's say I am watching a standard RTMP stream (500kbps video+audio) for 10 seconds, data transferred should be about 5000kilobits. Over 10 seconds, it's 500kbps average.

    When I monitor bandwidth usage of an iOS playing live nDVR (yes, it's currently recording) from the current source (500kbps video+audio) for 10 seconds, data transferred was 50,000kilobits. Over 10 seconds, it's 5,000kbps on average.

    For Flash/Strobe, it's about 2,500-3,000kbps average.

    (Actual test was much longer than 10 seconds. Just used 10 seconds as an example.)

    While the playlist would be very large. I doubt that it would increase playlist size that much.

    Figures above were from the test I made this around noon (CST) today.


    Now (Almost 9pm CST) iOS nDVR streaming barely works at all. It still uses excessive amount of bandwidth, but it only plays for a few seconds before the video stopped playing.

    As for Flash/Strobe, bandwidth usage is back to normal, ~500kbps.


    Does that explain the problem I am seeing?


    Another question :
    Is there anyway that I can just remove "?DVR" part from an iOS URL and make it behave as the same old cupertino live stream? iOS nDVR streaming barely works now, and I just want to switch iDevices to standard streaming in the meantime.
    I tried removing "?DVR" part but got empty playlist from Wowza.

  4. #4

    Default

    Quote Originally Posted by misterd View Post
    Let's say I am watching a standard RTMP stream (500kbps video+audio) for 10 seconds, data transferred should be about 5000kilobits. Over 10 seconds, it's 500kbps average.

    When I monitor bandwidth usage of an iOS playing live nDVR (yes, it's currently recording) from the current source (500kbps video+audio) for 10 seconds, data transferred was 50,000kilobits. Over 10 seconds, it's 5,000kbps on average.

    For Flash/Strobe, it's about 2,500-3,000kbps average.

    (Actual test was much longer than 10 seconds. Just used 10 seconds as an example.)

    While the playlist would be very large. I doubt that it would increase playlist size that much.

    Figures above were from the test I made this around noon (CST) today.


    Now (Almost 9pm CST) iOS nDVR streaming barely works at all. It still uses excessive amount of bandwidth, but it only plays for a few seconds before the video stopped playing.

    As for Flash/Strobe, bandwidth usage is back to normal, ~500kbps.


    Does that explain the problem I am seeing?


    Another question :
    Is there anyway that I can just remove "?DVR" part from an iOS URL and make it behave as the same old cupertino live stream? iOS nDVR streaming barely works now, and I just want to switch iDevices to standard streaming in the meantime.
    I tried removing "?DVR" part but got empty playlist from Wowza.
    A 24 hour playlist will be huge-- on the order of megabytes for the playlist alone. Which would explain your bandwidth. Most players won't accept a playlist that big. I would recommend taking a look at the various nDVR articles, specifically the DVR recording API to break up large recordings in logical chunks and the DVR playlist request, which can be used to select portions of a large recording.

    http://www.wowza.com/forums/content....-Recording-API
    Wowza nDVR Recording API


    http://www.wowza.com/forums/content....st-Request-API
    Wowza nDVR Playlist Request API

    Yes you can use HTTP live streaming. Just remove the ?dvr. Your app needs to be configured for a cupertino live stream packetizer. You probably don't have this, which is why you get an empty playlist.

  5. #5

    Default

    I've noticed the big difference in the bandwidth consumption too when using nDVR. In my case it triples the original stream bitrate. It's due to the periodic playlist requests from the client. Using gzip when sending the playlist could be a solution as it significantly reduces the size of the playlist. According to the HTTP Live Streaming draft RFC (since rfc v.04) the server should support gzip encoding if client request to use it.

    As Scott said it's best to keep the playlist short by using APIs but in my case I can't use it as i need to provide instant access to 24h live nDVR stream.
    Is there any plan to support gzipped playlist in the near feature?

  6. #6

    Default

    Quote Originally Posted by mahmut View Post
    I've noticed the big difference in the bandwidth consumption too when using nDVR. In my case it triples the original stream bitrate. It's due to the periodic playlist requests from the client. Using gzip when sending the playlist could be a solution as it significantly reduces the size of the playlist. According to the HTTP Live Streaming draft RFC (since rfc v.04) the server should support gzip encoding if client request to use it.

    As Scott said it's best to keep the playlist short by using APIs but in my case I can't use it as i need to provide instant access to 24h live nDVR stream.
    Is there any plan to support gzipped playlist in the near feature?
    Mahmut,
    Yes, having a 24 hour live playlist will greatly increase bandwidth. A recorded DVR playlist will not have the bandwidth overhead as the playlist is not requested again and again.
    For a 24 hour live DVR playlist for Cupertino, you are probably sending upwards of 750K-2Mb for each playlist request, depending on the video keyframe sizes. This will occur every few seconds.

    We have not done yet investigated gzip compression, but will make sure its in the enhancement request queue.

    As we've discussed, a couple things we recommend are:
    1. Making smaller recordings.
    2. Using the playlist request API to request portions of the 24 hour playlist. One can still provide access to the stream, but manage it. A simple arrangement would be to be able to request by hours. A more complex one might be to request specific shows in the stream.
    3. Depending on what devices you target, creating longer video keyframe sizes will reduce the amount of data in the playlist.
    4. Use a combination of live DVR streaming and the live stream record module-- use live DVR for most recent portion and the lsr module to archive longer past recordings.

    Besides the amount and frequency of data being sent from server, I have serious doubts of the ability of the players to handle 24 hour live recordings. This is a huge amount of data for the players to manage.

    Scott

  7. #7

    Default

    Quote Originally Posted by ScottKell View Post
    Mahmut,
    As we've discussed, a couple things we recommend are:
    1. Making smaller recordings.
    2. Using the playlist request API to request portions of the 24 hour playlist. One can still provide access to the stream, but manage it. A simple arrangement would be to be able to request by hours. A more complex one might be to request specific shows in the stream.
    3. Depending on what devices you target, creating longer video keyframe sizes will reduce the amount of data in the playlist.
    4. Use a combination of live DVR streaming and the live stream record module-- use live DVR for most recent portion and the lsr module to archive longer past recordings.
    Scott
    Thanks for the reply.
    I will be looking into the playlist request api to come up with manageable playlists though it requires some logic on the client side. My target platform is iOS btw.
    GZip support would be great as it downsize the playlist below 100K which is acceptable. Would you also consider adding some properties to shorten the name of the chunks in the playlist? (i.e. media_12977.ts?wowzasessionid=1919840687&DVR --> 12977.ts?wsid=1919840687&DVR).

    Regarding the keyframes, the encoder I'm using produces variable key frames with 2 to 10 seconds interval. Is there a property in Wowza to merge smaller chunks into bigger one as long as their sum is less than the target-duration?

  8. #8
    Join Date
    May 2011
    Posts
    456

    Default

    Mahmut,
    No, there is not a way in Wowza to merge smaller chunks based on target duration value.

    -Lisa

  9. #9
    Join Date
    Aug 2012
    Posts
    2

    Default

    Does wowza have a plan to support "EVENT Type in #EXT-X-PLAYLIST-TYPE" and "http range with transfering chunklist.m3u8"?
    if wowza support http range in transfering chunklist.m3u8, I think that the client can request only the added part of chunklist.m3u8.

    Have a nice day.

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

    Default

    I don't think #EXT-X-PLAYLIST-TYPE is supported, but byte-range requests are now supported. Apply this patch:

    http://www.wowza.com/downloads/Wowza...1.2-patch8.zip

    Richard

Posting Permissions

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