Wowza Community

Using an MPEG Transport Stream (MPEG-TS) encoder with Wowza Pro (MPEG-TS)

Step by step instructions for using a MPEG Transport Stream encoder (MPEG-TS) with Wowza Pro (Flash Player version or greater is required).

  • Send an email message to to obtain a 30-day evaluation license for Wowza Media Server Pro for MPEG-TS

  • Download and install Wowza Media Server Pro (version: Wowza Pro 1.7.0 or greater) and edit the file [install-dir]/conf/Server.license and enter your 30-day evaluation license

  • Create a new Wowza Pro application for streaming (may already exist if examples installed)

  • Create the folder [install-dir]/applications/rtplive

  • Create the folder [install-dir]/conf/rtplive

  • Copy the file [install-dir]/conf/Application.xml into this new folder [install-dir]/conf/rtplive

  • Edit the newly copied Application.xml and make the following changes:

  • Change Streams/StreamType to rtp-live

  • Add following properties to Streams/Properties container (there are several containers, be sure to add to correct container)

  • Startup the Wowza Pro server

  • Configure the encoder to send the stream to the Wowza Pro server’s ip address and a given port number of your choosing (this number is used below as the [port] part of the stream name when you play the stream). It is probably best to choose a port number greater then 10000 as to not conflict with regular RTSP/RTP streaming. If the Wowza Pro server is behind a router that uses NAT (network address translation) send it to the routers external ip address and be sure to map the UDP port to the correct internal ip address. Be sure that the time-to-live value on the encoder is high enough so that the stream is able to reach the server running Wowza Pro (time-to-live explained)

  • To play the stream, double click [install-dir]/examples/LiveVideoStreaming/client/live.html, set Server to rtmp://[server-ip-address]/rtplive (where [server-ip-address] is the ip address of the server running Wowza Pro) and Stream to udp://[port] (where [port] is the UDP port to which you sent the MPEG-TS stream) and click the Play button.


    Windows (default): C:\Program Files\Wowza Media Systems\Wowza Media Server Pro [version]

    Mac OS X: /Library/WowzaMediaServerPro

    Linux: /usr/local/WowzaMediaServerPro

    Note: If a stream name of udp://[port] does not work it might be necessary to use the stream name udp://[server-ip-address]:[port] (where [server-ip-address] is the ip address of the server running Wowza Pro).

    Note: If your MPEG-TS stream contains multiple video or audio channels (pids) you can choose which one to play by specifying the pid number as part of the stream name url. For example if your stream has multiple audio channels that use pid id’s 22, 23, 24. You can choose to play pid 23 by using the url:


    Note: Many players will not accept stream names that look like urls. You can use the stream name alias package to create an alias for the stream name url. This package can also be used to secure Wowza Pro so that it will only be able to restream urls that you specify. This package can be downloaded from here: StreamNameAlias.

    Note: If you experience problems getting either the audio or video to play through Flash, double check the version number of the Flash player (Flash player version or above is required). If you still have problems, turn on Wowza Pro debug logging (edit [install-dir]/conf/ and change the log4j.rootCategory on the first line from INFO to DEBUG), try the encoder several more times, zip up and send your [install-dir]/logs folder along with screen shots of the encoder setup screens and the LiveVideoStreaming player screen and send a detailed description of your problem to


Kind of. Wowza Pro will connect to the MPEG-TS UDP stream when the first player requests the stream. It will stay connected to the stream as long as someone is playing the stream. When the last player disconnects it will remain connected to the stream for 10 seconds then of noone else requests the stream it will disconnect from the stream. The encoder is always sending the stream to the ip-address/port.

I hope that makes sense.


  1. It just means it is binding to the local interface. This should pickup all local network interfaces. If it is not working then you can specify a specific local address and it will bind to only that address.


We do not have any means to block or control UDP flowing in and out of specific ports. You will need to use a firewall or iptables to control access.


We can only handle H.264/AAC over MPEG-TS. We cannot handle MP3 audio.


Yes, we should be able to handle HE-AAC as well.



where can I get a “MPEG Transport Stream encoder”?

In current system we already have live MpegTS video. We want to broadcast it using Wowza. Can you suggest a device or software to re-encode this video to H.264?


Mustafa Aldemir

Hi Charlie,

Currently I’ve testing Wowza with h264 MPEG-TS, work good only detect one Issue with Audio Sync

I try to describe the platform:

VideoRunner ASI to IP --> VLC MPEG-TS Input --> VLC H264 TS Output --> Wowza Server --> Flash player

The H264 TS Output have 2 audio Tracks, when Play the Stream, 5/10 seconds after, the audio is OutOfSync

I’ve use with success this other settings without problem, but only have one audio Track:

VideoRunner ASI to IP --> VLC MPEG-TS Input --> VLC H264 RTP Output --> Wowza Server --> Flash player

My VLC VLM Setting is:

new spa-pnr broadcast enabled

setup spa-pnr input udp://@:20060

setup spa-pnr option sout-all

