Setting the program-number property does not affect which program
is actually being demuxed.
Moving the initialization of the program_number from
gst_ts_demux_reset to gst_ts_demux_init seems to fix this issue.
https://bugzilla.gnome.org/show_bug.cgi?id=690934
* Avoids handling twice the same seek (can happen with playbin and files
with subtitles)
* Set the sequence number of the segment event to the sequence number of
the seek event that generated it (-1 for the initial one).
The seeking start time is approximated from the seek offset in bytes
using the accumulated PCR observations, so on a VBR stream there might
be a big difference between the actual PCR and the estimated one after
the seek. This might result in a long wait to skip all out of segments
packets.
Instead we just recalculate the new segment to start at the first PTS
after the seek, so that playback starts immediatly.
Until now we simply ignored those streams (since we couldn't do anything
with it anyway). Now that we have the mpegts library and we offload the
section handling to the application side we can properly identify and
extract them.
By default it is disabled for tsparse and enabled for tsdemux, but there is
a property to change that.
This should open the way to properly handle all private section streams,
including:
* DSM-CC
* MHEG
* Carousel data
* Metadata streams (though I haven't seen any of those in the wild)
* ... And all other specs/protocols making use of those
Partially fixes#560631
We still have some other stream types which haven't been ported, but
we will do so once we have defined the enums in the mpegts library.
Also add some FIXMEs regarding items discovered during analysis
* 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
Since there is a conflict between the DCII stream type and BluRay
stream types, moved the processing of BluRay-specific stream types
to the beginning of the function. Only if a BluRay stream type
IS NOT found do we proceed to check the rest of the stream type
identifiers
Previous code was also "sort-of" handling a similar conflict between
BluRay AC3 audio and standard AC3 audio. Moved the special case BluRay
AC3 handling in the main switch statement to the new BluRay-specific
switch.
https://bugzilla.gnome.org/show_bug.cgi?id=697892
And if we detect a discontinuity there (like... when losing packets
or having MPEGTS over raw UDP with out-of-order packets) we just
drop the corresponding packet.
A future version could try to implement a re-ordering algorithm based
on that, similar to what rtpjitterbuffer does.
Also reset segment info and drop the segment event when demuxer is
flushed.
Restore demuxer segment with the info stored in base when demuxer is
going to push data again if needed.
Drop code to recover the segment info from base in the initial program
becauses it's superseded by the new code.
Avoids consistently failing to detect that a packet is complete, which
would then only be pushed upon the start of a next packet, which leads
to quite a delay in case of a sparse (subtitle) stream.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=666674
Data should not be flushed out of the tsdemux because a payload unit start
indicator (pusi) is seen in a adaptation only ts packet. If the package contains no
payload a pusi does not indicate a new PES packet, but PSI information, etc.
This fixes playback of several TS files which contain ts packets without
payload but with pusi set to 1.
https://bugzilla.gnome.org/show_bug.cgi?id=676168
When the PES header tells us how big the outgoing packet is, push the
packet downstream as soon as we have the specified size instead of waiting
for the beginning of the next packet.
Reduces latency and removes issues with very sparse streams (like subtitles
and subpictures).
If we *really* can't figure out the first start position, that most
likely means the data to push out doesn't have any timestamp.
Use a default value of 0 then
When removing the current program, it will get freed by the
hash table removal callback, so ensure we clear our pointer
to it.
Fixes a crash later on in gst_ts_demux_push trying to access it.
https://bugzilla.gnome.org/show_bug.cgi?id=656927
When a program is changed, stream_added is called which sets the
need_newsegment to TRUE, then stream_removed is called, which calls
the flush_pending_data, which checks for the newsegment and causes
it to send a new-segment.
We must not send the newsegment when flushing the pending data on the
removed stream. We should only push it when flushing data on the newly
added streams (after they finish parsing their PTS header)
If a program/stream is changed, then a newsegment is sent which must
not be the same as the base segment since it happens later. We must
shift the start position by the time elapsed since the newsegment
and the current PTS of the stream
The program_stopped vmethod was called before stream_removed vmethod
was being called. Since we only did stream-related operations in there,
we just remove the program_stopped vmethod and do everything in the
stream_removed one.
Also, make sure we flush out all pending data before sending EOS.
We first activate new streams before shutting down old ones.
We emit no-more-pads after we add new streams and emit EOS before
removing old ones.
Also cleanup/refactor a bit more of the code accordingly
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
