This fixes a couple of issues regarding the output of (request)
per-program pads output:
We would never push out PAT sections (ok, that was one reallly stupid
mistake. I guess nobody ever uses this feature ...).
In the case where the PMT section of a program was bigger than one
packet, we would only end up pushing the last packet of that PMT. Which
obviously results in the resulting stream never containing the proper
(complete) PMT.
The problem was that the program is only started (in the base class)
after the PMT section is completely parsed. When dealing with single-program
pads, tsparse only wants to push the PMT corresponding to the requested
program (and not the other ones). tsparse did that check by looking
at the streams of the program...
... but that program doesn't exist for the first packets of the initial
PMT.
The fix is to use the base class program information (if it parsed the
PAT it already has some information, like the PMT PID for a given program)
if the program hasn't started yet.
In addition to the fact that it's a sane thing to do for multi-source
pad elements, it also avoids the situation where just using a request
pad (and not the main static pad) would result in the processing
stopping.
Assume that small backward PCR jumps are just from upstream packet
mis-ordering and don't reset timestamp tracking state - assuming that
things will be OK again shortly.
Make the threshold for detecting discont between sequential buffers
configurable and match the smoothing-latency setting on tsparse
to better cope with data bursts.
When the set-timestamps property is set, use PCRs on the provided
(or autodetected) pcr-pid to apply (or replace) timestamps on the
output buffers, using piece-wise linear interpolation.
This allows tsparse to be used to stream an arbitrary mpeg-ts file,
or to smooth jittery reception timestamps from a network stream.
The reported latency is increased to match the smoothing latency if
necessary.
It was previously a mix and match of both variants, introducing just too much
confusion.
The prefix are from now on:
* GstMpegts for structures and type names (and not GstMpegTs)
* gst_mpegts_ for functions (and not gst_mpeg_ts_)
* GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_)
* GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_)
The rationale for chosing that is:
* the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts)
* the namespace is one word under Gst
* it's shorter (yah)
* packet.origts is no longer used since the PCR refactoring done ages ago
* known_packet_size is a duplicate of packet_size != 0
* caps was never used outside of the packetizer
* Only mpeg-ts section packetization remains.
* Improve code to detect duplicated sections as early as possible
* Add FIXME for various issues that need fixing (but are not regressions)
https://bugzilla.gnome.org/show_bug.cgi?id=702724
First send stream-start, then caps, then segment.
The segment we push is from upstream in push-mode. If we work in pull-mode
then we initialize the base segment to BYTES.
https://bugzilla.gnome.org/show_bug.cgi?id=702422
tspad always has a static source pad which output everything received
(not functional yet).
Program pads are now request pads.
Remove all cruft that should have been removed from the switch over
to mpegtsbase.
Conflicts:
gst/mpegtsdemux/mpegtsparse.c
