g_sequence_remove_range's end iter is exclusive, so if one
wants to remove that item as well, it should be called with
the next iter.
This could in theory fix an issue where:
* The sequence isn't entirely trimmed, with an old item lingering
* Following FEC packets are immediately discarded because they
arrived later than corresponding media packets, long enough for
seqnums to wrap around
* We now try to reconstruct a media packet with a completely obsolete
FEC packet, chaos ensues.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1341>
GST_TRACE_OBJECT (dec,
"Trimming packets up to %" GST_TIME_FORMAT " (seq: %u)",
GST_TIME_ARGS (GST_BUFFER_DTS_OR_PTS (item->buffer)), item->seq);
- g_sequence_remove_range (g_sequence_get_begin_iter (dec->packets), iter);
+ g_sequence_remove_range (g_sequence_get_begin_iter (dec->packets),
+ g_sequence_iter_next (iter));
}
}
D ? "row" : "column",
GST_TIME_ARGS (GST_BUFFER_DTS_OR_PTS (item->buffer)), item->seq);
g_sequence_remove_range (g_sequence_get_begin_iter (dec->fec_packets[D]),
- iter);
+ g_sequence_iter_next (iter));
}
}