Wowza Community

RTP H264/SPEEX RTP/SDP payload type issue

Hello Guys

– Systems Tested –

Wowza Media Server 2.2.3 build26454

Wowza Media Server 3.0.0 build822

– Issue –

I am publishing streams to Wowza using RTSP/RTP with media types H264 and SPEEX. I am using a payload type of 97 and 96 respectively. I have tried the reverse of this rtp map as well. Here is the SDP I ANNOUNCE.

v=0

o=- 0 0 IN IP4 127.0.0.1

s=…

c=IN IP4 …

t=0 0

a=range:npt=now

a=tool:Livu RTP

m=audio 8088 RTP/AVP 96

a=rtpmap:96 speex/16000

a=ptime:20

a=fmtp:96 mode=“5”

a=control:trackid=1

m=video 9670 RTP/AVP 97

b=AS:300

a=rtpmap:97 H264/90000

a=fmtp:97 packetization-mode=1;sprop-parameter-sets=Z0IAHqtAsEsg,KM48gA==

a=control:trackid=2

The issue is Wowza is remapping both media streams to 97. Not only are the SDP rtpmap entries both 97, but the RTP PT field is also 97 for all packets emitted by Wowza. Here is the return SDP

v=0

o=- 2055666965 2055666965 IN IP4 50.17.156.90

s=WowzaMediaServer

c=IN IP4 50.17.156.90

t=0 0

a=sdplang:en

a=range:npt=now-

a=control:*

m=audio 0 RTP/AVP 97

a=rtpmap:97 SPEEX/16000/2

a=control:trackID=1

m=video 0 RTP/AVP 97

a=rtpmap:97 H264/90000

a=fmtp:97 packetization-mode=1;profile-level-id=42001E;sprop-parameter-sets=Z0IAHqtAsEsg,KM48gA==

a=cliprect:0,0,288,352

a=framesize:97 352-288

a=control:trackID=2

I have confirmed my RTP packets are using the correct payload type as specified in the SDP. I can try any suggestions you might have.

Flash does play out the stream correctly, so your FLV container generation is working right. I could install multicast publisher as a test if you think it might be worth testing.

I have exhausted all tests that I have put together, and in every case this issue still occurs. In one test I use a payload type of 96 for H264. Wowza remaps this to 97. I do recall a post by Charlie stating that AAC and H264 always have payload types of 96 and 97 respectively. My assumption is that a payload type of 97 is also hard coded for SPEEX. If I just publish speex using

v=0

o=- 0 0 IN IP4 127.0.0.1

s=Livu

c=IN IP4 127.0.0.1

t=0 0

a=tool:Livu RTP

m=audio 8088 RTP/AVP 96

a=rtpmap:96 speex/16000

a=ptime:20

a=fmtp:96 mode=“5”

a=control:trackid=1

The returned SDP from Wowza is

v=0

o=- 221537103 221537103 IN IP4 127.0.0.1

s=stream

c=IN IP4 0.0.0.0

t=0 0

a=sdplang:en

a=range:npt=now-

a=control:*

m=audio 0 RTP/AVP 97

a=rtpmap:97 SPEEX/16000/2

a=control:trackID=1

Could someone check the RTSP/RTP/SDP code to either confirm or deny what I am seeing is an issue. I really do think 97 is hardcoded somewhere. This issue is preventing us from moving forward with streaming H264/SPEEX from Wowza using RTP. A vital AV setup for us.

We don’t really support Speex over RTP. We built an RTP depacketizer for Speex but it is not complete or tested. We do support Speex over RTMP.

Charlie

Speex works fine if you send only the audio stream. I can publish and play out the stream. The only issue is the payload type. I would assume the code that is sending could be easily patched to prevent the Speex payload type from being 97.