- Mar 28, 2018
-
-
Tim-Philipp Müller authored
- Mar 17, 2018
-
-
We need at least 17 bytes of data for a valid flac header oss-fuzz #6974
-
- Mar 01, 2018
-
-
Nicolas Dufresne authored
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
-
- Feb 14, 2018
-
-
Nicolas Dufresne authored
-
Nicolas Dufresne authored
-
Nicolas Dufresne authored
-
Nicolas Dufresne authored
-
- Feb 13, 2018
-
-
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
-
- Jan 26, 2018
-
-
Tim-Philipp Müller authored
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
-
- Jan 17, 2018
-
-
If width or height are zero ... there's no video :)
-
(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.
-
- Dec 15, 2017
-
-
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
-
- Dec 07, 2017
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
The furthest we go to verify the data is reading a guint32 at offset 18, therefore make sure we can read as much.
-
- Dec 06, 2017
-
-
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
-
- Dec 05, 2017
-
-
- Dec 01, 2017
-
-
Thibault Saunier authored
-
-
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.
-
-
Edward Hervey authored
We already NULL-ended the string, don't use the bogus cur_size
-
We're also checking the byte after the WEBVTT magic.
-