Page 1 of 7 123 ... LastLast
Results 1 to 10 of 69

Thread: Using gstreamer-0.10 with Wowza

  1. 07-02-2008, 10:41 AM #1
    Florent.T
    Florent.T is offline Member
    Join Date
    Mar 2008
    Posts
    45

    Default Using gstreamer-0.10 with Wowza

    Hi

    I've begun experimenting using Wowza together with the gstreamer media framework.

    Here's the cmd line i'm using:
    gst-launch-0.10 -vvv videotestsrc ! queue ! x264enc byte-stream=true bitrate=300 ! rtph264pay ! udpsink port=5000 host=127.0.0.1 sync=false
    It results in creating a 320x240 video test pattern encoded using x264.

    Since there's no RTCP enabled with such command line, i put the systemclock sync parameter in the Application.xml config file.

    Server-side (on the local host), here's the myStream.sdp file:
    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
    Here's the debug log (relevant parts):
    DEBUG server comment - cmd: play
    INFO server comment - MediaStreamMediaCasterPlay: startPlay
    INFO server comment - RTPMediaCaster.create
    INFO server comment - RTPMediaCaster.init
    DEBUG server comment - cmd: setBufferTime
    INFO server comment - RTPMediaCaster.Reconnector: start
    INFO server comment - RTPSessionDescriptionDataProviderBasic.getStreamIn fo: /usr/local/WowzaMediaServerPro/content/myStream.sdp
    DEBUG server comment - sdp: v=0
    DEBUG server comment - sdp: o=- 1188340656180883 1 IN IP4 127.0.0.1
    DEBUG server comment - sdp: s=Session streamed by GStreamer
    DEBUG server comment - sdp: i=server.sh
    DEBUG server comment - sdp: t=0 0
    DEBUG server comment - sdp: a=tool:GStreamer
    DEBUG server comment - sdp: a=type:broadcast
    DEBUG server comment - sdp: m=video 5000 RTP/AVP 96
    DEBUG stream setbuffertime myStream.sdp -
    DEBUG server comment - sdp: c=IN IP4 127.0.0.1
    DEBUG server comment - sdp: a=rtpmap:96 H264/90000
    DEBUG server comment - onFlushNotifyClients: false
    DEBUG server comment - flushInterval: 0
    DEBUG server comment - verboseDebug: false
    INFO stream create - -
    DEBUG server comment - RTPDePacketizerRFC3984H264.init
    INFO stream publish myStream.sdp -
    INFO server comment - UDPTransport.bind: /127.0.0.1:5000
    DEBUG server comment - config: session: setReuseAddress: from:false to:true
    DEBUG server comment - config: session: setReceiveBufferSize: from:55296 to:65000
    DEBUG server comment - config: session: setSendBufferSize: from:55296 to:55296
    DEBUG server comment - config: session: setTrafficClass: from:0 to:0
    INFO server comment - UDPTransport.bind: /127.0.0.1:5001
    DEBUG server comment - config: session: setReuseAddress: from:false to:true
    DEBUG server comment - config: session: setReceiveBufferSize: from:55296 to:65000
    DEBUG server comment - config: session: setSendBufferSize: from:55296 to:55296
    DEBUG server comment - config: session: setTrafficClass: from:0 to:0
    INFO server comment - RTPMediaCaster.Reconnector: stop
    DEBUG server comment - rtp[video:1024] {80 60 11 af 25 e9 6f d6 e3 2f 49 73 1c 89 30 00 }
    DEBUG server comment - myStream.sdp: 17:36:15: waitforend: dropped:1
    INFO server comment - UDPTransport.firstPacket: /127.0.0.1:5000
    DEBUG server comment - rtp[video:286] {80 60 11 b0 25 e9 6f d6 e3 2f 49 73 1c 49 c7 bf }
    DEBUG server comment - myStream.sdp: 17:36:15: waitforend: dropped:2
    DEBUG server comment - rtp[video:1024] {80 60 11 b1 25 e9 7b 8f e3 2f 49 73 1c 89 10 00 }
    DEBUG server comment - myStream.sdp: 17:36:15: waitforend: dropped:3
    DEBUG server comment - rtp[video:990] {80 60 11 b2 25 e9 7b 8f e3 2f 49 73 1c 49 de 0a }
    DEBUG server comment - myStream.sdp: 17:36:15: waitforend: dropped:4
    DEBUG server comment - rtp[video:1024] {80 60 11 b3 25 e9 87 46 e3 2f 49 73 1c 89 30 00 }
    DEBUG server comment - myStream.sdp: 17:36:15: waitforend: dropped:5
    DEBUG server comment - rtp[video:148] {80 60 11 b4 25 e9 87 46 e3 2f 49 73 1c 49 49 9f }
    DEBUG server comment - myStream.sdp: 17:36:15: waitforend: dropped:6
    DEBUG server comment - rtp[video:1024] {80 60 11 b5 25 e9 92 fe e3 2f 49 73 1c 89 30 00 }
    DEBUG server comment - myStream.sdp: 17:36:15: waitforend: dropped:7
    DEBUG server comment - rtp[video:177] {80 60 11 b6 25 e9 92 fe e3 2f 49 73 1c 49 7a 2f }
    Of course this won't be an easy task, yet i'm wondering what this log mean ? Why are all frames dropped ?

    Cheers

    Florent
    Reply With Quote Reply With Quote
  2. 07-02-2008, 10:53 AM #2
    Florent.T
    Florent.T is offline Member
    Join Date
    Mar 2008
    Posts
    45

    Default

    I changed the resolution to 640x480:
    gst-launch-0.10 -vvv videotestsrc ! capsfilter caps="video/x-raw-yuv, format=(fourcc)I420, width=(int)640, height=(int)480, framerate=(fraction)30/1" ! queue ! x264enc byte-stream=true bitrate=300 ! rtph264pay ! udpsink port=5000 host=127.0.0.1 sync=false
    Now i'm getting these messages (again, using systemclock sync):
    DEBUG server comment - FU-A: end:false tc:3371173062 st:true
    DEBUG server comment - rtp[video:212] {80 e0 05 8f c8 f0 04 c6 3f e9 f1 e0 5c 41 ee c5 }
    DEBUG server comment - FU-A: end:true tc:3371173062 st:false
    DEBUG server comment - rtp[video:14] {80 60 05 90 c8 f0 10 7f 3f e9 f1 e0 09 30 }
    DEBUG server comment - SINGLE: end:false tc:3371176063 sz:2
    DEBUG server comment - rtp[video:1400] {80 60 05 91 c8 f0 10 7f 3f e9 f1 e0 5c 81 9a d9 }
    DEBUG server comment - FU-A: end:false tc:3371176063 st:true
    DEBUG server comment - rtp[video:512] {80 e0 05 92 c8 f0 10 7f 3f e9 f1 e0 5c 41 7a e5 }
    DEBUG server comment - FU-A: end:true tc:3371176063 st:false
    DEBUG server comment - rtp[video:14] {80 60 05 93 c8 f0 1c 36 3f e9 f1 e0 09 30 }
    DEBUG server comment - SINGLE: end:false tc:3371179062 sz:2
    DEBUG server comment - rtp[video:1400] {80 60 05 94 c8 f0 1c 36 3f e9 f1 e0 5c 81 9a dd }
    My questions are the following:
    • can i assume that wowza is getting video frames correctly ?
    • is it possible to get detailed comments/explanation about the debug messages ?
    Reply With Quote Reply With Quote
  3. 07-02-2008, 11:50 AM #3
    charlie
    charlie is offline Administrator
    Join Date
    Nov 2006
    Posts
    11,317

    Default

    The SDP data does not contain the sprop-parameter-sets parameter. This line usually looks like this in the SDP data.

    Code:
    a=fmtp:96 packetisation-mode=0; profile-level-id=42801e; sprop-parameter-sets=Z01AHuigsPbB6kBAQGQkAAADAAQABX5BgAAHoQAAFuNm974PihM0,aP91IA==
    Without this information Wowza Pro must hunt in the NAL units of the H.264 packets for this data. It can't start video playback until it finds this information. This information is not always contained within the stream.

    I really don't have a specific answer for you. I just know that this is what it seems to be searching for.

    Charlie
    Reply With Quote Reply With Quote
  4. 07-16-2008, 03:30 PM #4
    sullivan
    sullivan is offline Junior Member
    Join Date
    Jul 2008
    Posts
    2

    Default Successful client streaming?

    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,
    Reply With Quote Reply With Quote
  5. 07-16-2008, 04:51 PM #5
    charlie
    charlie is offline Administrator
    Join Date
    Nov 2006
    Posts
    11,317

    Default

    First, try it with Wowza Pro 1.5.1. You can download the upgrade patch here:

    http://www.wowzamedia.com/devbuild.html

    If that doesn't work, follow these instructions and send me the debug log files and the command line you are using:

    Note: If you experience problems getting either the audio or video to play through Flash, double check the version number of the Flash player (Flash player version 9.0.115.0 or above is required). If you still have problems, turn on Wowza Pro debug logging (edit [install-dir]/conf/log4j.properties and change the log4j.rootCategory on the first line from INFO to DEBUG), try the encoder several more times, zip up and send your [install-dir]/logs folder along with screen shots of the encoder setup screens and the LiveVideoStreaming player screen and send a detailed description of your problem to support@wowzamedia.com.
    Charlie
    Last edited by charlie; 07-16-2008 at 04:54 PM.
    Reply With Quote Reply With Quote
  6. 07-16-2008, 05:07 PM #6
    charlie
    charlie is offline Administrator
    Join Date
    Nov 2006
    Posts
    11,317

    Default

    Also, describe how to install gstreamer. I can't get it to work with x264enc. I am on Fedora6.

    Charlie
    Reply With Quote Reply With Quote
  7. 07-16-2008, 07:34 PM #7
    sullivan
    sullivan is offline Junior Member
    Join Date
    Jul 2008
    Posts
    2

    Default x264

    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.
    Reply With Quote Reply With Quote
  8. 08-11-2008, 09:30 AM #8
    Florent.T
    Florent.T is offline Member
    Join Date
    Mar 2008
    Posts
    45

    Default

    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
    Reply With Quote Reply With Quote
  9. 08-13-2008, 05:04 AM #9
    charlie
    charlie is offline Administrator
    Join Date
    Nov 2006
    Posts
    11,317

    Default

    I really don't have any new information here. The format of the sprop-parameter-sets looks OK to me. I think there is an issue with Wowza Pro not being able to recognize keys frames in the stream coming from gstreamer.

    Charlie
    Reply With Quote Reply With Quote
  10. 08-13-2008, 10:11 AM #10
    Florent.T
    Florent.T is offline Member
    Join Date
    Mar 2008
    Posts
    45

    Default

    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
    Reply With Quote Reply With Quote
Page 1 of 7 123 ... LastLast
« Previous Thread | Next Thread »

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

Forum Rules