setup spa-pnr output ‘#transcode{venc=x264{keyint=30},deinterlace,vcodec=x264,acodec=mp4a,vb=500,ab=32,scale=.5,sfilter={marq{marquee=For Internal Use Only,x=3,y=10,color=16776960}}}:std{access=udp,mux=ts,dst=}’

control spa-pnr play

In the Wowza Logs show:

INFO server comment 2009-04-14 17:11:59 - - - - - 23157.031 - - - - - - - UDPTransport.firstPacket: /

INFO server comment 2009-04-14 17:12:00 - - - - - 23157.135 - - - - - - - RTPDePacketizerMPEGTS.handleRTPPacket: videoPID: 0x44

INFO server comment 2009-04-14 17:12:00 - - - - - 23157.136 - - - - - - - RTPDePacketizerMPEGTS.handleRTPPacket: audioPID: 0x45

INFO server comment 2009-04-14 17:12:00 - - - - - 23157.136 - - - - - - - RTPDePacketizerMPEGTS.handleRTPPacket: audioPID: 0x46

INFO stream play 2009-04-14 17:12:00 762666710 157.XXX.XXX.XXX - 3488 3587 1.186 udp://@ 44 0 0 - - udp://@ -

INFO server comment 2009-04-14 17:12:30 - - - - - 23187.534 - - - - - - - MediaStreamMediaCasterPlay: close

Update Logs Access in DEBUG Mode:

DEBUG server comment 2009-04-14 20:45:25 - - - - - 1065.008 - - - - - - - RTPDePacketizerMPEGTS.flushAudioBuffer: packet: 2688789

DEBUG server comment 2009-04-14 20:45:25 - - - - - 1065.009 - - - - - - - writePacket[aud]: sz:175 tc:2688789:2688789:1239752725860

DEBUG server comment 2009-04-14 20:45:25 - - - - - 1065.012 - - - - - - - checkFlush[false,true,50]: tc:2688789>2688818 || rt:1239752725860>1239752725894

DEBUG server comment 2009-04-14 20:45:25 - - - - - 1065.012 - - - - - - - RTPDePacketizerMPEGTS.flushAudioBuffer: packet: 2688809

DEBUG server comment 2009-04-14 20:45:25 - - - - - 1065.013 - - - - - - - writePacket[aud]: sz:149 tc:2688809:2688809:1239752725864

DEBUG server comment 2009-04-14 20:45:25 - - - - - 1065.013 - - - - - - - checkFlush[false,true,50]: tc:2688809>2688818 || rt:1239752725864>1239752725894

DEBUG server comment 2009-04-14 20:45:25 - - - - - 1065.024 - - - - - - - RTPDePacketizerMPEGTS.flushVideoBuffer: packet: 2688783

DEBUG server comment 2009-04-14 20:45:25 - - - - - 1065.025 - - - - - - - nalUnit: hdr:41 sz:1815:1819 typ:SLICE

DEBUG server comment 2009-04-14 20:45:25 - - - - - 1065.025 - - - - - - - writePacket[vid]: sz:1824 tc:2688783:2688783:1239752725876 key:false

DEBUG server comment 2009-04-14 20:45:25 - - - - - 1065.025 - - - - - - - checkFlush[false,true,50]: tc:2688809>2688818 || rt:1239752725876>1239752725894

DEBUG server comment 2009-04-14 20:45:25 - - - - - 1065.04 - - - - - - - RTPDePacketizerMPEGTS.flushVideoBuffer: packet: 2688817

DEBUG server comment 2009-04-14 20:45:25 - - - - - 1065.041 - - - - - - - nalUnit: hdr:41 sz:1521:1525 typ:SLICE

DEBUG server comment 2009-04-14 20:45:25 - - - - - 1065.041 - - - - - - - writePacket[vid]: sz:1530 tc:2688817:2688817:1239752725892 key:false

DEBUG server comment 2009-04-14 20:45:25 - - - - - 1065.041 - - - - - - - checkFlush[false,true,50]: tc:2688817>2688818 || rt:1239752725892>1239752725894

DEBUG server comment 2009-04-14 20:45:25 - - - - - 1065.056 - - - - - - - RTPDePacketizerMPEGTS.flushAudioBuffer: packet: 2688831

DEBUG server comment 2009-04-14 20:45:25 - - - - - 1065.057 - - - - - - - writePacket[aud]: sz:166 tc:2688831:2688831:1239752725908

En RTPLIVE Application Setting for RTP Sync Metod I use on Both configs:




Thanks in Advance for any Help…

Is possible send the URL for you test but only for Private.



Sorry if these instructions seem clear as mud to me… but I have a few questions.

First, how do you know which UDP port to us? Is it just something you pick anytime or is it something that is configured somewhere in WMS?

Second, step 5 talks about [server-ip-address] and [ip-address]. What is the difference? It defines [server-ip-address] as the WMS server and [ip-address] as the ‘destination’. Well, isn’t the destination the WMS server???

Basically I’m trying to send an MPEG-TS to WMS and play it back but not really seeing much. I see in the logs when I try to connect the client, WMS appears to then decide it wants to publish the port, but I never see anything come back around. Netstat shows a listener on the port I just picked out of my arse when I click ‘play’ in the client but WMS logs don’t show that anything is even attempting to play.

