Unexplained freeze/hang from gst-omx omxh264enc on Raspberry Pi 3

[Graham Leggett]

On 16 Nov 2016, at 12:36 AM, Graham Leggett <minfrin at sharp.fm> wrote:

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

It looks like a single corrupt PTS will DoS the pipeline.

Regards,
Graham
—

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3240 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20161117/ac648484/attachment.bin>