Results 1 to 5 of 5

Thread: Server and client problems

  1. #1

    Default Server and client problems


    We are performing live streaming from public lectures and used Windows Media Services successfully for many years.
    Now we changed to Wowza for evaluation purpose and experienced a lot of problems on the client side with buffering.

    We applied all the tuning tips, server hardware is Xeon 2x Dual Core AMD Opteron 2.6 GHz CPU, 16GB RAM running Windows Server 2008 R2 with 1Gbit/s uplink at Level(3) facility Munich where also the old Windows Media Server is located. So server connectivity is not an issue. Clients mainly come from DSL providers in Germany but also worldwide.

    We used Adobe Strobe player with sanjose HTTP stream URL and stream groups created from the transcoder plugin. Clients experienced a lot of buffering and even complete breaks. We tried with JW Player and the multiple bitrate RTMP streams produced by jwplayer.rss Provider with the same result. It was really bad and nobody had a smooth streaming experience. About the cupertino streams I cannot remember any more.

    In the logs we could see a lot of stream connects and disconnects happening every second. Client number was at about 300. Source stream bitrate was at 850kbit/s using FMLE which degraded the bitrate automatically some times down to 400kbit/s and then back again to 850

    Then we undid the server tuning actions, first I turned on the Windows TCP Autotuning again with no improvement.
    Then I undid all the Java memory and CPU tunings and switched back from JDK Java VM 1.7.1 to JRE 1.6.2 shipped with Windows. Both were the x64 server variants. Don't nail me down on the exact version numbers, but this improved the situation and the clients had a much better streaming experience although still not free of buffering but now much longer periods of uninterrupted viewing. cupertino streams worked flawlessly.

    We also did some network optimizations on the sender side. We had a ADSL line with 1Mbit/s up and 16 down, speed was quite OK, but ping times to the Wowza server varied from 23 to 80ms and worse quite often. We tweaked some router settings and set the stream bitrate to 600kbit/s, FMLE never decreased bitrate. This gave us constant ping times from 23-27ms and uninterrupted viewing on the client side for over 3 hours of stream!!!

    But now at another event we had an SDSL line with 2Mbit/s up and down and ping times at 12-20ms when no stream is running. I was sending with 1.2Mbit/s and had ping times from 32 to 50ms, FMLE did not decrease bitrate. Clients using sanjose HTTP stream experienced significantly more buffering than those with RTMP in JWPlayer which almost played flawlessly expect some glitches from time to time. cupertino streams worked flawlessly. All stream types use adaptive bitrate streaming from the transcoder plugin. Now we had almost 500 viewers which gave the server CPU almost 75% constant load.

    Before deciding to buy Wowza I would like to ask for some feedback on my resulting questions:
    - what was behind the massive problems after applying the tuning actions and how to really tune it without these negative effects?
    - how does CPU consumption correlate with source stream bitrate, transcoded streams and number of viewers?
    - why does varying network latency from sender to server affect viewer experience quite strongly while Windows Media was totally stable from the same locations earlier?
    - why is RTMP in JW Player working better than sanjose in Strobe Player? Also viewers from countries with bad Internet quality had a significantly better experience with RTMP in JW. Is there a way to make sanjose as stable as RTMP?

    Thanks very much in advance,

  2. #2


    "buffering" is caused by insufficent network throughput. It is unrelated to Wowza for the most part.

    You want to identify if the bandwidth limitation is on the encoding side's Internet connection, your server's internet connection, or Internet connection of the clients playing the stream.

    If you notice a difference between RTMP and HTTP multibitrate streams, it is likely caused because one of the streams is not switching to a lower bitrate when there is not enough bandwidth. Use network monitoring tools to identify the actual bitrate being streamed. This is rather difficult to do when using an HTTP segmented protocol since it sends chunks of data in bursts at the maximum rate possible for the connection, as opposed to RTMP or RTSP which send data at the stream's actual bitrate. If your player can provide feedback as to which bitrate rendition is being requested/streamed, (like the Wowza silverlight examples) this is a better technique.

    There are two issues I can think of:
    1. "Source stream bitrate FMLE [...]some times down to 400kbit/s and then back again to 850" This will cause issues when transcoding, especially if it results in Wowza attempting to transcode to a higher bitrate than exists at the source. (not 100% sure, but that's my understanding)

    -Ensure that the encoding bitrate does not fluctuate, either by lowering it, or upgrading to business-class network infrastructure. And ensure you are only transcoding to bitrates and resolutions lower than the source.

    2. Variable bitrate encoding, or a dramatic reduction in bitrate like you mentioned, does not work well with multibitrate streaming on the client side. It causes the bitrates defined in the smil/media list to be different than the actual bitrates, and the player does not know how to handle this, which causes inconsistent playback issues. Some player technologies handle it better than others. It is not something that can be resolved by Wowza.

    -ensure the source stream quality is consistent.

    3. If you see different results with different tuning settings, you can post your server specs, and your changes:
    a. The log output from when Wowza first starts, which shows your specs.
    b. Server specs
    c. conf files you changed

    4. "Also viewers from countries with bad Internet quality had a significantly better experience with RTMP in JW. Is there a way to make sanjose as stable as RTMP?"
    Possibly by adjusting some buffer, chunk target duration or some such. Maybe your RTMP player has a larger receive buffer than your San Jose HTTP player.

  3. #3


    Thanx for the info!

    Basically server connectivity is not a problem. Sender connectivity however varies from different places. We will not use bitrate degration according to your recommendation and instead configure to drop frames. At least these two options are available in FMLE. But will it affect audio and video synchronizity?

    I conclude from your answer that RTMP is to be preferred over HTTP since it is a real streaming protocol and it will use the actual stream bitrate.

    And can you please tell a little bit more about how CPU consumption correlates with source stream bitrate, transcoded streams and number of viewers?

    Also I would like to apply the tuning recommendations again and will then send you configs and logs. However I need to find the right time when we do not disturb our clients too much with these experiments. Can you tell which Java version is supported?


  4. #4


    I'm not sure about the dropping frames. I can't think of why it wouldn't work, but you'll want to test it, by setting too high of a bitrate. If a delay in playback is acceptable, increasing the sort buffer on the Wowza side might help mitigate short client-side bandwidth issues. But, using business-class network infrastructure, a dedicated Internet connection, and ensuring the stream is a low enough bandwidth is the best solution. You can also use higher encryption complexity to get a better looking stream from lower bitrates.

    SanJose HTTP should work well for multibitrate. If it wasn't working as good as RTMP, you'll want to ensure HTTP is switching properly and that your smil is setup correctly. I recommend using whatever works best in your testing.

    All the info I have about CPU usage is in the Transcoder Benchmarks.

  5. #5


    I applied the tuning instructions again and it looks much better now. maybe I did a mistake the last time.

    CPU consumption definitely comes from transcoder plugin. We send the source stream with H.264 and MP3 at 1.2Mbit/s. transcoded bitrates are 300, 124 and 80 kbit/s. before the tuning, CPU was at 60% without any viewers. With 1000 viewers, server was up to 99% all the time on all cores.

    Then after tuning, we had 50% without any viewer and currently at 850 viewers we have 80%

    I guess we need hardware acceleration on our main server or install a repeating server.


Similar Threads

  1. problems with wowza server..
    By pezehk in forum General Forum
    Replies: 14
    Last Post: 02-11-2013, 09:53 AM
  2. Old Server, New problems - Cool commands
    By ajhalls in forum Performance Tuning Discussion
    Replies: 4
    Last Post: 07-30-2012, 06:35 PM
  3. Wowza server problems
    By krlosFD in forum General Forum
    Replies: 1
    Last Post: 06-09-2012, 02:44 AM

Posting Permissions

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