Streaming RTP/RTSP: sync/timestamp problems

前端 未结 3 1073
悲哀的现实
悲哀的现实 2021-02-05 16:51

I\'m having some trouble streaming H.264 video over RTSP. The goal is to live-stream a camera image to an RTSP client (ideally a browser plugin in the end). This has been workin

相关标签:
3条回答
  • 2021-02-05 17:05

    You can add "sync=false" to the source gst pipeline. On Ubuntu 12.04 that seems to remove the lag and error messages.

    Here's the command I used on the source:

    gst-launch videotestsrc ! x264enc tune=zerolatency ! rtph264pay ! udpsink host=127.0.0.1 sync=false
    

    and here's what I used on the receiver:

    gst-launch udpsrc ! application/x-rtp,payload=96 ! rtph264depay ! decodebin ! xvimagesink
    

    Unfortunately, I have no idea why that works or even which component the "sync=false" property belongs to (on the source pipeline).

    0 讨论(0)
  • 2021-02-05 17:19

    As root.ctrlc posted, you can use sync=FALSE. However, you might notice a huge increase in CPU usage on the sender's end. The reason is that sync=FALSE tells the sink to just push out buffers as soon as it receives them. The sink drives the whole pipeline. Therefore, sync=FALSE will cause the pipeline to encode video and push it to UDP as fast as possible; it will use 100% CPU.

    What you need is the gstrtpjitterbuffer. It also takes care of the timestamps, which are broken here.

    Example sender:

    gst-launch-0.10 -v videotestsrc ! videorate ! video/x-raw-yuv, framerate=30/1 ! ffmpegcolorspace ! x264enc ! rtph264pay ! udpsink port=50000 host=<sender IP>
    

    Example receiver:

    gst-launch-0.10 udpsrc port=50000 caps="application/x-rtp, media=(string)video, clock-rate=(int)90000 , encoding-name=(string)H264 , payload=(int)96" ! gstrtpjitterbuffer ! rtph264depay ! ffdec_h264 ! ffmpegcolorspace ! videoscale ! "video/x-raw-yuv, width=320, height=240" ! xvimagesink
    
    0 讨论(0)
  • 2021-02-05 17:23

    I don't know how much is this true, but when i run my pipeline without connecting the battery charger to my laptop, it used to throw me the same warning, and when i plugged in the power supply, trust me it worked. I think it is may be because of the old CMOS battery, which isn't working as it should be. as it is responsible for clock generation.

    0 讨论(0)
提交回复
热议问题