考虑以下 gstreamer 命令(我正在 Windows 中尝试它们):
-
gst-launch-1.0 rtspsrc location=rtsp://<path-to-stream> ! decodebin ! autovideosink
-
gst-launch-1.0 uridecodebin uri=rtsp://<path-to-stream> ! autovideosink
这两个命令都应该在自动创建的窗口上播放视频。但就我而言,第一个只能在 5 次尝试中的 1 次开始播放。而第二个每次都有效。
如果失败,第一个命令会打印出以下消息:
Setting pipeline to PAUSED ... Pipeline is live and does not need PREROLL ... Progress: (open) Opening Stream Progress: (connect) Connecting to rtsp://<path-to-stream-here> Progress: (open) Retrieving server options Progress: (open) Retrieving media info Progress: (request) SETUP stream 0 Progress: (request) SETUP stream 1 Progress: (open) Opened Stream Setting pipeline to PLAYING ... New clock: GstSystemClock Progress: (request) Sending PLAY request Progress: (request) Sending PLAY request Progress: (request) Sent PLAY request WARNING: from element /GstPipeline:pipeline0/GstDecodeBin:decodebin0: Delayed linking failed. Additional debug info: ./grammar.y(506): gst_parse_no_more_pads (): /GstPipeline:pipeline0/GstDecodeBin:decodebin0: failed delayed linking some pad of GstDecodeBin named decodebin0 to some pad of GstAutoVideoSink named autovideosink0 ERROR: from element /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0/GstUDPSrc:udpsrc0: Internal data flow error. Additional debug info: gstbasesrc.c(2948): gst_base_src_loop (): /GstPipeline:pipeline0/GstRTSPSrc:rtsp src0/GstUDPSrc:udpsrc0: streaming task paused, reason not-linked (-1) Execution ended after 0:00:02.289918784 Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ...
从用户的角度来看,这些命令之间的主要区别是什么? 是否有可能使第一个命令更可靠(即像第二个命令一样无错误地工作)?
最佳答案
是否设置了其他属性,例如caps="application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264"
。
如果参数不匹配,就会报错!
关于Gstreamer rtspsrc+decodebin 对比 uridecodebin,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/37528402/