weird behaviour of rtsp element. Possible bug? Follow up (yes, it is a bug).

Fri Dec 21 14:19:11 PST 2012

Hello again, guys.
Today I saw that this assertion: GStreamer-CRITICAL **: gst_segment_to_running_time: assertion `segment->format == format' failed
remains valid even with the classic usage of get-launch (Gstreamer 1.0.4): 

gst-launch-1.0 rtspsrc location=rtsp://bbs.darktech.org:1935/live/iphone.sdp ! capsfilter caps=application/x-rtp,media=video,payload=96,clock-rate=90000,encoding-name=H264 ! rtph264depay ! h264parse ! capsfilter caps=video/x-h264,alignment=au ! avdec_h264 ! filesink location=./bla.movie

Just before that call you need to start the executable built from that git repository: https://github.com/ggetchev/gst_test
You can initiate the stream by using the command line:

./gsttest <file> --no-reception
Where <file> is the bunzip2-ed file 1.move.bz2 from the same repository.

I believe this is a bug in Gstreamer. 

Regards,
G

On Dec 21, 2012, at 2:18 AM, Guetcho Guetchev <getcho.getchev at gmail.com> wrote:

> Hello guys,
> 
> I banged my head several days and I did not came to a conclusion. 
> The full sources you can get form here: https://github.com/ggetchev/gst_test
> The file which is used is named gsttest2.c
> The media file is located in the same repository, named 1.movie.bz2 (you should bunzip2 it first). 
> 
> Use the makefile to build the example.
> The example is intended to be run against Gstreamer 1.0.4 (tagged, taken straight from the git repository, no snapshots, no tarballs).
> 
> I have the following pipelines:
> 
> Transmission pipeline:
> 
> appsrc -- x264enc -- capsfilter -- rtph264depay -- udpsink
> 
> 
> Settings:
> 
> appsrc properties:
> caps = video/x-raw; format=I420; framerate=20; width=480; height=640
> format = GST_FORMAT_TIME,
> max-latency = min-latency = 0
> size = -1
> max-bytes = 5 * 480 * 640 * 3 / 2;
> 
> x264enc:
> bitrate = 3 * 512
> tune = 4
> speed-preset = 3
> threads = 1
> bframes = 0
> b-adapt = 0
> cabac = 0
> dct8x8 = 0
> aud = 0
> byte-stream=1
> key-int-max = 10
> quantizer = 50
> vbv-buf-capacity = 0
> 
> capsfilter:
> caps = "video/x-h264;stream-format=byte-stream; alignment=au"
> 
> udpsink:
> host = HOST
> port = PORT
> force-ipv4 = 1
> sync = FALSE
> 
> 
> Reception pipeline:
> 
> rtspsrc --- capsfilter(1) -- rtph264depay --- h264parse --- capsfilter(2) --- avdec_h264 --- appsink
> 
> Settings:
> 
> appsink:
> caps = "video/x-raw;format=BGRA"
> 
> capsfilter(2):
> caps = "video/x-h264;alignment=au"
> 
> capsfilter(1):
> caps = "application/x-rtp;media=video;payload=96;clock-rate=90000;encoding-name=H264"
> 
> The only media that is used is video.
> 
> The server used in that example is a Wowza Media Server. The transmission pipeline works fine. It's output can be observed with the use of QuickTime or VLC. Which proves both the server and the pipeline are working.
> 
> However on the receiving pipeline some weird things happen:
> I get this assertion:
> 
> (gsttest:7390): GStreamer-CRITICAL **: gst_segment_to_running_time: assertion `segment->format == format' failed
> This assertion however terminates the pipeline job.
> 
> The backtrace (obtained after setting G_DEBUG="fatal-criticals") is:
> 
> Program received signal SIGTRAP, Trace/breakpoint trap.
> [Switching to Thread 0xb62ffb40 (LWP 7402)]
> 0xb7dd669d in g_logv () from /lib/i386-linux-gnu/libglib-2.0.so.0
> (gdb) bt
> #0  0xb7dd669d in g_logv () from /lib/i386-linux-gnu/libglib-2.0.so.0
> #1  0xb7dd6823 in g_log () from /lib/i386-linux-gnu/libglib-2.0.so.0
> #2  0xb7dd686d in g_return_if_fail_warning () from /lib/i386-linux-gnu/libglib-2.0.so.0
> #3  0xb7f4e2c8 in gst_segment_to_running_time (segment=0xb71300b8, format=GST_FORMAT_TIME, position=1717999299) at gstsegment.c:476
> #4  0xb6e11b57 in gst_rtp_base_depayload_chain (pad=0xb7108d70, parent=0xb7130000, in=0xb36f8658) at gstrtpbasedepayload.c:270
> #5  0xb7f2b8aa in gst_pad_chain_data_unchecked (data=0xb36f8658, type=3068204944, pad=0xb7108d70) at gstpad.c:3654
> #6  gst_pad_push_data (pad=0xb712e138, type=3068204944, data=0xb36f8658) at gstpad.c:3871
> #7  0xb7b0eeb1 in gst_base_transform_chain (pad=0xb712e000, parent=0xb71108c8, buffer=0xb36f8658) at gstbasetransform.c:2203
> #8  0xb7f2b8aa in gst_pad_chain_data_unchecked (data=0xb36f8658, type=3081825424, pad=0xb712e000) at gstpad.c:3654
> #9  gst_pad_push_data (pad=0x8141018, type=3081825424, data=0xb36f8658) at gstpad.c:3871
> #10 0xb7f1ba72 in gst_proxy_pad_chain_default (pad=0x8142028, parent=0x8141018, buffer=0xb36f8658) at gstghostpad.c:128
> #11 0xb7f2b8aa in gst_pad_chain_data_unchecked (data=0xb36f8658, type=3086072256, pad=0x8142028) at gstpad.c:3654
> #12 gst_pad_push_data (pad=0xb3604b00, type=3086072256, data=0xb36f8658) at gstpad.c:3871
> #13 0xb645a54d in gst_rtp_dec_chain_rtp (pad=0xb3604140, parent=0xb3601000, buffer=0xb36f8658) at gstrtpdec.c:532
> #14 0xb7f2b8aa in gst_pad_chain_data_unchecked (data=0xb36f8658, type=3058016688, pad=0xb3604140) at gstpad.c:3654
> #15 gst_pad_push_data (pad=0xb712eea0, type=3058016688, data=0xb36f8658) at gstpad.c:3871
> #16 0xb7b04ffe in gst_base_src_loop (pad=0xb712eea0) at gstbasesrc.c:2710
> #17 0xb7f5cf38 in gst_task_func (task=0xb6335bc8) at gsttask.c:316
> #18 0xb7f5e198 in default_func (tdata=0xb6301090, pool=0x805f410) at gsttaskpool.c:70
> #19 0xb7df3047 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
> #20 0xb7df26b3 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
> #21 0xb7b7cd4c in start_thread (arg=0xb62ffb40) at pthread_create.c:308
> #22 0xb7cbfd3e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130
> 
> It is obvious a media segment has a format of GST_FORMAT_UNDEFINED but the expected format is GST_FORMAT_TIME
> 
> After debugging on the rtsp element I found out that by some reason a RECONFIGURE event is pushed. However the reception pipeline is not being reconfigured - all its elements are created and added at the same time.
> All links are made between them. Except the link rtsp -- capsfilter(1), obviously because rtsp element has no pads. The link between the rtsp element and the capsfilter(1) is made upon pad-added signal occurrence. 
> The RECONFIGURE event comes shortly after the link rtsp -- capsfilter  is established.
> 
> After a short talk with Tim on the Gstreamer IRC channel he stated that this might be a bug. However I am not sure whether I do something wrong or that is a real bug. 
> The case is trivial, IMHO. 
> Can someone help me?
> 
> Regards,
> Vahan
> 
> 
> 
> 
> 
> 
> 
> 