weird behaviour of rtsp element. Possible bug?

[Guetcho Guetchev]

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