• Get involved.
    We want your input!
    Apply for Membership and join the conversations about everything related to broadcasting.

    After we receive your registration, a moderator will review it. After your registration is approved, you will be permitted to post.
    If you use a disposable or false email address, your registration will be rejected.

    After your membership is approved, please take a minute to tell us a little bit about yourself.
    https://www.radiodiscussions.com/forums/introduce-yourself.1088/

    Thanks in advance and have fun!
    RadioDiscussions Administrators

Problem with Windows Media Stream

Our station is having a problem with our Windows Media stream. Several listeners have called, reporting that our stream "stutters" at times or has other issues on all players (7, 9, 10, 11). From my home computer, I've heard the problem as well.

After some investigation, I've discovered that the problem occurs only when the players connect to the stream using the UDP protocol. The problem does NOT occur if the player connects using either HTTP or TCP. It seems the easy solution is to eliminate the encoder's UDP protocol and stream only the TCP and HTTP protocol. Is there a way to do this? So far, I haven't discovered one.

THANKS!
 
I believe that on your server you can change it to do http only. I can't remember where off the top of my head. I'll take a look for you tomorrow.
 
speakerman said:
UDP works on closed LANs but falls apart on the internet. It is often termed "Unreliable Data Packets" due to the lack of error correction.

You might consider switching from Windows Monopoly Player to this format.

http://www.wowzamedia.com/index.html

Check out NPR Flash streaming. http://www.npr.org/templates/player/mediaPlayer.html

UDP is used when low latency is required, such as in VOIP. UDP per se' is NOT a bad procol, it just doesn't have any data error correction (as TCP does). That said, it also is bandwidth efficient (no ACKS flying back and forth netween servers). When using UDP, error concealment is used in the receiver, which reconstructs data based upon what was there before and is there after the loss. For this to work properly, a decent sized buffer is needed. The default for Windows Media is: "let Windows Media set the buffer" .
Unfortunately, Windows Media SUCKS at setting the buffer-so stutters happen. There is a way to override this setting in Windows Media-and most who listen to a lot of streaming have already done so-though it also can be said that those who really listen to streaming use Winamp (a far, far better player).


The preferred mode of streaming in the Barix units is UDP. Both RTP and BRTP use UDP as their underlying protocol. This is why we recommend a two second buffer in the Exstreamer. Raw UDP streaming is also available in the Instreamer (and the stock Exstreamer's firmware) and I have many customers using it successfully for mission critical applications like STLs all over the place. You can also use raw TCP as a protocol-but we recommend against it unless you have a transmission path with a LOT of packet loss (some Internet connections that cross ISPs have this problem). BUT that said, we use TCP as a 'last ditch' solution when UDP can not be made to work.
 
Status
This thread has been closed due to inactivity. You can create a new thread to discuss this topic.


Back
Top Bottom