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 
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;
-
do you want me to report the issue to the development list ? (https://lists.sourceforge.net/lists/listinfo/gstreamer-devel)
-
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
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
From http://www.rfc-editor.org/rfc/rfc3016.txt:
5.4 SDP usage of MPEG-4 Audio
The MIME media type audio/MP4A-LATM string is mapped to fields in the
Session Description Protocol (SDP), RFC 2327, as follows:
o The MIME type (audio) goes in SDP “m=” as the media name.
o The MIME subtype (MP4A-LATM) goes in SDP “a=rtpmap” as the
encoding name.
o The required parameter “rate” goes in “a=rtpmap” as the clock
rate.
o The optional parameter “ptime” goes in SDP “a=ptime” attribute.
o The optional parameter “profile-level-id” goes in the “a=fmtp”
line to indicate the coder capability. The “object” parameter
goes in the “a=fmtp” attribute. The payload-format-specific
parameters
Here’s what i am trying for AAC:
m=audio 10002 RTP/AVP 96
a=rtpmap:96 MP4A-LATM/48000/2
Where gst caps are:
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)3006373333, clock-base=(guint)1009694188, seqnum-base=(guint)27071
Problem is, if i do this the video doesn’t play back anymore ! (Black screen). No errors though…
Here is my latest sdp audio section test:
m=audio 10002 RTP/AVP 96
a=rtpmap:96 MP4-LATM/48000/2
a=fmtp:96 profile-level-id=1; bitrate=128000; cpresent=0;config=40001320
Here are the default faac parameters:
outputformat : Format of output frames
flags: accès en lecture, accès en écriture
Enum “GstFaacOutputFormat” Default: 1, “ADTS headers” Current: 0, “Raw AAC”
(0): Raw AAC - OUTPUTFORMAT_RAW
(1): ADTS headers - OUTPUTFORMAT_ADTS
bitrate : Bitrate in bits/sec
flags: accès en lecture, accès en écriture
Integer. Range: 8000 - 320000 Default: 128000 Current: 128000
profile : MPEG/AAC encoding profile
flags: accès en lecture, accès en écriture
Enum “GstFaacProfile” Default: 1, “Main profile” Current: 1, “Main profile”
(1): Main profile - MAIN
(2): Low complexity profile - LC
(3): Scalable sampling rate profile - SSR
(4): Long term prediction profile - LTP
tns : Use temporal noise shaping
flags: accès en lecture, accès en écriture
Boolean. Default: false Current: false
midside : Allow mid/side encoding
flags: accès en lecture, accès en écriture
Boolean. Default: true Current: true
shortctl : Block type encorcing
flags: accès en lecture, accès en écriture
Enum “GstFaacShortCtl” Default: 1, “No short blocks” Current: 0, “Normal block type”
(0): Normal block type - SHORTCTL_NORMAL
(1): No short blocks - SHORTCTL_NOSHORT
(2): No long blocks - SHORTCTL_NOLONG
It seems to me everything should be alright here (according to RFC). Does anyone see any obvious mistake ?
