rtp failure(s)

[Chuck Crisler-2]

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

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Tim-Philipp Müller-2]

On Fri, 2012-12-21 at 16:30 -0500, Chuck Crisler wrote:

> 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.

> gstbasesrc.c(2543): gst_base_src_loop
> (): /GstPipeline:pipeline0/GstUDPSrc:udpsrc0:
> streaming task paused, reason not-negotiated (-4)
>
> It *looks* to me like this has been running for a few buffers, so I
> don't understand the 'not-negiotiated' error.

not-negotiated means there's something wrong with the caps somewhere.

In this case, it *might* be that you have to tell rtph264depay manually
to output avc instead of byte-stream format, try with

rtph264depay byte-stream=false access-unit=true ! ffdec_h264 ! ..


> 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.
>


If you dump a GST_DEBUG=*:5 log to file, and then do
 
 grep -B25 not-negotiated dbg.log

That should give a clue where the problem is (which pad/element).


> 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?

You're running an ancient version of GStreamer and gst-plugins-good.
This might already be fixed in later versions (I don't know, I didn't
check).

Cheers
 -Tim

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel