Co-Authored by: Thibault Saunier <tsaunier@gnome.org>
From a high level perspective, the new process for seeking h264
streams is as follows:
1) Rewind the stream until we find the first I-slice of a frame,
and mark its offset in the stream.
2) Rewind the stream until we find SPS and PPS informations,
to make sure the subsequent parser is up to date.
3) Accumulate optionnal SEI NAL units on the way.
4) Push the SPS, PPS and SEI units before the new keyframe.
https://bugzilla.gnome.org/show_bug.cgi?id=675132
This should always be set for valid files when we get there,
and checking this avoids having ad hoc checks further down
in several places.
Coverity 1139698
If _set_current_pcr_offset gets called after a flushing seek, we ended
up using the current group for delta calculation ... whereas we should
be using the first group to calculate shifts.
Also add an early exit if there are no changes to apply
When working in push mode, we need to be able to evaluate the duration
based on a single group of observations.
To do that we use the current group values
When handling the PTS/DTS conversion in new groups, there's a possibility
that the PTS might be smaller than the first PCR value observed, due to
re-ordering.
When using the current group, only apply the wraparound correction when we
are certain it is one (i.e. differs by more than a second) and not when it's
just a small difference (like out-of-order PTS).
https://bugzilla.gnome.org/show_bug.cgi?id=731088
When we receive sticky events from upstream, always return TRUE.
Fixes the issue where we receive custom sticky events (such as "uri")
and no pads are created yet.
Since all the other timestamp tracking now gets reset on a discont,
it makes sense to wait for a PCR and timestamp buffers like when
playback first starts
(same as 744c58d71b but for the
position query)
It was only querying in time, but then trying to use dead bytes
to time conversion code.
Coverity 1139677
(Identical to commit 612cdeec80 which
was for resindvd)
When we'd see an unknown stream type, then a SDDS stream.
Then we'd get to the end of the switch with a NULL temp stream
pointer, and dereference it.
Coverity 1139708
Due to mpegts streaming nature some pads are created but are only added
later to the element. This can cause a scenario where the first stream
doesn't have an available decoder (while the next ones still pending
would have) and tsdemux will fail with not-linked as the first stream
added wouldn't be linked.
To avoid this tsdemux needs to add pads to the flowcombiner
when they are created instead of only when adding them to the
element.
gstfreeverb.c:781:29: error: using integer absolute value function 'abs' when
argument is of floating point type [-Werror,-Wabsolute-value]
if (abs (out_l2) > 0 || abs (out_r2) > 0)
They are very confusing for people, and more often than not
also just not very accurate. Seeing 'last reviewed: 2005' in
your docs is not very confidence-inspiring. Let's just remove
those comments.
This should not harm regular files, since those are the last 4 bytes of
a normal file.
This allows to handle playback of concatenated mpeg-ps files. Seeking and
duration reporting is still wrong though.
Testing mpegversion when mpegaudioversion was likely meant.
Similar tests in sys/androidmedia/gstamcaudiodec.c also test
mpegaudioversion with the same conditional code.
Coverity 206071
This component is dereferenced, and later code checking for
NULL in particular cases implies it can be NULL. This likely
does not fix the coverity warning as it was seeing another
path setting component to NULL explicitely, but this was
spotted by looking at:
Coverity 1139736
Which is actually OK from what I can see since the actual
dereference of the explicit NULL pointer will not happen
if the condition that led to the NULL pointer assignment
is met, since the assignment and defeference have mutually
exclusive tests.
Detect resolution changes on key frames, and propagate the resulting
caps to the src pad. Only the uncompressed data chunk is decoded, so
avoid using the new VP8 bitstream parsing library for now.
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Avoid possible division-by-zero while deriving the presentation timestamp
of the buffer. The base class will take care of any interpolation needs.
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
* Search in current pending values first. For CBR streams we can very
easily end up having just one initial observations and then nothing
else (since the bitrate doesn't change).
* Use one group whether we are in that group *OR* if there is only
one group.
* If the group to use isn't closed (points are being accumulated in the
PCROffsetCurrent), use the latest data available for calculation
* If in the unlikelyness that all of this *still* didn't produce more
than one data point, just return the initial offset
While the calculation done in these macros will work with 64bit
integers, they will fail if working with 32bit integers.
Force the scaling up to solve that.
This amazingly didn't introduce major issues up to now, but resulted
in bogus values in debug logs.
Doing a hard flush on the packetizer will drop all observations, which
will eventually break push-based seeking (with BYTES segment) since
we won't know where to seek to anymore (new data would always be
considered as the beginning of the stream).
Turns out glib aborts on allocation failure, so this is pointless.
We'll just ignore Coverity warnings on such constructs.
This reverts commit d347809a82.
While this probably should never happen if callers are well behaved,
this avoids a crash if it does. With a warning about it. Unsure if
it'd be better to not add at all, but it should not happen...
Coverity 1139713
While it will probably not trigger, it should silence a Coverity
warning about the fail code path testing for NULLness before
freeing, where the buffer was already dereferenced. It seems
safest to keep that test, in case future goto fail statements
happen to have a NULL buffer there.
Coverity 1139851
Fixes multiple seeking issues. When doing ACCURATE or normal
non-KEYUNIT seeks, mxfdemux would just send data from the
edit unit that covered the seek position, whether that's
a keyframe or not. Decoders would only output things from
the next keyframe then, which means there's a gap between
the start of the segment and the first decoded data in
some cases. In combination with gst-editing-services this
might result in a frozen picture for the duration of that
gap at the beginning (if videorate fixes up the first
buffer's start timestamp to cover the entire gap), or
a black frame (if no videorate is used and videomixer
fills the gap). Also fixes A/V sync issue when requesting
a KEYUNIT seek.
