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

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 234.3.2.234 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)) 10.13.28.12 > 224.0.0.22: igmp v3 report, 1 group record [gaddr 234.3.2.234 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?

i.e

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

Thanks!

Thank you very much for implementing that.

Unfortunately my system operations department looked at me in a very disapproving manner when I mentioned the requirement to install preview software in production…

I’ve been told that they are keen for me to test this in the lab (which I will do) with the intention to roll it out when Wowza 2 goes full release.

In the meantime the network guys are going to statically join the network ports for these 3 servers to the multicast stream.

I’ll let you know how it goes in the lab and how the rollout goes when Wowza 2 is released.

Thanks.

Hrmm a small question about this plugin.

I’m currently solving my IGMPv3 problem by statically joining the ports to the multicast stream.

I’m sending a raw UDP/TS stream to the port. 500k/s H.264 and 96k/s HE-AAC audio.

When I connect in my browser all the backend stuff seems to work. I buffer for a few seconds and then the stream starts playing but it’s highly jittery in video and audio. It stop and starts and jumps all over the place.

What’s weird is that if I set my encoder to deliver mpeg for the audio the video stream cleans up to perfect and plays smoothly but I have no audio. (logs show no connection to an audio stream)

Is this a problem with codecs? Or me sending a UDP/TS rather than an RTP stream?

Debug below.

INFO|server|comment|2009-12-08|06:21:53|-|-|-|-|-|-|-|-|-|-|354438.641|-|-|-|-|-|-|-|ModuleStreamNameAlias.play: bloomberg=udp://234.3.2.234:1234

INFO|server|comment|2009-12-08|06:21:53|-|-|-|-|-|-|-|-|-|-|354438.642|-|-|-|-|-|-|-|MediaStreamMediaCasterPlay: startPlay

INFO|server|comment|2009-12-08|06:21:53|-|-|-|-|-|-|-|-|-|-|354438.647|-|-|-|-|-|-|-|RTPMediaCaster.create

INFO|server|comment|2009-12-08|06:21:53|-|-|-|-|-|-|-|-|-|-|354438.647|-|-|-|-|-|-|-|RTPMediaCaster.init

INFO|server|comment|2009-12-08|06:21:53|-|-|-|-|-|-|-|-|-|-|354438.648|-|-|-|-|-|-|-|RTPMediaCaster.Reconnector: start

INFO|server|comment|2009-12-08|06:21:53|-|-|-|-|-|-|-|-|-|-|354438.648|-|-|-|-|-|-|-|RTPSessionDescriptionDataProviderBasic.getStreamInfo: URI: udp://234.3.2.234:1234

INFO|stream|create|2009-12-08|06:21:53|-|-|-|-|-|-|-|-|-|-|0.0|-|1|0|0|-|-|-|-

INFO|stream|create|2009-12-08|06:21:53|-|-|-|-|fms.iinet.net.au|rtplive|-|-|-|-|0.0|-|1|0|0|-|-|-|-

INFO|stream|publish|2009-12-08|06:21:53|-|-|-|-|fms.iinet.net.au|rtplive|-|-|-|-|0.012|udp://234.3.2.234:1234|1|0|0|-|-|udp://234.3.2.234:1234|-

INFO|server|comment|2009-12-08|06:21:53|-|-|-|-|fms.iinet.net.au|rtplive|-|-|-|-|354438.664|-|-|-|-|-|-|-|MulticastTransport.bind: 234.3.2.234/1234

INFO|server|comment|2009-12-08|06:21:53|-|-|-|-|fms.iinet.net.au|rtplive|-|-|-|-|354438.664|-|-|-|-|-|-|-|RTPMediaCaster.Reconnector: stop

INFO|server|comment|2009-12-08|06:21:53|-|-|-|-|fms.iinet.net.au|rtplive|-|-|-|-|354438.706|-|-|-|-|-|-|-|MulticastTransport.firstPacket: 234.3.2.234/1234

INFO|server|comment|2009-12-08|06:21:53|-|-|-|-|fms.iinet.net.au|rtplive|-|-|-|-|354438.862|-|-|-|-|-|-|-|RTPDePacketizerMPEGTS.handleRTPPacket: videoPID: 0x820

INFO|server|comment|2009-12-08|06:21:53|-|-|-|-|fms.iinet.net.au|rtplive|-|-|-|-|354438.862|-|-|-|-|-|-|-|RTPDePacketizerMPEGTS.handleRTPPacket: audioPID: 0x830

INFO|stream|play|2009-12-08|06:21:58|542551126|203.59.130.32|-|203.59.140.102|fms.iinet.net.au|rtplive|80|rtmp://fms.iinet.net.au/rtplive/|3603|3568|4.336|udp://234.3.2.234:1234|1|0|0|-|-|udp://234.3.2.234:1234|-

Never mind… ignore me… It does look like it’s because the Stream is a RAW UDP/TS… I attached to the stream with VLC, re-encapsulated it in an RTP multicast stream and then Wowza sends it fine.

I’ll find a way to work round this…

Thanks for your time

Hopefully this should be an easy question. Is there anywhere that lists all the possible properties for an RTP stream or streams in general in the Applications file?

I’m getting seriously jerky audio/video when re-streaming RTP video from a particular encoder we’re using but the video plays fine when rtp streaming from VLC.

I just want to know what settings I can tweak other than “sortPackets” and “BufferSize” if anything.

Setting the logs to debug shows no obvious errors, it just doesn’t play correctly.

Hrmm that’s odd. Because it plays fine if I take the very same stream and re-encapsulate it in RTP with VLC. I’m more suspecting that the particular encoder we are using is doing something funny with the RTP headers that Wowza isn’t expecting?

All other sources play fine, except from this one encoder.

Here are a TS Reader output for both streams.

http://www.angry-monk.com/support/not-working-encoder-stream.jpg

http://www.angry-monk.com/support/working-vlc-stream.JPG

one of the major things I can see is that the VLC stream Puts the PCR on the same PID as the video stream which the encoder doesn’t do. Could this cause the problem?

Looks like it’s an Audio timing issue… I followed the instructions in this thread here.

http://community.wowza.com/t/-/57

(point 4. MPEG-TS missing audio) and all of a sudden I have working video and audio! Hurrah!

My problem now is that the video and audio fall out of sync over time no matter what I set the servers sortbuffersize to.

I’ve also tried all three options for the

Suggestions?

I get situation A. If I play it drifts out of sync. If I stop and restart the stream in the player they are initially in sync and slowly fall out of sync.

Chris

Any suggestions for this scenario?

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.

I on the other hand have a license for MPEG-TS injest and I’m getting the same error :s

Hello Charlie,

I have some problems with streaming my live video. I am streaming on standard udp and I can see that there is lots of package loss and picure is falling appart.

Can you help me with this? What info do you need from me?

Thanks,

KB

Tried following this guide and adding the stream properties but still no stream.

I have been using a Telairity BE8500 encoder for testing. We have been able to test HD to a point and then it breaks. Anyhow, we are now trying to test SD video with flash and cannot even get it running. Here is the error we keep seeing:

WARN server comment 2011-09-30 09:53:38 - - - - - 594.918 - - - - - - - - RTPDePacketizerMPEGTS.handleRTPPacket: Out of sync: 0x80

WARN server comment 2011-09-30 09:56:05 - - - - - 741.462 - - - - - - - - RTPDePacketizerMPEGTS.handleRTPPacket: Out of sync: 0x80

WARN server comment 2011-09-30 09:58:06 - - - - - 862.644 - - - - - - - - RTPDePacketizerMPEGTS.handleRTPPacket: Out of sync: 0xff

I can transport in UDP/RTP modes but I get this same result from both. Can anyone give me any suggestions or ideas as to what may be going on here?

Thanks,

Jason

I’ve seen this before when I had 2 different streams pointing to the same udp port.

I have been using a Telairity BE8500 encoder for testing. We have been able to test HD to a point and then it breaks. Anyhow, we are now trying to test SD video with flash and cannot even get it running. Here is the error we keep seeing:

WARN server comment 2011-09-30 09:53:38 - - - - - 594.918 - - - - - - - - RTPDePacketizerMPEGTS.handleRTPPacket: Out of sync: 0x80

WARN server comment 2011-09-30 09:56:05 - - - - - 741.462 - - - - - - - - RTPDePacketizerMPEGTS.handleRTPPacket: Out of sync: 0x80

WARN server comment 2011-09-30 09:58:06 - - - - - 862.644 - - - - - - - - RTPDePacketizerMPEGTS.handleRTPPacket: Out of sync: 0xff

I can transport in UDP/RTP modes but I get this same result from both. Can anyone give me any suggestions or ideas as to what may be going on here?

Thanks,

Jason

We have everything on different ports. That was the first thing I checked. We are running our secondary encoder (QVidum) into the same port we tried this on and it is working fine.

I am using port 10000 for one and 6002 for the other. I figured this out. My encoder reset its audio to Mpeg 1-2, Changed it to AAC and its working now.