Peek as much as possible in one go. Ideally we should remove usage of
adapter altogether, but for the time being it provides a big enough
speedup (around 2 times faster per packet processed).
The overhead of creating/using 188 byte GstBuffer from GstAdapter
is too expensive.
We now peek the next packet, and provide a data/size which is only
valid until the packetizerpacket is cleared.
In addition, cleanup all the internal code to deal with that new
behaviour and remove double-checks which are no longer needed.
The section_length is now the corrected section_length (i.e. with
the additional 3 bytes).
Avoid using gst_adapter_prev_timestamp and instead track
the timestamp ourself.
Allows PCR<=>PTS<=>offset estimation/calculation
Right now the calculation is very naive, but can be extended later on
without disrupting the code in tsdemux/mpegtsbase
* Don't take into account packets that arrived at the same time as
previous ones for clock skew estimation
* Add convenience method for processing the next ts packet
This is probably the cause for an occasional crash while streaming
MPEG. Blind fix after staring at the code and following logic, so
may or may not fix the issue, I cannot test.
(Port of 4275a70cb5 from mpegdemux)
buffer timestamps are converted to GstClockTime to cover pcr/pts wraps.
multiple pcr/pts wraps are handled with an index which ensures at most
a single pcr wraparound between two entries.
the last seen pcr is recorded to have a nearby index point for short seeks
resuming playback might be delayed if the postion is not a keyframe
TODO: replace manual packet scanning and parsing in the initial duration estimation
