- Jan 30, 2017
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
-
- Jan 25, 2017
-
-
- Jan 18, 2017
-
-
Sebastian Dröge authored
There was already a check for that, but it failed because subformat_guid[0] is a guint32 and that is then casted implicitely to a guint16 when recursing... just that we checked the uncasted value. This caused an infinite recursion and thus stack overflow. https://bugzilla.gnome.org/show_bug.cgi?id=777265
-
- Jan 16, 2017
-
-
Sebastian Dröge authored
Otherwise we might divide by zero or otherwise create invalid caps. https://bugzilla.gnome.org/show_bug.cgi?id=777262
-
Sebastian Dröge authored
video-converter: Fix crashes in fast-paths when converting interlaced formats with different vertical subsampling E.g. the following pipelines fail because chroma values after the last line are read (note: 486 % 4 == 2): gst-launch-1.0 videotestsrc ! "video/x-raw,interlace-mode=interleaved,width=720,height=486,format=UYVY" ! videoconvert ! "video/x-raw,format=I420" ! fakesink gst-launch-1.0 videotestsrc ! "video/x-raw,interlace-mode=interleaved,width=720,height=486,format=I420" ! videoconvert ! "video/x-raw,format=UYVY" ! fakesink gst-launch-1.0 videotestsrc ! "video/x-raw,interlace-mode=interleaved,width=720,height=486,format=I420" ! videoconvert ! "video/x-raw,format=AYUV" ! fakesink
-
- Jan 10, 2017
-
-
Thibault Saunier authored
-
- Jan 09, 2017
-
-
When operating on framerates near 10000fps, at least keep 1 digit of precision for calculations
-
Avoiding trying to use NULL pointers
-
... as a sinkpad need not be called "sink", and it is not the case for e.g. timeoverlay (and friends). Fixes https://bugzilla.gnome.org/show_bug.cgi?id=776623
-
-
This way special characters such as '@' can be used in usernames or passwords, e.g. rtsp://view:%40dm%4An@<IP-ADDR>/media/camera1 will now parse username and password into: User: view Pass: @DM:n https://bugzilla.gnome.org/show_bug.cgi?id=758389
-
Make sure ticks start with an accumulator value of 0 by incrementing it after filling in samples instead of before and by resetting the accumulator every time a tick begins. This prevents it from being discontinuous at the beginning of the tick. https://bugzilla.gnome.org/show_bug.cgi?id=774050
-
This ensure that XInitThreads is called and so gl contexts are properly initialized. https://bugzilla.gnome.org/show_bug.cgi?id=776403
-
- Dec 22, 2016
-
-
When plugging and then exposing a parser, don't fail if it fails to send sticky events. The most likely reason is that things were flushed due to the app immediately doing a seek, but we can't detect flushing separately to other error conditions without a gst_pad_send_event_full() core function that returns a GstFlowReturn.
-
Sebastian Dröge authored
There are cases when there is no demuxer involved that could do the buffering, e.g. HLS with raw MP3 or AAC. In this case we want to place the buffering multiqueue after the parser. Before this change, we've considered the first element after the adaptive streaming demuxer as a parser. This is not always true, e.g. id3demux. Instead we now wait until we actually have a parser (or decoder). Fixes playback on such HLS streams.
-
- Dec 13, 2016
-
-
- Dec 09, 2016
-
-
Jan Schmidt authored
When frames claim to have a footer, ensure they are large enough to contain one to avoid an invalid read overrun. Spotted by Joshua Yabut
-
- Dec 07, 2016
-
-
Sebastian Dröge authored
Ensure that nothing is in any of the streaming thread functions anymore when going from PAUSED to READY. While the parent's state change function has deactivated all pads, there is nothing preventing downstream from activating our srcpad again and calling the getrange() function. Although we're in READY! https://bugzilla.gnome.org/show_bug.cgi?id=775687
-
- Dec 05, 2016
-
-
Using the max 120 ms buffer size to ensure we have enough space for decoded data meant that Opus could actually return 120 ms' worth of data. https://bugzilla.gnome.org/show_bug.cgi?id=771723
-
Always supply a buffer with max size to the decoder, as we can't really decide how many samples will be in the lost packet based on the timestamps we get. https://bugzilla.gnome.org/show_bug.cgi?id=771723
-
This fixes missing audio when we get buffers with zero duration, denoting unknown duration. When several such buffers are received in a row, they're all at the same timestamp, with zero duration. https://bugzilla.gnome.org/show_bug.cgi?id=771723
-
If a client gets dropped and the iteration gets restarted, bufpos is incremented again for all clients that preceded the dropped one, causing havoc. Adjust the bufpos for all clients first before trying to drop any. https://bugzilla.gnome.org/show_bug.cgi?id=774908
-
max_buffer_usage is the index of the oldest buffer in the queue, starting at zero, not the number of buffers queued. find_limits returns the index of the oldest buffer that satisfies the limits in its min_idx parameter, not the number of buffers needed. Fix this use too in order to keep passing the tests that read buffers-queued. https://bugzilla.gnome.org/show_bug.cgi?id=775351
-
-
Sebastian Dröge authored
If getting multiple caps events. https://bugzilla.gnome.org/show_bug.cgi?id=775480
-
- Nov 29, 2016
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
- Nov 28, 2016
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
We're not going to get a buffer or GAP event anymore after EOS and would wait forever otherwise.
-
Sebastian Dröge authored
The caps might not be fixated (which is required by GstVideoInfo) and we would assert otherwise. However the caps often contain useful information in the already-fixed parts that we can use here.
-
- Nov 26, 2016
-
-
Sebastian Dröge authored
Otherwise we'll get a g_critical() before erroring out cleanly on https://samples.mplayerhq.hu/A-codecs/ATRAC3/SND0.AT3
-
- Nov 24, 2016
-
-
-
For drop-frame timecodes, the nsec_since_daily_jam doesn't necessarily directly correspond to this many hours/minutes/seconds/frames. We have to get the frame count as per frames_since_daily_jam and then convert. https://bugzilla.gnome.org/show_bug.cgi?id=774585
-