In my case I was tracking a bug that occurred when I did the following:
gst_element_seek_simple(pipeline, GST_FORMAT_TIME, (GstSeekFlags)(GST_SEEK_FLAG_FLUSH | GST_SEEK_FLAG_KEY_UNIT), 0)
The src was a souphttpsrc.
The stream was a mpegts.
Since I searched for GST_FORMAT_TIME, the mpegtsdemux element did the conversion to bytes. This conversion resulted in a byte value that was extremely large, and thus far beyond the end of the file. At another place the byte position was truncated to the file length +1. But basically the problem was found in the mpegtspacketizer. There, in the mpegts_packetizer_ts_to_offset function the offset is calculated.
querypcr = GSTTIME_TO_PCRTIME (ts);
breaks the querypcr, which is 0 in my case.
In the function the variable ret is first set to
res = firstoffset;
which I can understand.
But after that the following is done:
if (lastpcr != firstpcr) res += gst_util_uint64_scale (querypcr - firstpcr, lastoffset - firstoffset, lastpcr - firstpcr);
So here the scaled value for querypcr is added to res. In my case, however, querypcr is smaller than firstpcr. Since the parameter is unsigned, a negative and thus extremely large positive value is passed here. gst_util_uint64_scale thus returns extremely wrong values. Why firstpct has a value of about 8460 is another matter but in my opinion gst_util_uint64_scale must only be called if querypcr > firstpcr.
Therefore I recommend to change the line like this:
if (lastpcr != firstpcr && querypcr > firstpcr) res += gst_util_uint64_scale (querypcr - firstpcr, lastoffset - firstoffset, lastpcr - firstpcr);
In my case it fixed my problem. But I would like to know your opinion about this.