[Bug 774600] mpegtsdemux: Pipeline hang on lossy transport stream

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=774600

--- Comment #1 from minfrin at sharp.fm ---
0:01:35.201549213 14697 0x74301db0 DEBUG           videodecoder
gstvideodecoder.c:2703:gst_video_decoder_prepare_finish_frame:<omxh264dec-omxh264dec0>
no valid PTS, using oldest DTS 0:07:14.952708481

Placing a breakpoint at this point and taking a look at the frame that
triggered this message, we find this:

0:01:40.252680427   351 0x74e021b0 DEBUG           videodecoder
gstvideodecoder.c:2654:gst_video_decoder_prepare_finish_frame:<omxh264dec-omxh264dec0>
sync timestamp 0:07:15.792708481 diff -0:07:15.792708481
0:01:40.253014642   351 0x74e021b0 DEBUG           videodecoder
gstvideodecoder.c:3174:gst_video_decoder_clip_and_push_buf:<omxh264dec-omxh264dec0>
pushing buffer 0x6c7bb3e0 of size 470016, PTS 0:07:15.792708481, dur
0:00:00.040000000
0:01:40.254921651   351 0x73144ec0 DEBUG           videodecoder
gstvideodecoder.c:1728:gst_video_decoder_src_query:<omxh264dec-omxh264dec0>
received query 5123, duration
0:01:40.255264043   351 0x73144ec0 DEBUG                tsdemux
tsdemux.c:516:gst_ts_demux_srcpad_query: query duration
0:01:40.255315657   351 0x73144ec0 DEBUG                tsdemux
tsdemux.c:527:gst_ts_demux_srcpad_query:<tsdemux0> only query duration on TIME
is supported
[Switching to Thread 0x6dfff460 (LWP 366)]

Breakpoint 1, gst_video_decoder_prepare_finish_frame (decoder=0x74e28190,
frame=0x7314e950, dropping=1) at gstvideodecoder.c:2700
2700          frame->pts = min_ts + priv->pts_delta;
(gdb) print frame->pts
$1 = 18446744073709551615
(gdb) print priv->reordered_output
$2 = 0
(gdb) print *frame
$3 = {ref_count = 2, flags = 0, system_frame_number = 3456, decode_frame_number
= 3456, presentation_frame_number = 0, dts = 139992708481, pts =
18446744073709551615, duration = 40000000, 
 distance_from_sync = 3456, input_buffer = 0x6e1d38d0, output_buffer = 0x0,
deadline = 18446744073709551615, events = 0x0, user_data = 0x0,
user_data_destroy_notify = 0x0, abidata = {ABI = {
     ts = 434912708481, ts2 = 18446744073709551615}, padding = {0x42d14781,
0x65, 0xffffffff, 0xffffffff, 0x0 <repeats 16 times>}}}
(gdb) 

Specifically, the PTS on this frame is 18446744073709551615
(GST_CLOCK_TIME_NONE), as is the “deadline” and the “ts2”.

This triggers the code that replaces the bogus PTS with DTS, which is in the
future compared to the frames that follow, leading to this:

0:01:35.202174569 14697 0x74301db0 WARN            videodecoder
gstvideodecoder.c:2767:gst_video_decoder_prepare_finish_frame:<omxh264dec-omxh264dec0>
decreasing timestamp (0:07:14.952708481 < 0:07:15.792708481)
0:01:35.202333421 14697 0x74301db0 DEBUG           videodecoder
gstvideodecoder.c:2847:gst_video_decoder_drop_frame:<omxh264dec-omxh264dec0>
dropping frame 0:07:15.792708481

The videodecoder starts dropping all frames, and shortly afterwards the
pipeline freezes up completely.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.