[Bug 690632] New: rtsp reception pipeline gets an assertion when handling and parsing / decoding H264 packets

Fri Dec 21 16:21:51 PST 2012

https://bugzilla.gnome.org/show_bug.cgi?id=690632
  GStreamer | gstreamer (core) | 1.0.5

           Summary: rtsp reception pipeline gets an assertion when
                    handling and parsing / decoding H264 packets
    Classification: Platform
           Product: GStreamer
           Version: 1.0.5
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: critical
          Priority: Normal
         Component: gstreamer (core)
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: getcho.getchev at gmail.com
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Overview: 
At Gstreamer 1.0.4

The pipeline:
rtspsrc -- capsfilter -- rtph264depay -- h264parse -- capsfilter -- avdec_h264
-- appsink 
Causes GStreamer-CRITICAL **: gst_segment_to_running_time: assertion
`segment->format == format' failed and stops working.

Steps to Reproduce: 

1. clone https://github.com/ggetchev/gst_test and build the gsttest application
(use make). 
2. Bunzip2 the file 1.movie.bz2 to let say file.movie.
3. Execute in a shell: ./gsttest ./file.movie --no-reception
4. launch the pipeline:

gst-launch-1.0 rtspsrc location=rtsp://bbs.darktech.org:1935/live/iphone.sdp !
capsfilter name=c1
caps=application/x-rtp,media=video,payload=96,clock-rate=90000,encoding-name=H264
! rtph264depay ! h264parse ! capsfilter name=c2 caps=video/x-h264,alignment=au
! avdec_h264 ! capsfilter name=c3 caps=video/x-raw,format=I420 ! avenc_tiff !
multifilesink location=./file_%05d.tiff

Actual Results: There are tiff files, but none of them is a real tiff file. A
lot of criticals is printed on the output: GStreamer-CRITICAL **:
gst_segment_to_running_time: assertion `segment->format == format' failed

If the last three elements (capsfilter name=c3, avenc_tiff, multifilesink) are
substituted by appsink element - the sample delivery is broken by forced EOS
signal / callback. 

Expected Results: 
1. No criticals in the output.
2. The tiff files produced should be valid images.
3. If the last three elements are substituted by an appsink element the sample
delivery should not be interrupted.

That happens on Gstreamer 1.0.4, taken from git repository (tag = 1.0.4)
OS: Ubuntu 12.04 LTS, 32-bit.

Additional Information: The callstack when setting GST_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

The media sent to the server is processed by the following pipeline (look at
the file gsttest2.c from the git repository mentioned above):

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 = bbs.darktech.org
port = 1938
force-ipv4 = 1
sync = FALSE

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.