rtp failure(s)

[Chuck Crisler]

I am trying to receive, decode and display video received via RTP with the
following test pipeline.

gst-launch udpsrc port=$1 !
'application/x-rtp,media=video,payload=96,clock-rate=90000,encoding-name=H264'
\
    ! gstrtpjitterbuffer mode=0 ! rtph264depay ! video/x-h264 ! ffdec_h264
! ximagesink sync=false

I am using the good-plugins v. 0.10.23. When I get an incoming media stream
it immediate fails with the following message.

Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
ERROR: from element /GstPipeline:pipeline0/GstUDPSrc:udpsrc0: Internal data
flow error.
Additional debug info:
gstbasesrc.c(2543): gst_base_src_loop ():
/GstPipeline:pipeline0/GstUDPSrc:udpsrc0:
streaming task paused, reason not-negotiated (-4)
Execution ended after 1301072468 ns.
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...

Here is a snippet of the log file.

0:00:01.286025792  8432  0x880f7a0 DEBUG                basesrc
gstbasesrc.c:2114:gst_base_src_get_range:<udpsrc0> calling create offset
18446744073709551615 length 4096, time 0
0:00:01.286063522  8432  0x880f7a0 LOG                  basesrc
gstbasesrc.c:1953:gst_base_src_do_sync:<udpsrc0> created timestamp:
0:00:01.190901584
0:00:01.286084973  8432  0x880f7a0 DEBUG                basesrc
gstbasesrc.c:1988:gst_base_src_do_sync:<udpsrc0> no sync needed
0:00:01.286104364  8432  0x880f7a0 DEBUG                basesrc
gstbasesrc.c:2155:gst_base_src_get_range:<udpsrc0> buffer ok
0:00:01.286182518  8432  0x880f7a0 LOG                  basesrc
gstbasesrc.c:2367:gst_base_src_loop:<udpsrc0> next_ts 99:99:99.999999999
size 4096
0:00:01.286204841  8432  0x880f7a0 DEBUG                basesrc
gstbasesrc.c:2114:gst_base_src_get_range:<udpsrc0> calling create offset
18446744073709551615 length 4096, time 0
0:00:01.291782805  8432  0x880f588 DEBUG                basesrc
gstbasesrc.c:1083:gst_base_src_default_query:<udpsrc0> query convert
returns 0
0:00:01.355319069  8432  0x880f7a0 LOG                  basesrc
gstbasesrc.c:1953:gst_base_src_do_sync:<udpsrc0> created timestamp:
0:00:01.260152236
0:00:01.355402940  8432  0x880f7a0 DEBUG                basesrc
gstbasesrc.c:1988:gst_base_src_do_sync:<udpsrc0> no sync needed
0:00:01.355424981  8432  0x880f7a0 DEBUG                basesrc
gstbasesrc.c:2155:gst_base_src_get_range:<udpsrc0> buffer ok
0:00:01.355516857  8432  0x880f7a0 INFO                 basesrc
gstbasesrc.c:2483:gst_base_src_loop:<udpsrc0> pausing after gst_pad_push()
= not-negotiated
0:00:01.355540184  8432  0x880f7a0 DEBUG                basesrc
gstbasesrc.c:2509:gst_base_src_loop:<udpsrc0> pausing task, reason
not-negotiated
0:00:01.355587785  8432  0x880f7a0 WARN                 basesrc
gstbasesrc.c:2543:gst_base_src_loop:<udpsrc0> error: Internal data flow
error.
0:00:01.355607514  8432  0x880f7a0 WARN                 basesrc
gstbasesrc.c:2543:gst_base_src_loop:<udpsrc0> error: streaming task paused,
reason not-negotiated (-4)
ERROR: from element /GstPipeline:pipeline0/GstUDPSrc:udpsrc0: Internal data
flow error.

It *looks* to me like this has been running for a few buffers, so I don't
understand the 'not-negiotiated' error.

Would anyone please suggest what is wrong or what I can do to diagnose the
problem? I am feeding it with a rather complicated setup. I capture a v4l2
source, encode H264, mpeg2t mux, transmit over the network to another
system, receive with udpsrc, de-mux, rtph264pay pt=96, then transmit to the
system that fails. There are actually reasons for convoluted setup. The
inverse (capture, rtp -> transmit, rtph264depay, mp2t mux -> transmit,
mp2tdemux, decode, display) works nicely.

A second issue that I have seen in packet captures is that none of the RTP
packets seems to have the marker bit set. That seems like a serious problem
to me because that bit delineates the end of frame so that the decoder can
then be run. Is there something that I missed there?

Thank you and a Merry Christmas to all!

Chuck Crisler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20121221/55083162/attachment.html>