v4l2h264dec0: Too old frames, bug in decoder -- please file a bug
This g_warning is triggered by an anomaly (NOT a decoder bug) where the first few video frames are not processed in gstv4l2videodec.c gst_v4l2_video_dec_loop(GstVideodecoder *decoder)
.
For certain streams, (described below) the first frame to get past line 712
frame =
gst_video_decoder_get_frame (decoder,
GST_BUFFER_TIMESTAMP (buffer) / GST_SECOND);
is the frame with frame->system_frame_number = 4, while frames 0,1,2,3 are waiting, with oldest_frame->system_frame_number = 0. These only get removed by the garbage collection code when frames 101 - 104 are processed, triggering the warning four times.
I could not diagnose why the these frames dont get through. There is one instance of a return at line 693
if (ret == GST_V4L2_FLOW_RESOLUTION_CHANGE) { GST_WARNING_OBJECT (decoder, "Received resolution change"); g_atomic_int_set (&self->capture_configuration_change, TRUE); return; }
The source is an h264 video stream (Apple Airplay from an iOS client) where the first frame has the structure 0x00 0x00 0x00 0x01 SPS 0x00 0x00 00x00 0x01 PPS 0x00 0x00 00x00 0x01 (h264 video) and thereafter only 0x00 0x00 0x00 0x01 (h264 video).
Every works fine when an appsrc with no caps set injects this into a video pipeline starting with h264parse. Possibly a few (4) initial video frames are lost, but every then works fine in the pipeline, so no decoder errors.
The cleanup of these first four orphan frames ideally should only generate a GST_DEBUG-2 warning, not the "annoying" g_warning it now does.