Sur d’autres sites (18237)

• Why does use of H264 in sender/receiver pipelines introduce just HUGE delay ?

  24 janvier 2012, par Serguey Zefirov

  When I try to create pipeline that uses H264 to transmit video, I get some enormous delay, up to 10 seconds to transmit video from my machine to... my machine ! This is unacceptable for my goals and I'd like to consult StackOverflow over what I (or someone else) do wrong.

  I took pipelines from gstrtpbin documentation page and slightly modified them to use Speex :

  This is sender pipeline :
  # !/bin/sh

  gst-launch -v gstrtpbin name=rtpbin \
  
          v4l2src ! ffmpegcolorspace ! ffenc_h263 ! rtph263ppay ! rtpbin.send_rtp_sink_0 \
  
                    rtpbin.send_rtp_src_0 ! udpsink host=127.0.0.1 port=5000                            \
  
                    rtpbin.send_rtcp_src_0 ! udpsink host=127.0.0.1 port=5001 sync=false async=false    \
  
                    udpsrc port=5005 ! rtpbin.recv_rtcp_sink_0                           \
  
          pulsesrc ! audioconvert ! audioresample  ! audio/x-raw-int,rate=16000 !    \
  
                    speexenc bitrate=16000 ! rtpspeexpay ! rtpbin.send_rtp_sink_1                   \
  
                    rtpbin.send_rtp_src_1 ! udpsink host=127.0.0.1 port=5002                            \
  
                    rtpbin.send_rtcp_src_1 ! udpsink host=127.0.0.1 port=5003 sync=false async=false    \
  
                    udpsrc port=5007 ! rtpbin.recv_rtcp_sink_1

  Receiver pipeline :

   !/bin/sh

  gst-launch -v\
  
      gstrtpbin name=rtpbin                                          \
  
      udpsrc caps="application/x-rtp,media=(string)video, clock-rate=(int)90000, encoding-name=(string)H263-1998" \
  
              port=5000 ! rtpbin.recv_rtp_sink_0                                \
  
          rtpbin. ! rtph263pdepay ! ffdec_h263 ! xvimagesink                    \
  
       udpsrc port=5001 ! rtpbin.recv_rtcp_sink_0                               \
  
       rtpbin.send_rtcp_src_0 ! udpsink port=5005 sync=false async=false        \
  
      udpsrc caps="application/x-rtp,media=(string)audio, clock-rate=(int)16000, encoding-name=(string)SPEEX, encoding-params=(string)1, payload=(int)110" \
  
              port=5002 ! rtpbin.recv_rtp_sink_1                                \
  
          rtpbin. ! rtpspeexdepay ! speexdec ! audioresample ! audioconvert ! alsasink \
  
       udpsrc port=5003 ! rtpbin.recv_rtcp_sink_1                               \
  
       rtpbin.send_rtcp_src_1 ! udpsink host=127.0.0.1 port=5007 sync=false async=false

  Those pipelines, a combination of H263 and Speex, work fine enough. I snap my fingers near camera and micropohne and then I see movement and hear sound at the same time.

  Then I changed pipelines to use H264 along the video path.

  The sender becomes :
  # !/bin/sh

  gst-launch -v gstrtpbin name=rtpbin \
  
          v4l2src ! ffmpegcolorspace ! x264enc bitrate=300 ! rtph264pay ! rtpbin.send_rtp_sink_0 \
  
                    rtpbin.send_rtp_src_0 ! udpsink host=127.0.0.1 port=5000                            \
  
                    rtpbin.send_rtcp_src_0 ! udpsink host=127.0.0.1 port=5001 sync=false async=false    \
  
                    udpsrc port=5005 ! rtpbin.recv_rtcp_sink_0                           \
  
          pulsesrc ! audioconvert ! audioresample  ! audio/x-raw-int,rate=16000 !    \
  
                    speexenc bitrate=16000 ! rtpspeexpay ! rtpbin.send_rtp_sink_1                   \
  
                    rtpbin.send_rtp_src_1 ! udpsink host=127.0.0.1 port=5002                            \
  
                    rtpbin.send_rtcp_src_1 ! udpsink host=127.0.0.1 port=5003 sync=false async=false    \
  
                    udpsrc port=5007 ! rtpbin.recv_rtcp_sink_1

  And receiver becomes :
  # !/bin/sh

  gst-launch -v\
  
      gstrtpbin name=rtpbin                                          \
  
      udpsrc caps="application/x-rtp,media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264" \
  
              port=5000 ! rtpbin.recv_rtp_sink_0                                \
  
          rtpbin. ! rtph264depay ! ffdec_h264 ! xvimagesink                    \
  
       udpsrc port=5001 ! rtpbin.recv_rtcp_sink_0                               \
  
       rtpbin.send_rtcp_src_0 ! udpsink port=5005 sync=false async=false        \
  
      udpsrc caps="application/x-rtp,media=(string)audio, clock-rate=(int)16000, encoding-name=(string)SPEEX, encoding-params=(string)1, payload=(int)110" \
  
              port=5002 ! rtpbin.recv_rtp_sink_1                                \
  
          rtpbin. ! rtpspeexdepay ! speexdec ! audioresample ! audioconvert ! alsasink \
  
       udpsrc port=5003 ! rtpbin.recv_rtcp_sink_1                               \
  
       rtpbin.send_rtcp_src_1 ! udpsink host=127.0.0.1 port=5007 sync=false async=false

  This is what happen under Ubuntu 10.04. I didn't noticed such huge delays on Ubuntu 9.04 - the delays there was in range 2-3 seconds, AFAIR.

