| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
We need at least 17 bytes of data for a valid flac header
oss-fuzz #6974
|
|
This fixes playbin gapless playback. An ancient QoS time was used and
would lead to all frames being dropped.
https://bugzilla.gnome.org/show_bug.cgi?id=668995
|
|
The various id3v2 specs handle the extended header sizes differently
(because hey, it wouldn't be fun otherwise).
http://id3.org/id3v2.3.0 states:
"Where the 'Extended header size', currently 6 or 10 bytes, excludes
itself."
http://id3.org/id3v2.4.0-structure states:
Extended header size 4 * %0xxxxxxx
Number of flag bytes $01
Extended Flags $xx
Where the 'Extended header size' is the size of the whole extended
header, stored as a 32 bit synchsafe integer. An extended header can
thus never have a size of fewer than six bytes.
So in id3v2.4.0 it's the *whole* extended header size (a-la ISOBMFF
atom), whereas in id3v2.3.0 it's the extended header size *excluding*
those 4 initial bytes.
And for other versions, god knows..
Fixes regression introduced in commit da607005.
https://bugzilla.gnome.org/show_bug.cgi?id=792983
|
|
Fixes:
gst-launch-1.0 audiotestsrc ! audio/x-raw, format=U32BE ! \
audioconvert ! autoaudiosink
|
|
|
|
|
|
|
|
|
|
If new headers arrive after we are initialized, we need to make
sure that they are indeed valid.
A vorbis bitstream always begins with three header packets and must
be in order.
Also some streams have unframed (invalid?) headers that might
confuse and disrupt the decoding process.
Therefore if ever we see new headers, we accumulate them and once
we get a non-header packet we check them to make sure that:
* We have at least 3 headers
* They are the expected ones (identification, comments and setup)
* They are in order
* Any other "header" is ignored
If those conditions are met, we reset and reconfigure the decoder
https://bugzilla.gnome.org/show_bug.cgi?id=784530
|
|
With playbin the last subtitle chunk would not get displayed
if the last chunk was missing a newline at the end. This is
because streamsynchronizer will hold back the EOS event until
the audio and video streams are finished too, so subparse
would never forcefully push out the last chunk until the very
end when it is too late.
We get a STREAM_GROUP_DONE event from streamsynchronizer however,
so handle that like EOS and force out any remaining text then.
https://bugzilla.gnome.org/show_bug.cgi?id=771853
|
|
If width or height are zero ... there's no video :)
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=789358
|
|
(yes, this has never worked since it was introduced, don't worry)
If we want to actually detect layer/channels/samplerate changes,
it would be better to:
* not reset the various prev_* variables at every iteration.
* and actually store the values when they change
CID #206079
CID #206080
CID #206081
|
|
Encoder names should be valid utf-8, if not just ignore them
|
|
The qt typefinder uses guint64 values for offset and size calculation
but the typefinder system only supports gint64 values.
Make sure we don't end up using potentially overflowing values.
|
|
The qt typefinder uses guint64 values for offset and size calculation
but the typefinder system only supports gint64 values.
Make sure we don't end up using potentially overflowing values.
|
|
select-stream event
If select-stream event was send to playbin3 as missing any GstStream of ES type
(V or A or TEX) of collection then, playbin will access to invalid address of
GstStream due to invalid index limit. This caused SIGSEGV.
https://bugzilla.gnome.org/show_bug.cgi?id=791638
|
|
|
|
|
|
The furthest we go to verify the data is reading a guint32 at offset
18, therefore make sure we can read as much.
|
|
Fix unused variable build error if HAVE_XSHM is undefined
https://bugzilla.gnome.org/show_bug.cgi?id=790329
|
|
the fourcc might not contain printable characters, use the convenience
macro to turn it into a printable fourcc, like it's done in
gstogmparse
|
|
|
|
|
|
|
|
n_frames could end up being quite big (potentially up to G_MAXINT64). Which
would result in overflowing 64bits when multiplying it by GST_SECOND.
Instead move GST_SECOND to the num argument
|
|
|
|
If we are going to return a (potentially) 64bit integer, don't use
a 32bit one for calculation, otherwise we could end up exceeding
the maximum size of a 32bit int.
|
|
Don't use granuleshift if it wasn't set
|
|
Needs to be cast to the target type
|
|
Cast value to target type
|
|
Cast value to target type
|
|
For stream mappers that don't set a specific granuleshift, it will
have the default value of -1.
Protect the code for that and return the granule value as-is
|
|
Only valid values are -1, 0 or positive values. Anything else is
most likely corrupted data streams
|
|
Invalid input files do not warrant assertions. Instead
output error messages and let the error bubble up.
|
|
|
|
We already NULL-ended the string, don't use the bogus cur_size
|
|
We're also checking the byte after the WEBVTT magic.
|
|
Instead of trying to get the size of a NULL buffer :)
|
|
In the same way we check before whether the content of the tag
is UTF-8
|
|
in push-mode we only can track time (or most operations on streams
for that matter) if the underlying GstOggMap was properly initialized.
|
|
Since the default value of a GstOggPad.map.map was 0 ... we would
end up using wrong functions from mappers() if the stream wasn't
initialized yet.
Instead of that, use a default blank/empty first entry.
|
|
The clamping of the fraction denominator was bogus (it needs to
be >0)
|
|
In some corner cases we end up with the building chain not being
properly tracked (and therefore not properly freed).
Add a FIXME so it can later be fixed, but for now just fix the leak
|
|
Don't leak the vendor_string on error cases
|
|
|
|
gst_rt[c]p_buffer_new_copy_data()
|
|
|
