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
Sync byte scan is incorrect for M2TS streams because the timestamp 4
bytes were not included in the flush size. This can result in an
infinite loop.
Rework the scan code to be clearer and work in all cases.
descriptors are stored as a GValueArray of GString. The downside is
that there is no way to "pass" ownership of a GValue to a GValueArray
which previously resulted in expensive copy/free of the (already expensive)
GString.
Here we estimate first the size of the GValueArray, then create it,
then directly use the GValue of that array.
Speeds up total SI parsing by ~30%
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.
Ensure the chain is not running before reset the state to avoid race
conditions and random corruptions downstream.
Also fixes segfaults in the packetizer due wrong available values that
causes gst_adapter_map to return a NULL pointer.
This reverts commit e14e310f71.
Would be better move the packetizer flushing to FLUSH_STOP and avoid
the race that way. Without introducing a memory barrier that could
have impact in the performance.
When dealing with non-time based push-mode streams, we need to revert
to using the offset-based PCR/PTS estimation logic of packetizer.
This solves uses cases such as:
pushfile:// ! tsdemux
src ! queue ! tsdemux
https://bugzilla.gnome.org/show_bug.cgi?id=687178
additional_copy_info: need to get rid of the highest
bit, not the lowest one
program_packet_sequence_counter: also need to get rid
of the highest bit instead of multiplying with a random
value
original_stuff_length: want to AND 0x3f to extract the
lowest 6 bits, not multiply by it.
None of these fields are actually used though, so these
should not have caused any issues.