So in summary I guess I need to know:

What the difference really is between [server-ip-address] and [ip-address] as noted above, what port should I be using, and are there any additional configs needed in WMS to let it know what to do with these various ports/etc?



My ts stream with h.264/mp3 encoding can play well with vlc. However, when feeding this stream to wowza, there is no sound. Why?

Hi there, I’m trying our a test of this process with attaching to a multicast stream of an h.264 encoded video with AAC audio encoded in a transport stream.

We’re looking at taking our current IPTV offering and making it available via our website and I’ve downloaded and installed a trial of Wowza. I got the trial License and applied it and re-started the server.

I connect to udp:// (the multicast URL)

I then fired up the App as defined here and I get the following error in the logs.

"WARN server comment 2009-11-11 17:58:32 - - - - - 1984.442 - - - - - -

  • Failed to find an appropriate depacketizer for this track (MP2T): You may not have the proper software license to use this feature. Please contact for more information."

Is this actually a license issue or is Wowza not able to decode an mpeg transport stream container?

Sounds like you are using Wowza Pro10 - it doesn’t support MPEG-TS ingest. We just emailed you a 30-day evaluation license that does. Let us know how your test progresses.

Can you provide more information…

  • What do you see when you poll the server from a browser with


I would first verify that you in fact have the correct license key installed.

What encoder are you using? Also, are you sure you’re sending H.264/AAC over MPEG-TS?

VLC might be able to do this but it does not seem all that stable. I can’t think of any other hardware/software encoders that can take in an MPEG2 transport stream and spit out H.264. VLC is the only one that comes to mind. You may want to contact Digital Rapids. They may have a solution that supports this mode of operation.


VLC is tough. It is pretty buggy in this area. If the audio is out by 5 seconds not sure there is much we can do. It is most likley off somewhere inside of VLC. With mpeg-ts the audio/video is pre-synced. So the AVSyncMethod does not come into play. This is only used for RTP. With MPEG-TS we use the sync provided to use inside the MPEG-TS stream. All streams are to use a 90Mhz clock and the video/audio packets are to use the same time basis.


First, how do you know which UDP port to us? Is it just something you pick anytime or is it something that is configured somewhere in WMS?

You pick any ports you like. It is configured on the encoder side. You are basically sending a UDP signal to the server running Wowza Pro on a specific port. Wowza Pro is simply binding to that port and decoding the stream.

Second, step 5 talks about [server-ip-address] and [ip-address]. What is the difference? It defines [server-ip-address] as the WMS server and [ip-address] as the ‘destination’. Well, isn’t the destination the WMS server???

They are the same thing. I have updated the instructions. It is best in the stream to just use as the ip address. This will instruct Wowza Pro to bind to the default address. If this doesn’t work then you can try [server-ip-address].


  1. Can the streamer do a IGMPv1 join to a existing Multicast stream containing a Mpeg2TS 188bytes stream (h.264 and aac Elementary streams)?

Yes, this should work great. You might get better performance from this development build. I enhanced our multicast performance:

  1. Can it remux and remap it unicastly over RTMP for viewing on Flash 10?

Yes, that is exactly what it does.

  1. Are there any security mechanisms that i can set restrictions from the streamingserver regards to where the client comes from and so on?

Yes, see this post:


I will look into this and get back to you.


Hi there, I’m having a bit of an issue with Wowza and the re-broadcast of a multicast stream into a flash site.

We have Cisco routers which are acting as multicast controllers. When I fire up VLC on the same host as wowza transmitting to I have no trouble connecting with the RTPMulticastListener. However… we have implemented the actual stream to our edge Cisco routers not via local vlc.

When I connect to the stream I see all the right things happening in Wowza. And a tcpdump on the eth0 interface shows the IGMPv3 join packet going out to the routers.

02:26:55.039008 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 40, options (RA)) > igmp v3 report, 1 group record [gaddr to_ex, 0 source ]

The problem is that the stream never starts. I’m told by the Cisco guys here they they see the IGMPv3 query coming through but that they are using “source specific multicast” for these streams and that, as the join lacks the source IP, the router is rejecting the request.

I’m told if I can configure Wowza to send this… or alternatively configure it to send a IGMPv2 join they can apply a hack on the router which will map the group to the source.

Are either of these things possible?


Sending the source IP for the source specific multicast IGMPv3 join or sending an IGMPv2 join instead?


OK, I finally got around to adding support for this. Try the following. First, I could only add this additional support to Wowza Media Server 2 Advanced. So you need to install the preview version to get this new functionality. Signup and install preview 9 from here:

then install this patch:

Then setup your application as normal. In addition set the following property in the RTP/Properties container in [install-dir]/conf/Applicaton.xml (be sure to get the correct properties container - there are several in the file):


Set the value to the desired bind to value. Let me know if this works.


We do not have them documented in this way. Jerky playback like this is usually attributed to the player having the NetStream.bufferTime value set to zero. I would suggest you have at least a buffer of between 2-5 seconds. See if that helps.