Requirement for Transport Stream Streaming Server

Elementary Streams vs Transport Streams in Video Streaming

Elementary streams and Transport streams are terms that originated in the broadcast world - the transport stream allows multiple packetised elementary streams to be carried in a broadcast signal and all provided error correction etc functions. So it is not a case one one versus the other, they are both parts of the overall video deliver technology.

Most internet video streaming, certainly for commercial and video hosting sites, actually uses HLS or DASH streaming now.

These are streaming protocols which deliver the media in fragments or chunks and are referred to generally as Adjustable Bit Rate streaming protocols (ABR).

ABR allows the client device or player download the video in chunks, e.g 10 second chunks, but the server provides each chunk in multiple different bit rate versions. The player can select the next chunk from the bit rate most appropriate to the current network conditions.

So the elementary streams are 'wrapped' in a container, usually an MP4 like container, and then the container is transported by or wrapped in the ABR streaming protocol.

All this seems like a lot of extra overhead, but some of the advantages are:

  • compatibility - most devices or HTML5 players will support HLS or DASH streams
  • The video containers allow extra data, metadata, be included with the media and can include multiple audio and video tracks
  • fast start up - the video can start to play with a lower bandwidth and ramp up to higher over time
  • avoids buffering delays - if the network is bad the chunks will be requested from a lower quality level until it improves
  • related to the above, allows the best quality possible of the given device and network conditions.

It will depend on the application, but for many the first point is probably the most important - most clients devices and players do not support elementary stream playback out of the box.

Documentation of getting the TRANSPORT STREAM from UDP

There are two ways of transporting a MPEG2 transport stream in UDP. One is two just place a couple of MPEG2 TS frames into a UDP packet. The other is to put a number of frames into an RTP packet (which itself is the payload of a UDP packet). The Wikipedia entry is a good starting point for the format. If the first byte in your UDP packet is 0x47, it's most likely TS in plain UDP. If it is something else, it's usually MPEG2 TS in RTP.

If it is RTP, you have to skip the header to find the begin of the payload. See the RfC for details.

What is the major role of Streaming Media Server?

Let me quickly add my understanding to your questions:

1a. Why Media Server? ..

You could write your own software for distributing the stream data to all the players as well. But in that case you would need to implement various transport protocols and you would end up implementing a fairly big piece of software, your home grown media server.

1b. What actually Media Server do to make its role necessary?

A way to see the role of the media server is to either receive the live stream from a stream source and handle the distribution of this stream to probably many-many other players. This usually involves taking the data out from the source transport protocol and repackage it into one or more other container format or transport protocol that the clients favour. Optionally the Media Server can change the way the video or the audio is encoded (transcoding), or produce different resolution and quality streams and provide the players with the list of available qualities in the form of a manifest file (e.g. m3u8 or smil file) so they can do so called adaptive streaming.

An other typical use-case of Media Servers is serving non-live video files to players from disk, as well as recording live streams, and so on. If you look at the feature list of popular media servers, you'll see that they are really doing many things, so practically this is something you probably want to get out of the box and not implement your own.


  1. In my App, I will have to integrate a library for encoding and feed to a streaming server like Wowza. But, how it would be fed to the
    streaming server?

You need to encode the video and audio with a particular codec (such as H.264 for video and AAC for audio), then you need to choose a suitable container format to put these streams into (e.g. MPEG-TS) and then choose a transport protocol to push the stream to the server (e.g. RTMP). Best if you google for tutorials to see how this looks like in code.


  1. How will my server communicate with a streaming server like Wowza?

The contract is basically the transport protocol, one example is using RTMP protocol to connect to Wowza and publish the stream to it. These protocols cover all the technical details.


  1. How Wowza will feed to the stream to the receiving side i.e. the user having an iPhone and needs to see a live stream.

The player software will initiate the communication with Wowza. This is again protocol dependent but in case you are using HLS, the player will use the HTTP protocol to find out the URL of the consequtive video chunks that it will progressively download and display to the user.


  1. What should be at the receiving side. What will decode the stream and will play the stream to AVPlayer ?

It's not clear whether your app under development is the broadcaster side or the player side. But generally on the player side you need to find a library that is able to pull the stream from the media server with the protocol/transport/codec you are using. I am not familiar with this part in iOS, I only have experience with players embedded in websites.

I am not going to draw this, but imagine 3 boxes connected with arrows and that's the data flow. From encoder to streaming server and finally to player. That's it I guess.. :-)

What is the difference between RTP or RTSP in a streaming server?

You are getting something wrong... RTSP is a realtime streaming protocol. Meaning, you can stream whatever you want in real time. So you can use it to stream LIVE content (no matter what it is, video, audio, text, presentation...). RTP is a transport protocol which is used to transport media data which is negotiated over RTSP.

You use RTSP to control media transmission over RTP. You use it to setup, play, pause, teardown the stream...

So, if you want your server to just start streaming when the URL is requested, you can implement some sort of RTP-only server. But if you want more control and if you are streaming live video, you must use RTSP, because it transmits SDP and other important decoding data.

Read the documents I linked here, they are a good starting point.



Related Topics



Leave a reply



Submit