GNOME Bugzilla – Bug 596964
[rtpmp2tdepay] fails after pcapparse
Last modified: 2009-10-06 17:49:51 UTC
* step to reproduce: GST_DEBUG=2 gst-launch-0.10 filesrc location=capture2.pcap ! pcapparse ! rtpmp2tdepay ! mpegtsdemux ! ffdec_h264 ! xvimagesink * result: gstbasesrc.c:2378:gst_base_src_loop:<filesrc0> error: streaming task paused, reason not-negotiated (-4) * expected result: The video should be displayed as using udpsrc: gst-launch-0.10 udpsrc uri=udp://232.0.1.1:8200 caps="application/x-rtp, media=video" ! queue ! rtpmp2tdepay ! mpegtsdemux ! ffdec_h264 ! xvimagesink * other infos: gst-launch-0.10 playbin uri=file:///home/julien/capture2.pcap does not introduce pcapparse element and also it does not introduce a rtp depayloader.
Created attachment 144476 [details] it contains a pcap dump of a multicast flow
if i add a caps filter (in order to fix the caps) then it works fine: gst-launch-0.10 filesrc location=capture2.pcap ! pcapparse ! "application/x-rtp, media=video, payload=96, clock-rate=1" ! rtpmp2tdepay ! mpegtsdemux ! ffdec_h264 ! xvimagesink Anyway, why decodebin does not introduce a pcapparse and a rtpdepayloader ? Is the fault from typefind ?
You need a capsfilter after the filesrc to specify the media type of the bytes. We don't yet typefind RTP packets or pcap files and even less the possible media type inside the RTP packets. I would mark this as not-a-bug. You could reopen this as a feature request to typefind RTP and pcap but this sounds like a difficult, error prone task.
ok thx