Using gstreamer-0.10 with Wowza

First, be sure to upgrade to the latest patch (patch33) from here:

https://www.wowza.com/devbuild.html

Next, send me the entire debug log so I can have a look at it (charlie@wowza.com).

Charlie

Please send me the entire debug log file. Send it to charlie@wowza.com.

Charlie

I don’t know gstreamer very well. Is this doing a transcode to H.264? What happens when you try to play this stream using VLC player. What is the type of the audio/video in the “Stream Media Info” dialog box in VLC?

Charlie

I think you have been contacting me directly over email. I suspect that the problem might be with gstreamer. The fact that you do not have a reliable stream working with VLC is suspect. I would work with the gstreamer team to try and get reliable playback with VLC first. Once you have this working then move on to Wowza Pro and Flash. I suspect that the audio packets are not properly formatted in the RTP packets. You might also see if there is an option to turn off the CRC byte. We have had problems in the past if the CRC byte is turned on.

Charlie

Then try changing the SDP data to this:

v=0
o=- 14770170187368070364 14770170187368070364 IN IP4 c3dpcws004
s=Unnamed
i=N/A
c=IN IP4 10.218.35.135
t=0 0
a=tool:vlc 0.9.6
a=recvonly
a=type:broadcast
a=charset:UTF-8
m=video 1234 RTP/AVP 96
b=RR:0
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1
a=fmtp:96 profile-level-id=3;

We cannot handle the config data as it is presented in the SDP file. We should be able to extract this data from the stream if it is not present in the SDP file.

Charlie

GStreamer tends to use AUD NAL units. For some reason with this setup it is actually sending SPS NAL units which include video data. I have never seen this before. I will need to better understand this.

Charlie

I made a change that enabled it to work when using the test pattern. So in the most recent version the following gstreamer command line works:

gst-launch-0.10 -vvv videotestsrc ! queue ! x264enc byte-stream=true bitrate=300 ! rtph264pay ! udpsink port=5000 host=127.0.0.1 sync=false 

This continues to work for me. I have tried gstreamer in other situations where it does not work due to the problems I described above.

Charlie

Also, try setting the RTP/AVSyncMethod to systemclock in [install-dir]/conf/[application]/Application.xml.

Charlie

Hi,

Fortunately, gstreamer’s verbose arguments lets you get information like sprops.

Unfortunately, this didn’t change a thing :-\

v=0

o=- 1188340656180883 1 IN IP4 127.0.0.1

s=Session streamed by GStreamer

i=server.sh

t=0 0

a=tool:GStreamer

a=type:broadcast

m=video 5000 RTP/AVP 96

c=IN IP4 127.0.0.1

a=rtpmap:96 H264/90000

sprop-parameter-sets=“Z01AM5JUCg/YCIAAAAMAgAAAHkeMGVA\=\,aO48gA\=\=”

Is the syntax wrong ?

Other info possibly useful:

gst-launch-0.10 -vvv videotestsrc ! queue ! x264enc byte-stream=true bitrate=300 ! rtph264pay ! udpsink port=5000 host=127.0.0.1 sync=false

/pipeline0/udpsink0.sink: caps = application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, profile-level-id=(string)4d4033, sprop-parameter-sets=(string)“Z01AM5JUCg/YCIAAAAMAgAAAHkeMGVA\=\,aO48gA\=\=”, payload=(int)96, ssrc=(guint)581716154, clock-base=(guint)1491552284, seqnum-base=(guint)30522

I doubt it’s the codec that’s faulty, since it’s x264 like VLC. Would the rtp payloading be the problem ?

Do you have example h264 raw rtp sdp files for inspiration ?

Thanks

Florent

Here’s the detailed debug output with the previous sdp file (EOS). Nothing shows up.

DEBUG server comment -   SINGLE: end:true tc:com.wowza.util.RolloverLong@1a7f9dc sz:1284
DEBUG server comment - rtp[video:1209] {80 e0 b0 e2 ea 11 5f 12 80 b6 6f c4 09 30 00 00 }
DEBUG server comment -   SINGLE: end:true tc:com.wowza.util.RolloverLong@1a7f9dc sz:1197
DEBUG server comment - rtp[video:1316] {80 e0 b0 e3 ea 11 6a ca 80 b6 6f c4 09 30 00 00 }
INFO server comment - RTPMediaCaster.shutdown: mystream.sdp
DEBUG server comment -   SINGLE: end:true tc:com.wowza.util.RolloverLong@1a7f9dc sz:1304
INFO server comment - RTPMediaCaster.disconnect
INFO stream unpublish mystream.sdp -

Do you see something new ?

I’m working on a more detailed sdp file, i’ll let you know.

Here’s a new sdp file inspired from Wirecasts’:

v=0
o=- 1188340656180883 1 IN IP4 127.0.0.1
s=Session streamed by GStreamer
t=0 0
a=tool:GStreamer
a=type:broadcast
m=video 5000 RTP/AVP 96
c=IN IP4 127.0.0.1
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;profile-level-id=4d4033;sprop-parameter-sets=Z01AM5JUCg/YCIAAAAMAgAAAHkeMGVA=,aO48gA==
a=cliprect:0,0,240,320
a=framesize:96 320-240

Ouptut is still:

DEBUG server comment - rtp[video:1195] {80 e0 83 04 d6 dc 65 12 f5 1a 23 64 09 30 00 00 }
DEBUG server comment -   SINGLE: end:true tc:com.wowza.util.RolloverLong@1aa0a15 sz:1183
DEBUG server comment - rtp[video:1201] {80 e0 83 05 d6 dc 70 cb f5 1a 23 64 09 30 00 00 }
DEBUG server comment -   SINGLE: end:true tc:com.wowza.util.RolloverLong@1aa0a15 sz:1

