* Search in current pending values first. For CBR streams we can very
easily end up having just one initial observations and then nothing
else (since the bitrate doesn't change).
* Use one group whether we are in that group *OR* if there is only
one group.
* If the group to use isn't closed (points are being accumulated in the
PCROffsetCurrent), use the latest data available for calculation
* If in the unlikelyness that all of this *still* didn't produce more
than one data point, just return the initial offset
While the calculation done in these macros will work with 64bit
integers, they will fail if working with 32bit integers.
Force the scaling up to solve that.
This amazingly didn't introduce major issues up to now, but resulted
in bogus values in debug logs.
Doing a hard flush on the packetizer will drop all observations, which
will eventually break push-based seeking (with BYTES segment) since
we won't know where to seek to anymore (new data would always be
considered as the beginning of the stream).
While this probably should never happen if callers are well behaved,
this avoids a crash if it does. With a warning about it. Unsure if
it'd be better to not add at all, but it should not happen...
Coverity 1139713
gst_ts_demux_push_pending_data() will check if it now can activate the
stream and add the pad, we don't have to check that ourselves.
Fixes playback of very short MPEG TS files.
Apart from just adding detection of the proper stream type, we also need to only
output the first substream (0x71) which contains the core substream.
While this does not provide *full* DTS-HD support (since it will miss the complementary
substreams), it will still work in the way legacy (non-DTS-HD) bluray players would work.
https://bugzilla.gnome.org/show_bug.cgi?id=725563
Keep a list of current global tags around and push them
whenever a new stream is started. Also convert all stream
specific tags to global as they are stream specific for
the container, so they are global for the streams from
within that container.
https://bugzilla.gnome.org/show_bug.cgi?id=644395
The PAT is related to the stream, we therefore want it cleared along
with anything stream related.
This commented section was from the (old) mpegtsparse and *might* have
been related to speeding up DVB start-up. But we have another plan for that.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=724716
The requested TS might be beyond the last observed PCR. In order to calculate
a coherent offset, we need to use the last and previous-to-last groups.
https://bugzilla.gnome.org/show_bug.cgi?id=721035
The original code (old mpegtsparse) from which this plugin was based on
was dual-licensed. This allowed usage of the code under any of the
licenses (which including LGPL):
"""
* Alternatively, the contents of this file may be used under the terms of
* the GNU Lesser General Public License Version 2 or later (the "LGPL"),
* in which case the provisions of the LGPL are applicable instead
* of those above. If you wish to allow use of your version of this file only
* under the terms of the LGPL, and not to allow others to
* use your version of this file under the terms of the MPL, indicate your
* decision by deleting the provisions above and replace them with the notice
* and other provisions required by the LGPL. If you do not delete
* the provisions above, a recipient may use your version of this file under
* the terms of the MPL or the LGPL.
"""
When refactored (leading to the creation of this new plugin), I chose all
new code to be LGPL-only (which was allowed for pre-existing code) by removing
the MPL sections.
The headers were all updated, but not the plugin license field. This commit
fixes this.
It is quite possible that we might get PTS/DTS before the first
PCR/Offset observation.
In order to end up with valid timestamp we wait until at least one
stream was able to get a proper running-time for any PTS/DTS.
Until then, we queue up the pending buffers to push out.
Once we see a first valid timestamp, we re-evaluate the amount of
running-time elapsed (based on returned inital running-time and amount
of data/DTS queued up) for any given stream.
Taking the biggest amount of elapsed time, we set that on the packetizer
as the initial offset and recalculate all pending buffers running-time
PTS/DTS.
Note: The buffer queueing system can also be used later on for the
dvb fast start proposal (where we queue up all stream packets before
seeing PAT/PMT and then push them once we know if they belong to the
chosen program).
This allows:
* Better duration estimation
* More accurate PCR location
* Overall more accurate running-time location and calculation
Location and values of PCR are recorded in groups (PCROffsetGroup)
with notable PCR/Offset observations in them (when bitrate changed
for example). PCR and offset are stored as 32bit values to
reduce memory usage (they are differences against that group's
first_{pcr|offset}.
Those groups each contain a global PCR offset (pcr_offset) which
indicates how far in the stream that group is.
Whenever new PCR values are observed, we store them in a sliding
window estimator (PCROffsetGroupCurrent).
When a reset/wrapover/gap is detected, we close the current group with
current values and start a new one (the pcr_offset of that new group
is also calculated).
When a notable change in bitrate is observed (+/- 10%), we record
new values in the current group. This is a compromise between
storing all PCR/offset observations and none, while at the same time
providing better information for running-time<=>offset calculation
in VBR streams.
Whenever a new non-contiguous group is start (due to seeking for example)
we re-evaluate the pcr_offset of each groups. This allows detecting as
quickly as possible PCR wrapover/reset.
When wanting to find the offset of a certain running-time, one can
iterate the groups by looking at the pcr_offset (which in essence *is*
the running-time of that group in the overall stream).
Once a group (or neighbouring groups if the running-time is between two
groups) is found, once can use the recorded values to find the most
accurate offset.
Right now this code is only used in pull-mode , but could also
be activated later on for any seekable stream, like live timeshift
with queue2.
Future improvements:
* some heuristics to "compress" the stored values in groups so as to keep
the memory usage down while still keeping a decent amount of notable
points.
* After a seek compare expected and obtained PCR/Offset and if the
difference is too big, re-calculate position with newly observed
values and seek to that more accurate position.
Note that this code will *not* provide keyframe-accurate seeking, but
will allow a much more accurate PCR/running-time/offset location on
any random stream.
For past (observed) values it will be as accurate as can be.
For future values it will be better than the current situation.
Finally the more you seek, the more accurate your positioning will be.
The previous code could enter an infinite loop because the adapter state
could get out of sync with its mapped data state after sync was lost.
The code was pretty confusing so it's been rewritten to be clearer.
The easiest way to reproduce the infinite loop is to use the breakmydata
element before tsdemux to trigger a resync.
https://bugzilla.gnome.org/show_bug.cgi?id=708161
Some streams had wrong values for the stream_id_extension, make sure
we only remember the valid ones.
For streams with PES_extension_field_length == 0, assume there's nothing
else.
For streams that state they have a TREF extension but don't have enough
data to store it, just assume it was produced by a non-compliant muxer
and skip the remaining data.
Only store remaining data in stream_id_extension_data instead of storing
data we already parse.
If ever we lose sync, we were just checking for the next 0x47 marker ...
which might actually happen within a mpeg-ts packet.
Instead check for 3 repeating 0x47 at the expected packet size interval,
which the same logic we use when we initially look for the packet size.
We were only resetting the first 512 values of the lookup table instead
of the whole 8192.
This resulted in any PCR PID over 0x0200 ... ending up taking the first PCR
table around :(
