FaSTTUBe/GST-Tensordecoder-ov_ep
37
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

interlace: Increment phase_index before checking if we're at the end of the phase

Browse Source 
Incrementing it afterwards will always have to phase_index >= 1 and we
will never be at the beginning (0) of the phase again, and thus never
reset timestamp tracking accordingly.

This was broken in bea13ef43b719aad96e28766cd4d23652a891a20 in 2010, and
causes interlace to run into integer overflows after 2^31 frames or
about 5 hours at 29.97fps. Due to usage of wrong types for the integers
this then causes negative numbers to be used in calculations and all
calculations spectacularly fail, leading to all following buffers to
have the timestamp of the first buffer minus one nanosecond.
This commit is contained in:
Sebastian Dröge 2019-12-03 15:35:57 +02:00 committed by GStreamer Merge Bot
parent fd6c51b2e7
commit c67146b27a
1 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
gst/interlace/gstinterlace.c
View File

@ -899,13 +899,13 @@ gst_interlace_chain (GstPad * pad, GstObject * parent, GstBuffer * buffer)
interlace->fields_since_timebase = 0;
}
current_fields = format->n_fields[interlace->phase_index];
/* increment the phase index */
interlace->phase_index++;
if (!format->n_fields[interlace->phase_index]) {
interlace->phase_index = 0;
}
current_fields = format->n_fields[interlace->phase_index];
/* increment the phase index */
interlace->phase_index++;
GST_DEBUG ("incoming buffer assigned %d fields", current_fields);
num_fields = interlace->stored_fields + current_fields;