Streaming Blog

Windows Media Ports and Firewalls

Firewalls are often prevent Windows Media streams. Either by protocol or port. Below are the standard ports that Windows Media uses. These must be open in order to watch the video streams over the given ports.

HTTP - TCP port 80
MMST - TCP port 1755
MMSU - UDP port 1755, and TCP port 1755
RSPT - TCP port 554
RTSPU - UDP port 5005, and TCP port 554

Add comment August 10th, 2005

VBR or CBR Encoding

If you are going to be streaming video you should use CBR (constant bit rate) encoding and select the two pass encoding option. This will limit the data transfer rate of the video stream to an amount that you specify. The reason why you do not use the “better quality” VBR encoding is that the rates which are used for encoding sections of the video with lots of movement often goes up to 4mbps or more which is still too high for most consumers to watch.

Two pass encoding means that a first pass of the video is made to identify sections of video with high complexity. A second pass is then made which optimises the encoding to produce the best quality possible throughout the entire video.

Two pass encoding takes longer because a lot more processing is required, but the results are well worth it.

Add comment August 4th, 2005

Digital Rights Management (DRM)

Digital Rights Management is the term given to protecting content to restrict access to media files.

The process of protecting the file with Digital Rights Management consists of the original unprotected file being packaged with an additional header file that identifies details about the license, which is required to play the file. The packaging has got to be completed by a Windows Media Service Provider such as Streaming Wizard.

When a user attempts to play the file, which has been packaged with DRM one of two things happens.

If the Windows Media Player of the person trying to play the content already has a license for the content, then they will watch the video as if it was not encrypted. If they do not have a license, then a request will be sent off to the license server to try to get the necessary license in order to play the file.

The license server will then contain a bunch of business rules, which dictate whether or not the user can have a license, whether they have to put in a username/password to get the license, whether they have to put credit card details in and pay for the license or whatever else.

When these rules have been satisfied, and the appropriate license agreed (such as paying for a one time viewing, or paying for a months subscription) then the license server will send the license to the users Windows Media Player where it will stay for the duration of the license, allowing the user to watch the stream(s) as outlined by the business rules.

Add comment August 1st, 2005

Embedding Windows Media

Embedding Windows Media Player in a web page can get a bit tricky as you have to use different code for different browsers and versions of the player. In order to cater for all of the different circumstances you will have to write some script to autodetect your browser and player versions. Dependent on the circumstances you can then embed the player using the following snippets of code:

Embedding Windows Media Player version 6 in Internet Explorer

<OBJECT ID=Player WIDTH=320 HEIGHT=240
CLASSID="CLSID:22D6F312-B0F6-11D0-94AB-0080C74C7E95">

<PARAM NAME="FileName"

VALUE="http://merlin.streamingwizard.com/demo/animationbroadband.wmv">
</OBJECT>

Embedding Windows Media Player versions 7-10 in Internet Explorer

<OBJECT ID=Player WIDTH=320 HEIGHT=240
CLASSID="CLSID:6bf52a52-394a-11d3-b153-00c04f79faa6">

<PARAM NAME=FileName

VALUE="http://merlin.streamingwizard.com/demo/animationbroadband.wmv">
</OBJECT>

Embedding Windows Media Player in NetScape, Firefox or other Mozilla based browsers

<EMBED TYPE="application/x-mplayer2"
SRC="http://merlin.streamingwizard.com/demo/animationbroadband.wmv"
NAME=MediaPlayer
WIDTH=320
HEIGHT=240>
</EMBED>

Add comment July 26th, 2005

Windows Media Live Streaming Pull vs Push

Windows media streaming allow you to broadcast a live stream in two different ways.

A “Pull stream” consists of the encoding machine running independently of any clients. Once it has started clients can tune in to the broadcast by connecting to the encoder directly on the ip address and port that the encoder is using.

It is possible to restrict access to the encoder by ip address so as to prevent unauthorised users connecting or to prevent the local connections bandwidth supply from becoming saturated, which will lead to buffering and loss of service.

If the encoding computer is behind a firewall or on an internal network then external users will not be able to connect to the stream unless port forwarding is set up and the firewall allows access from an external ip address.

The advantage that a Pull stream has is that if no users are watching the stream, then no bandwidth is used up until someone tunes in to the stream.

Normally Pull streams are used for 24×7 streaming. The encoder restricts access to it’s stream to the ip address of a distribution server. Clients then tune in to the distribution server. The first connection will instigate a connection from the distribution server to the encoder and start running the stream. Subsequent connections will come directly from the distribution server. Once all clients have closed their media players and stopped watching the connection between the distribution server and encoding computer will be closed to save bandwidth and remain in this state until the next person connects to the stream.

A “Push stream” works in a more pro-active way.

The encoder connects directly to the distribution server and sends it’s stream out regardless of if anyone is watching it. Clients tune in to the distribution server and watch the stream directly from there. The advantages of using a Push stream are that the encoder “knows” that the connection has been made and an error will be reported if there is a problem. (With a push stream, as a connection is not necessary you manually have to check that everything is working). The disadvantages of a push stream are that there are the inherent bandwidth overheads of sending out the stream regardless of whether or not anyone is watching the stream. Also at the server side it is a little bit harder to split the log files to create analysis reports afterwards.

Push streams are normally used for short one off webcasts as opposed to 24×7 streaming.

Add comment July 21st, 2005