EAC3 bit streams shall be identified with a stream_type value of 0x87 when
transmitted as PES streams conforming to ATSC-published standards. It is specified
in ATSC Standard A/52.
https://bugzilla.gnome.org/show_bug.cgi?id=770528
When draining a program, we might send a newsegment event on the pads
that are going to be removed (and then the pending data).
In order to do that, calculate_and_push_newsegment() needs to know
what list of streams it should take into account (instead of blindly
using the current one).
All callers to calculate_and_push_newsegment() and push_pending_data()
can now specify the program on which to act (or NULL for the default
one).
A simple fix for the problem of creating new pads with duplicate
names when switching program, easier than the alternative of
trying to work out which pads might persist and manage that.
See https://bugzilla.gnome.org/show_bug.cgi?id=758454
When the sub-class claims a program for later freeing, make
sure it's not left in the hash table, or it can cause crashes on shutdown.
Make sure tsdemux frees any program it has kept around at shutdown
if it wasn't freed already.
https://bugzilla.gnome.org/show_bug.cgi?id=763503
The order in which program switch must happen is:
1) drain all data on old pads (but don't push EOS)
2) add new pads (but don't push any data on them)
3) Push EOS and remove old pads
4) Start pushing data on new pads
There was one caveat in this implementation, which is that when
we activate a sparse pad (step 2) we would push a GAP event. The problem
is that, while being an event, it is actually *data*.
We therefore need to make sure pushing those GAP event is done at the step
we start pushing data.
https://bugzilla.gnome.org/show_bug.cgi?id=750402
Before we add any streams, make sure we drain all streams. This ensures
there's consistency that only "new" data will be pushed on buffers once
the new pads are added
https://bugzilla.gnome.org/show_bug.cgi?id=750402
When changing programs, the order of events needs to be the following:
* add pads from new program
* send EOS on old pads
* remove old pads
* emit 'no-more-pads'
Previously tsdemux was not doing that, and was first deactivating and
removing old pads before adding new ones.
We fix this by allowing subclasses of mpegtsbase to be able to handle
themselves the deactivation of programs. In this case tsdemux will
properly deactivate it once it has activated the new program.
https://bugzilla.gnome.org/show_bug.cgi?id=750402
The values of channel_mapping are copied by gst_codec_utils_opus_create_caps ()
but it doesn't free or take ownership of the g_new0 allocated memory. This
needs to be freed before going out of scope.
CID 1338692
If tsdemux never receives data for a stream, the corresponding pad will never
be added and stream->active will remain FALSE. When the stream is removed, the
pad will not be unreffed and will be leaked.
https://bugzilla.gnome.org/show_bug.cgi?id=757873
The tsdemux latency should always be added to the minimum
latency (which is always a valid clock time value). The
"cleanup" in commit a1f709c2 made it so that it would not
be added if upstream reported 0 as minimum latency (as
e.g. udpsrc would). This broke playback of live mpeg-ts
streaming in some cases, leading to playback stutter due
to a too-small configured latency for the pipeline.
https://bugzilla.gnome.org/show_bug.cgi?id=751508
The segment should start at first PTS, and the vairable name lower_pts
state so correctly. Though we where using the first DTS instead. This
could lead to small desynchronization of video stream.
https://bugzilla.gnome.org/show_bug.cgi?id=740575
Chinese broadcaster encapsulate AVS video codec into MPEG2-TS. They
use the stream_id 0x42 to identify AVS video streams. It should be noted
that this id is currently within the ISO reserved range, hence it's
utilisation is unofficial.
https://bugzilla.gnome.org/show_bug.cgi?id=727731
Timestamps should start at the segment start, rather than 0, so
we need to not subtract the first timestamp. This makes the sink
correctly account for running time when switching PMTs where a
stream starts not quite at zero, causing timing offsets that can
become noticeable and causing dropped frames after a few times.
If the stream which is about to be removed still has a ref on a tag list we
should drop it.
Fix a leak which was occasionally happening with the
validate.file.playback.change_state_intensive.tron_en_ge_aac_h264_ts scenario.
https://bugzilla.gnome.org/show_bug.cgi?id=748576
Such seeks are used to change playback rate and we do not want
to alter the position in that case, so we bypass the flush/seek
logic, and set things up so a new segment is scheduled to be
regenerated.
https://bugzilla.gnome.org/show_bug.cgi?id=735100
This will happen when the PMT changes, replacing streams with
new ones. In that case, we need to accumulate the running time
from the previous chain in the segment base.
https://bugzilla.gnome.org/show_bug.cgi?id=745102
Always update the segment and not only for accurate seeking and always
send a new segment event after seeks.
For non-accurate force a reset of our segment info to start from
where our seek led us as we don't need to be accurate
https://bugzilla.gnome.org/show_bug.cgi?id=743363
The flush is called on discont and we shouldn't output a new segment
each time a discont happens. So this commit remove the mark for a new
segment when flushing streams by propagating the 'hard' flag passed
on the flusing from the base class.
https://bugzilla.gnome.org/show_bug.cgi?id=743363
Signal sparse streams properly in stream-start event and force sending
of pending sticky events which have been stored on the pad already and
which otherwise would only be sent on the first buffer or serialized
event (which means very late in case of subtitle streams). Playsink in
playbin waits for stream-start or another serialized event, and if we
don't do this it will wait for the multiqueue to run full before
starting playback, which might take a couple of seconds.
https://bugzilla.gnome.org/show_bug.cgi?id=734040
All pads of a stream are now added at the beginning. In order to cope with
streams that don't get any data (forever or for a long time) we detect gaps
and push out GAP events when needed.
Cleanups and commenting by Jan Schmidt <jan@centricular.com>
https://bugzilla.gnome.org/show_bug.cgi?id=734040
If a discontinuity in the stream is detected, data is discarded until
a new PES starts. If the first packet after the discontinuity is also
the start of a PES, there is no reason to discard the packets.
https://bugzilla.gnome.org/show_bug.cgi?id=737569
