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 ?
Hi
Just found the solution: you have to use the rtpmp4gpay plugin which reports the appropriate parameters to fill in the sdp file; and it works !!!
However, if the flash player is left open for some time, audio and video are desynced.
Why is that ?
Is there a way to avoid it (e.g. using RTSP/RTCP/mpegts) ?
Well, it’s hard to say: it’s perceivable after 20 minutes or so.
-
why do i need to restart the server after stopping and restarting the (publisher) streaming process ? Is there a workaround ? If i do not, the flash player only shows a black screen
-
audio plays back faster
-
my audio tests samples (voice/claps) seem to have a direct effect on drifting speed ! If i speak longer, the desync comes faster ! :mad:
Streamer: gstreamer-0.10.21 (cvs)
Wowza: 1.5.3 build7825
Client: Flash Player 10 (Vista)
Looks quite ok to me. Are you sure you are waiting long enough ? What do the wowza debug messages tell ?
You might want to explain what your gst-launch command line is !
Hi-
I’m looking at streaming gstreamer to wowza as well. So far I can stream in, but no clients can play a stream. The connection process seems to negotiate and wowza seems to be sending data, but with a size length of zero.
DEBUG server comment - send: size:0 filter:7 time:278 tOffset:0
DEBUG server comment - send: size:0 filter:7 time:288 tOffset:0
DEBUG server comment - send: size:0 filter:7 time:278 tOffset:0
DEBUG server comment - send: size:0 filter:7 time:295 tOffset:0
DEBUG server comment - send: size:0 filter:7 time:284 tOffset:0
DEBUG server comment - send: size:0 filter:7 time:284 tOffset:0
DEBUG server comment - send: size:0 filter:7 time:300 tOffset:0
DEBUG server comment - send: size:0 filter:7 time:292 tOffset:0
DEBUG server comment - send: size:0 filter:7 time:305 tOffset:0
Were you able to close the loop and get a client to receive data?
I’d like to stay with Wowza. But the close nature of it may force a look at red5 to close the loop if we can’t get it to reflect the stream.
Thanks,
Thanks,
Thanks.
I’m on ubuntu hardy 8.0.4 right now. To install, use
apt-get install
gstreamer0.10-plugins-good gstreamer0.10-plugins-base gstreamer0.10-plugins-bad-multiverse gstreamer-tools gstreamer0.10-ffmpeg gstreamer-tools
that should get all the necessary parts. the gst plugin for x264 resides in the bad-multiverse install.
I’ll check which version of the player is being used (whatever debug version came with the flash install). I just installed the most recent patch for the wowza server. And I’ll send a debug log soon.
The setup has isolated the variation to the RTP stream alone. RTSP announce is handled through a separate process. And wirecast or quicktime broadcaster in unicast mode work. When the rtp stream is changed to gstreamer, it seems to zero out the packets for all but the first.
More soon.
I am using my own rtp streaming application. The SDP seems to be parsed correctly however all the received RTP packets (with H.264 encoded video) seem to get dropped.
DEBUG server comment 2008-11-03 10:08:54 - - - - - 132.859 - - - - - - - RTSPPort.sessionOpened: (DATAGRAM, R: /172.16.1.43:2048, L: /0.0.0.0:60000, S: 0.0.0.0/0.0.0.0:60000)
DEBUG server comment 2008-11-03 10:08:54 - - - - - 132.875 - - - - - - - rtp[video:363] {80 60 32 dd 4c ce 37 ed e5 cb eb ba 06 42 00 33 }
DEBUG server comment 2008-11-03 10:08:54 - - - - - 132.875 - - - - - - - myStream.sdp: 10:08:54: waitforend: dropped:1
Including the partial log file.
Any help is appreciated.
Thanks in advance.
Files/Wowza Media Systems/Wowza Media Server Pro 1.5.3/content/myStream.sdp
DEBUG server comment 2008-11-03 10:08:37 - - - - - 115.719 - - - - - - - sdp: v=0
DEBUG server comment 2008-11-03 10:08:37 - - - - - 115.719 - - - - - - - sdp: s=RTP_H264_0
DEBUG server comment 2008-11-03 10:08:37 - - - - - 115.719 - - - - - - - sdp: b=AS:1000000
DEBUG server comment 2008-11-03 10:08:37 - - - - - 115.719 - - - - - - - sdp: t=0 0
DEBUG server comment 2008-11-03 10:08:37 - - - - - 115.719 - - - - - - - cmd: setBufferTime
DEBUG server comment 2008-11-03 10:08:37 - - - - - 115.719 - - - - - - - sdp: m=video 60000 RTP/AVP 96
DEBUG stream setbuffertime 2008-11-03 10:08:37 1823527831 127.0.0.1 - 3685 3402 0.032 myStream.sdp 14195 0 0 - - myStream.sdp 750
DEBUG server comment 2008-11-03 10:08:37 - - - - - 115.734 - - - - - - - sdp: a=rtpmap:96 H264/90000
DEBUG server comment 2008-11-03 10:08:37 - - - - - 115.734 - - - - - - - sdp: a=fmtp:96 packetization-mode=0;profile-level-id=420033;sprop-parameter-sets=Z0AAM5QUAoAt0IAAAfQAADgYQg==,aMQLyA==
DEBUG server comment 2008-11-03 10:08:37 - - - - - 115.734 - - - - - - - sdp:
DEBUG server comment 2008-11-03 10:08:37 - - - - - 115.734 - - - - - - - onFlushNotifyClients: false
DEBUG server comment 2008-11-03 10:08:37 - - - - - 115.734 - - - - - - - flushInterval: 0
DEBUG server comment 2008-11-03 10:08:37 - - - - - 115.734 - - - - - - - verboseDebug: false
INFO stream create 2008-11-03 10:08:37 - - - - - 0.0 - 1208 0 0 - - - -
DEBUG server comment 2008-11-03 10:08:37 - - - - - 115.75 - - - - - - - RTPDePacketizerRFC3984H264.init
INFO stream publish 2008-11-03 10:08:37 - - - - - 0.016 myStream.sdp 1208 0 0 - - myStream.sdp -
INFO server comment 2008-11-03 10:08:37 - - - - - 115.75 - - - - - - - UDPTransport.bind: 0.0.0.0/0.0.0.0:60000
DEBUG server comment 2008-11-03 10:08:37 - - - - - 115.75 - - - - - - - config: session: setReuseAddress: from:false to:true
DEBUG server comment 2008-11-03 10:08:37 - - - - - 115.75 - - - - - - - config: session: setReceiveBufferSize: from:8192 to:65000
DEBUG server comment 2008-11-03 10:08:37 - - - - - 115.75 - - - - - - - config: session: setSendBufferSize: from:8192 to:8192
DEBUG server comment 2008-11-03 10:08:37 - - - - - 115.766 - - - - - - - config: session: setTrafficClass: from:0 to:0
INFO server comment 2008-11-03 10:08:37 - - - - - 115.781 - - - - - - - UDPTransport.bind: 0.0.0.0/0.0.0.0:60001
DEBUG server comment 2008-11-03 10:08:37 - - - - - 115.781 - - - - - - - config: session: setReuseAddress: from:false to:true
DEBUG server comment 2008-11-03 10:08:37 - - - - - 115.781 - - - - - - - config: session: setReceiveBufferSize: from:8192 to:65000
DEBUG server comment 2008-11-03 10:08:37 - - - - - 115.781 - - - - - - - config: session: setSendBufferSize: from:8192 to:8192
DEBUG server comment 2008-11-03 10:08:37 - - - - - 115.781 - - - - - - - config: session: setTrafficClass: from:0 to:0
INFO server comment 2008-11-03 10:08:37 - - - - - 115.797 - - - - - - - RTPMediaCaster.Reconnector: stop
DEBUG server comment 2008-11-03 10:08:37 - - - - - 115.953 - - - - - - - send: size:0 filter:7 time:0 tOffset:0
DEBUG server comment 2008-11-03 10:08:37 - - - - - 116.203 - - - - - - - send: size:0 filter:7 time:250 tOffset:0
DEBUG server comment 2008-11-03 10:08:38 - - - - - 116.469 - - - - - - - send: size:0 filter:7 time:266 tOffset:0
DEBUG server comment 2008-11-03 10:08:38 - - - - - 116.719 - - - - - - - send: size:0 filter:7 time:250 tOffset:0
DEBUG server comment 2008-11-03 10:08:38 - - - - - 116.969 - - - - - - - send: size:0 filter:7 time:250 tOffset:0
DEBUG server comment 2008-11-03 10:08:38 - - - - - 117.219 - - - - - - - send: size:0 filter:7 time:250 tOffset:0
DEBUG server comment 2008-11-03 10:08:39 - - - - - 117.484 - - - - - - - send: size:0 filter:7 time:265 tOffset:0
DEBUG server comment 2008-11-03 10:08:39 - - - - - 117.734 - - - - - - - send: size:0 filter:7 time:250 tOffset:0
DEBUG server comment 2008-11-03 10:08:39 - - - - - 117.984 - - - - - - - send: size:0 filter:7 time:250 tOffset:0
DEBUG server comment 2008-11-03 10:08:39 - - - - - 118.234 - - - - - - - send: size:0 filter:7 time:250 tOffset:0
DEBUG server comment 2008-11-03 10:08:40 - - - - - 118.5 - - - - - - - send: size:0 filter:7 time:266 tOffset:0
DEBUG server comment 2008-11-03 10:08:40 - - - - - 118.75 - - - - - - - send: size:0 filter:7 time:250 tOffset:0
DEBUG server comment 2008-11-03 10:08:54 - - - - - 132.859 - - - - - - - RTSPPort.sessionOpened: (DATAGRAM, R: /172.16.1.43:2048, L: /0.0.0.0:60000, S: 0.0.0.0/0.0.0.0:60000)
DEBUG server comment 2008-11-03 10:08:54 - - - - - 132.875 - - - - - - - rtp[video:363] {80 60 32 dd 4c ce 37 ed e5 cb eb ba 06 42 00 33 }
DEBUG server comment 2008-11-03 10:08:54 - - - - - 132.875 - - - - - - - myStream.sdp: 10:08:54: waitforend: dropped:1
INFO server comment 2008-11-03 10:08:54 - - - - - 132.875 - - - - - - - UDPTransport.firstPacket: 0.0.0.0/0.0.0.0:60000
DEBUG server comment 2008-11-03 10:08:54 - - - - - 132.875 - - - - - - - rtp[video:31] {80 60 32 de 4c ce 37 ed e5 cb eb ba 67 42 00 33 }
DEBUG server comment 2008-11-03 10:08:54 - - - - - 132.875 - - - - - - - myStream.sdp: 10:08:54: waitforend: dropped:2
DEBUG server comment 2008-11-03 10:08:54 - - - - - 132.875 - - - - - - - rtp[video:16] {80 60 32 df 4c ce 37 ed e5 cb eb ba 68 ce 0b c8 }
DEBUG server comment 2008-11-03 10:08:54 - - - - - 132.875 - - - - - - - myStream.sdp: 10:08:54: waitforend: dropped:3
DEBUG server comment 2008-11-03 10:08:54 - - - - - 132.875 - - - - - - - rtp[video:3253] {80 60 32 e0 4c ce 37 ed e5 cb eb ba 65 88 80 80 }
DEBUG server comment 2008-11-03 10:08:54 - - - - - 132.875 - - - - - - - myStream.sdp: 10:08:54: waitforend: dropped:4
DEBUG server comment 2008-11-03 10:08:54 - - - - - 132.875 - - - - - - - rtp[video:3727] {80 60 32 e1 4c ce 37 ed e5 cb eb ba 65 03 88 88 }
DEBUG server comment 2008-11-03 10:08:54 - - - - - 132.875 - - - - - - - myStream.sdp: 10:08:54: waitforend: dropped:5
DEBUG server comment 2008-11-03 10:08:54 - - - - - 132.875 - - - - - - - rtp[video:3694] {80 60 32 e2 4c ce 37 ed e5 cb eb ba 65 01 c4 22 }
DEBUG server comment 2008-11-03 10:08:54 - - - - - 132.875 - - - - - - - myStream.sdp: 10:08:54: waitforend: dropped:6
Thanks for the prompt reply.
Yeah, I seem to be doing that. Setting the marker bit for the last RTP packet before the next packet with a different timestamp is set.
From a wireshark Capture.
3206 3.778338 172.16.1.43 172.16.1.35 RTP PT=Unknown (96), SSRC=0x1E48E2BB, Seq=1473, Time=1836230591, Mark
3207 3.813092 172.16.1.43 172.16.1.35 RTP PT=Unknown (96), SSRC=0x1E48E2BB, Seq=1474, Time=1836233591
Thanks.
Hello, I’m trying to send a stream from a webcam, codificated in H264, and packeted into a RTP contaner to a Wowza Media Server Pro (build 9437).
Using debug logging, it shows the same that the other users’ log in this thread:
“DEBUG server comment - send: size:0 filter:7 time:305 tOffset:0 …”
Is this problem solved?
What should I do?
Thanks
Charlie, is there any solution for this problem?
Thanks
fonarik, you must the h264 enconding before rtp payloading:
gst-launch-0.10.exe -v filesrc location=avc.avi ! avidemux ! x264enc byte-stream=true ! rtph264pay mtu=1438 ! udpsink host=192.168.3.13 port=6000
try it
I’m trying to send live audio form a dvb card with gstreamer to a Wowza server and then play audio flash from jwplayer.
The problem is that I can’t hear the audio in jwplayer.
I’d tested it with a mp3 file and the following command:
gst-launch-0.10 -v filesrc location=/share/sample.mp3 ! flump3dec ! queue max-size-buffers=0 max-size-time=0 ! ffenc_libfaac ! queue max-size-buffers=0 max-size-time=0 ! queue max-size-buffers=0 max-size-time=0 ! rtpmp4apay ! udpsink host=192.168.1.168 port=6060
Wowza caught it and I have this SDP:
v=0
o=- 116704633 116704633 IN IP4 127.0.0.1
s=GStreamer
t=0 0
a=range:npt=now-
a=control:trackID=1
c=IN IP4 192.168.1.168
m=audio 6060 RTP/AVP 96
a=rtpmap:96 MP4A-LATM/48000/2
But, if I try to play that SDP in jwplayer, It looks loke loading, but doesn’t play anything…
Wowza doesn’t echo any errors, when I connect from jwplayer to play, it only says (I turn the debug off):
INFO session connect-pending 192.168.1.128 -
INFO session connect 192.168.1.128 -
INFO stream create - -
INFO server comment - MediaStreamMediaCasterPlay: startPlay
INFO stream play rtplive.sdp -
Has Anybody any idea?
Has Anybody tried anything like that?
Is it a problem only with audio encoding or SDP file config or is there a bug in any part?
Thanks
I’ve found a gstreamer’s pipeline and a SDP that work with Wowza, sending live video and audio to Wowza.
However, I’m only able to send audio or video separately, but not together.
Here is my last SDP file (caps are copied form gstreamer output).
If i remove video or audio from SDP, the other (video or audio, depending) is played alright:
v=0
o=- 14818005123115786627 14818005123115786627 IN IP4 localhost.localdomain
s=Gstreamer
i=N/A
c=IN IP4 237.1.1.3
t=0 0
m=video 6070 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 media=video; clock-rate=90000; encoding-name=H264; profile-level-id=4d4015; sprop-parameter-sets=Z01AFZJUDwX3/gAwACIgAAADACAAAAZR4sXU; payload=96; ssrc=3120057827; clock-base=1065471660; seqnum-base=39429;
a=control:trackID=1
m=audio 6060 RTP/AVP 96
a=rtpmap:96 MPEG4-GENERIC/48000/2
a=fmtp:96 media=audio; clock-rate=44100; encoding-name=MPEG4-GENERIC; encoding-params=1; streamtype=5; profile-level-id=1; mode=AAC-hbr; config=0a08; objectType=64; sizeLength=13; indexLength=3; indexDeltaLength=3; payload=96; ssrc=4278936313; clock-base=160119643; seqnum-base=26806
a=control:trackID=2
