Updating caps results in downstream elements potentially reconfiguring themselves
(such as decoders). If we do this in the middle of keyframes, we would result
in those elements being reconfigured and handling garbage until the next keyframe.
Instead of this only send (potentially) new codec_data when we have *both* SPS and
PPS.
https://bugzilla.gnome.org/show_bug.cgi?id=705333
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 :(
ATSC ac3 streams are always guaranteed to be AC3 if EAC3 descriptor
is not present
If stream registration id is 'AC-3' then it's also guaranteed to be AC3.
Finally if AC3 descriptor is present it's guaranteed to be AC3.
Only silences a warning, but still.
We know we will not overflow 64 bits, therefore just use direct
multiplication/division instead of the scale method (trims usage from
50 instruction calls to 2/3).
Helps with debugging issues. And also remove unused variable (opcr)
This will also allow us in the future to properly detect:
* random-access location (to enable keyframe observation and
potentially seeking
* discont location (to properly handle resets)
* splice location (to properly handle new stream changes)
If a buffer was entirely clipped out (ie, it's out of the segment
entirely), we'll end up with a NULL buffer, which we don't want
to process/dereference.
The new seek handling re-creates the segment time information once it
has enough information after a seek.
The problem was that we'd completely ignore the requested rate. So store
that and use it in the newly created segment.
https://bugzilla.gnome.org/show_bug.cgi?id=694369
Make videotestsrc ! interlace ! $anything work again. Problem
was that upstream filter caps were passed which contained
interlace-mode=progressive, which doesn't intersect too well
with interlace's source pad template caps, leading to
not-negotiated errors.
The program_number attribute was overloaded, trying to indicate both
the currently playing program, and the program requested via the
"program-number" property. The end result was that setting the
property didn't work (see #690934).
I added a new requested_program_number field rather than reviving the
current_program_number field because it seemed this would result in
fewer changes overall and be less confusing. It breaks symmetry with
the "program-number" property, but it retains parallels with the likes
of program->program_number.
Because gst_ts_demux_reset is called after the properties have been
parsed, requested_program_number is initialised in gst_ts_demux_init.
Whether this is exactly the right place, I don't know.
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).