• The fdsink element in GStreamer cannot be used to output the correct byte-stream to the pipeline

  21 avril 2022, par yuniversi

  Because I need to output the RTSP stream pulled from the GStreamer command line to my Python program, I use the fdsink element to output the byte-stream from the pipeline.
The video can be displayed correctly by using the xvimagesink element. The command line is as follows.

  


  gst-launch-1.0 rtspsrc location=rtsp://wowzaec2demo.streamlock.net/vod/mp4:BigBuckBunny_115k.mp4 ! queue2 ! rtph264depay ! capsfilter caps="video/x-h264, width=240, height=160" ! avdec_h264 ! videoconvert ! xvimagesink


  


  Correct video :


  


  Then I use fdsink instead of the xvimagesink element to output the byte stream from the pipeline and play it with ffplay. It can't display correct video. The command line is as follows.

  


  gst-launch-1.0 rtspsrc location=rtsp://wowzaec2demo.streamlock.net/vod/mp4:BigBuckBunny_115k.mp4 ! queue2 ! rtph264depay ! capsfilter caps="video/x-h264, width=240, height=160" ! avdec_h264 ! videoconvert ! fdsink | ffplay -f rawvideo -pixel_format rgb24 -video_size 240*160 -i -


  


  Wrong video :

  


  So is fdsink element wrong or other elements wrong ? Thank you for taking the time to help me solve the problem

  


• ffmpeg rtp streaming errors : RTP : dropping old packet received too late

  2 février 2019, par Андрей_RnD

  I start video transfer by means of ffmpeg like this :

  ffmpeg -f video4linux2 -i /dev/video0 -vcodec libx264 -preset ultrafast -crf 20 -tune zerolatency -s 800x600 -r 25 -b:v 0.9M -sdp_file video.sdp -f rtp rtp://192.168.10.24:5010    

  I reproduce this way :

  ffplay -protocol_whitelist file,udp,rtp video.sdp    

  Everything works just fine. Then I interrupt transmission and after a couple of seconds I resume. ffplay does not immediately start to reproduce but errors occur :

  ....
  
  [sdp @ 0x6ebf80] RTP: dropping old packet received too lateB f=1/1
  
      Last message repeated 14 times
  
  [sdp @ 0x6ebf80] RTP: dropping old packet received too lateB f=1/1
  
      Last message repeated 33 times
  
  [sdp @ 0x6ebf80] RTP: dropping old packet received too lateB f=1/1
  
      Last message repeated 41 times
  
  [sdp @ 0x6ebf80] RTP: dropping old packet received too lateB f=1/1
  
      Last message repeated 49 times
  
  [sdp @ 0x6ebf80] RTP: dropping old packet received too lateB f=1/1
  
      Last message repeated 33 times
  
  [sdp @ 0x6ebf80] RTP: dropping old packet received too lateB f=1/1
  
      Last message repeated 27 times
  
  [sdp @ 0x6ebf80] RTP: dropping old packet received too lateB f=1/1
  
      Last message repeated 14 times
  
  [sdp @ 0x6ebf80] RTP: dropping old packet received too lateB f=1/1
  
      Last message repeated 48 times
  
  [sdp @ 0x6ebf80] RTP: dropping old packet received too lateB f=1/1
  
      Last message repeated 34 times
  
  ......    

  After a some time, playback is restored, but it is too long. Is there a way to eliminate or minimize the occurrence of errors of this nature when the incoming stream is suspended, can options or something else ? Read the manual ffmpeg nothing worthwhile about this did not naryl .... ((((