• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 99 subscribers
  • Views 2090 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

OMAP4460: Problem with Ducati and Gstreamer on Pandaboard

Adrian Dubiel
Prodigy 90 points

Hello,

I'm using gstreamer on Pandaboard running Ubuntu 11.10. I want to make videoconferencing but have some problems with ducati h264 encoding/decoding. Currently I encode video (from webcam), stream via RTP to media server (Wowza) and get this stream back to panda (via RTSP) then decode and show video. Everything works good until (probably) ducati decoder hangs (usually after few miuntes or when I leave it for a while and suddenly make some rapid moves in front of the camera).
I suspect decoder because if I'm only running encoded stream there is no problem. These are my gst commands:
Sender:
gst-launch -v gstrtpbin name=rtpbin  v4l2src device=/dev/video3  num-buffers=-1 ! "video/x-raw-yuv, width=320, height=240,framerate=20/1" ! queue ! colorspace \
! tee name=tee tee.src1 ! queue ! pvrvideosink tee.src2 ! queue ! ducatih264enc ! h264parse !  rtph264pay ! rtpbin.send_rtp_sink_0 rtpbin.send_rtp_src_0  \
! udpsink port=5000 host=192.168.3.206 ts-offset=0 name=vrtpsink rtpbin.send_rtcp_src_0
Receiver:
gst-launch -v rtspsrc location="rtsp://192.168.3.206:1935/live/video4.sdp" ! gstrtpjitterbuffer latency=100 ! rtph264depay ! h264parse \
! "video/x-h264, width=320, height=240,framerate=20/1" ! ducatih264dec ! colorspace ! pvrvideosink

File video4.sdp (which is run on Wowza server to stream incoming video):
o=- 3818915560 IN IP4 192.168.3.206
s=Panda Video
i=N/A
c=IN IP4 192.168.3.206
t=0 0
m=video 5000 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 media=video; clock-rate=90000; encoding-name=H264; sprop-parameter-sets=J2QAKKzKgUH5,KN4Briw=; ssrc=3818915560; payload=(int)96; clock-base=2277541302; seqnum-base=37988
a=control:trackID=1

I tried to change ducatih264dec to ffdec_h264 and the diffrence was that the decoding stops after some minutes but encoding was still running whilst when ducati264dec is hung it also hangs encoding. I've also tried to remove gstrtpbin because I've read somewhere there could be buffer problem but it didn't help. CPU usage is small.

Do you have any ideas?

Regards,
Adrian
  • 0
    TI__Mastermind 24525 points

    >>ducati decoder hangs (usually after few miuntes or when I leave it for a while and suddenly make some rapid moves in front of the camera)

    Its a wild guess, but maybe worth trying. When you make sudden rapid move in front of camera, it is possible that encoder's bitrate is shooting through the roof and all 1D tiler buffers are grabbed by encoder, leaving decoder to starve. 

    I could not find any bitrate config in your gst pipe. Can you try setting a bitrate (preferably constant bitrate) at encoder?

  • 0 in reply to Mayank Mangla
    Prodigy 90 points

    Thanks for your suggestion! I check it when I get back to work on Monday.

  • 0 in reply to Adrian Dubiel
    Prodigy 90 points

    I've changed encoder parameters that I decreased bitrate to 512 kbps (previously there was 2048 kbps), profile to baseline (was high) and level to 3 (was 4). Unfortunately it didn't improve anything.. However, I veryfied the source of the problem and now I think it is rather encoder than decoder, because I see that the encoder fails first. But I still don't understand why when I run only encoding (without decoding) it works without stopping. Moreover, when I ran it with 320x240 resolution with increased receiver rtspsrc udp buffer I felt like it worked for longer period of time, but when I tried it with 640x480 the time was shorter and more dependant on rapid moves (I suppose....). I don't know what more I can do :/ 

  • 0 in reply to Adrian Dubiel
    TI__Mastermind 24525 points

    Try setting num_buffers to a finite value (for e.g. 8). Currently you are setting it as num-buffers=-1 which means infinite buffers.

  • 0 in reply to Mayank Mangla
    Prodigy 90 points

    Mayank Mangla said:

    Currently you are setting it as num-buffers=-1 which means infinite buffers.

    That's right, because according to manual num-buffers is  "number of buffers to output before sending EOS (-1 = unlimited)." So I thought if I set finite number then my stream will stop after a while depending on this buffer size.. I need to stream no matter how long.. But ok I will try this and check if it doesn't stop, maybe I'm missing something... 

  • 0 in reply to Adrian Dubiel
    Prodigy 90 points

    sorry for late answer, but just as I thought num-buffers set up how many bytes will be aquired from camera 

  • 0 in reply to Adrian Dubiel
    TI__Intellectual 1165 points

    Adrian,

    GStreamer traces would help to understand the root cause. For this, run: GST_DEBUG=*:2 gst-launch ...

    Also you may try the following modifications one by one, in order to rule out each element:

    * Replace pvrvideosink by fakesink (or remote completely this part of the pipeline)

    * Replace ducatih264enc by ducatimpeg4enc or ffenc_mpeg4, and h264parse by mpeg4videoparse (on both sides)

    * Replace colorspace by ffmpegcolorspace

    * Run the sender and receiver pipelines in two processes on the same machine, without network, like this:

    ( gst-launch -v v4l2src ! .... ! fdsink fd=3 ) 3>&1 >&2 | gst-launch -v fdsrc ! ... ! pvrvideosink

    Hopefully this will help to narrow down the issue.

    Regards,

    -- Olivier