It was originally test for 9 bytes (as the comment says) and was
rewritten buggily. So rewrite it a third way, which is now
hopefully consistent with the original and the comment, while
being more sense-making to humans.
Coverity 1139654
Turns out glib aborts on allocation failure, so this is pointless.
We'll just ignore Coverity warnings on such constructs.
This reverts commit d347809a82.
So this is actually pointless. We'll just have to ignore
Coverity moaning on those.
Revert "mpegts: test for allocation failure"
This reverts commit 224cb81b8f.
While it's unlikely to get there, it silences the coverity warning
on the error code path that we test for NULL before freeing, when
all branches there are from locations where pmt cannot be NULL,
and removing the NULL check makes the code more vulnerable to a
hypothetical future branch from somewhere where it can be.
Coverity 1139852
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
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
While the code that creates the object sets priv to some existing
pointer after new, this ensures any future new not doing this will
hit the various priv!=NULL asserts in the code.
Coverity 1139935
Recent refactoring causes this code to be called with either a NULL
fragment, or a non NULL fragment. In the former case, we don't have
a buffer. In the latter case, the original code dealing with DISCONT
assumed the buffer was valid. Testing for a NULL buffer here thus
does not seem to change the intent, and fixes:
Coverity 1195147
As the relevant variables are initialized to 0/NULL, we can loop
over the full range and make sure we free partial allocations
when an error happens partway through initialization.
Turns out there was the same issue as with subtitles.
There is space for a single audio stream, but up to 255
may be used based on a uint8_t value in a struct, which may
or may not be read from the (untrusted) data.
A comment in ifo_types.h says this value is either 0 or 1, so
we can ensure this here without drawbacks.
Coverity 1139585
There is space for a single subtitle stream, but up to 255
may be used based on a uint8_t value in a struct, which may
or may not be read from the (untrusted) data.
A comment in ifo_types.h says this value is either 0 or 1, so
we can ensure this here without drawbacks.
Coverity 1139586
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.
There is a small chance that we might end up in the done step without
having any output available.
Furthermore, when going through not_ready, we need to ensure gst_buffer_unmap
has a properly initialized GstMapInfo.
CID #1139923
CID #1139924
CID #1139919
CID #1139920