Any comments ? I also tried setting the packetization mode to 0, witout any changes :-\

To charlie:

avidemux only demultiplexes an existing avi stream (from file in the example), so if the payload is h264 no need to reencode…

I continue trying to use gstreamer with wowza, and i get exactly the same behaviour as fonarik:

When using the following gst, my udp sink reports:

/pipeline0/udpsink0.sink: caps = application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, profile-level-id=(string)42e01e, sprop-parameter-sets=(string)“Z0LgHtoC0EmwEAg\=\,aM4zyA\=\=”, payload=(int)96, ssrc=(guint)4241018952, clock-base=(guint)3431787311, seqnum-base=(guint)21521

When i use this info to fill in the .sdp file,

INFO session connect-pending 192.168.40.121 -

INFO session connect 192.168.40.121 -

INFO stream create - -

INFO server comment - MediaStreamMediaCasterPlay: startPlay

INFO server comment - RTPMediaCaster.create

INFO server comment - RTPMediaCaster.init

INFO server comment - RTPMediaCaster.Reconnector: start

INFO server comment - RTPSessionDescriptionDataProviderBasic.getStreamInfo: /usr/local/WowzaMediaServerPro/content/gsttest.sdp

INFO stream create - -

INFO stream publish gsttest.sdp -

INFO server comment - UDPTransport.bind: /127.0.0.1:10000

INFO server comment - UDPTransport.bind: /127.0.0.1:10001

INFO server comment - UDPTransport.bind: /127.0.0.1:10002

INFO server comment - UDPTransport.bind: /127.0.0.1:10003

INFO server comment - RTPMediaCaster.Reconnector: stop

INFO server comment - UDPTransport.firstPacket: /127.0.0.1:10000

After, nothing more happens…

I saw the changelog entry stating “added support for gstreamer” recently. I use 1.6 wowza deb. Should the issue be fixed already ?

Hi charlie :slight_smile:

Regarding the development environment:

http://www.pitivi.org/wiki/GStreamer_CVS_Setup_Page

What do you mean by “latest version” : 0.10.21 ?

I confirm the test pattern works !!! This is awesome !

So finally you did add support for the different RTP handling ?

I’m just trying to understand why this works with the test pattern but not other cases: with the test pattern + x264enc, the mark is correct ?

Okay;

  1. do you want me to report the issue to the development list ? (https://lists.sourceforge.net/lists/listinfo/gstreamer-devel)

  2. i tested with the dev env (0.10.21), and THIS WORKS PERFECTLY !!! For reference, we use the FastVDO SmartCapture device with a dedicated gstreamer plugin

This is great :slight_smile:

Thanks again !

FLorent

Hi Charlie,

I am now looking for a way to send MP3 or AAC data with gstreamer as well:

AAC:

gst-launch audiotestsrc ! faac ! rtpmp4apay ! udpsink host=$server port=$audio_port

Here is the sdp audio part i’ve been using

m=audio 10002 RTP/AVP 96

a=rtpmap:96 mpeg4-generic/48000/2

a=control:trackID=2

a=fmtp:96 streamtype=5; profile-level-id=255; mode=AAC-hbr; config=1190; objectType=64; sizeLength=13; indexLength=3; indexDeltaLength=3

The server raises exceptions:

ERROR server comment - addDataA[this.size:513 this.dataA.length:513 this.startDataLoc:512 this.dataLoc:512 data.length:303 offset:0 size:303 missing:1 ]: java.lang.ArrayIndexOutOfBoundsException

java.lang.ArrayIndexOutOfBoundsException

at com.wowza.wms.amf.AMFPacket.addData(Unknown Source)

at com.wowza.wms.stream.live.LiveReceiver.addAudioData(Unknown Source)

at com.wowza.wms.stream.live.MediaStreamLive.addAudioData(Unknown Source)

at com.wowza.wms.rtp.depacketizer.RTPPacket.write(Unknown Source)

at com.wowza.wms.rtp.depacketizer.RTPPacket.write(Unknown Source)

at com.wowza.wms.rtp.depacketizer.RTPDePacketizerMPEG4AAC.handleRTPPacket(Unknown Source)

Given gstreamer’s detailed output (below) how should the SDP file be ?

caps = application/x-rtp, media=(string)audio, clock-rate=(int)48000, encoding-name=(string)MP4A-LATM, cpresent=(string)0, config=(string)40001320, payload=(int)96, ssrc=(guint)3653097729, clock-base=(guint)2206318833, seqnum-base=(guint)48474

MP3:

gst-launch audiotestsrc ! lame ! rtpmpapay ! udpsink host=$server port=$audio_port

I do not know how to tell the server in the sdp file (if supported) that audio is MP3. Do you have sample SDP files for MP3 rtp streams ?

THanks

Here’s what i’m trying:

m=audio 10002 RTP/AVP 96

a=rtpmap:96 mpa-robust/90000

And the corresponding gst caps:

/GstPipeline:pipeline0/GstRtpMPAPay:rtpmpapay0.GstPad:src: caps = application/x-rtp, media=(string)audio, clock-rate=(int)90000, encoding-name=(string)MPA, payload=(int)96, ssrc=(guint)1315959326, clock-base=(guint)2051349402, seqnum-base=(guint)41023

/GstPipeline:pipeline0/GstRtpMPAPay:rtpmpapay0.GstPad:sink: caps = audio/mpeg, mpegversion=(int)1, mpegaudioversion=(int)1, layer=(int)3, channels=(int)2, rate=(int)48000