- 25 Feb, 2016 6 commits
-
-
Tim-Philipp Müller authored
-
-
Tim-Philipp Müller authored
Move Opus RTP depayloader/payloader from -bad to -good. https://bugzilla.gnome.org/show_bug.cgi?id=756282
-
Philippe Normand authored
This is already supported for PUSH mode but was failing in PULL mode. The aux info is sometimes stored in the mdat before the first sample, so the loop task needs to pull data stored at that location and perform the aux info cenc parsing. https://bugzilla.gnome.org/show_bug.cgi?id=761700 https://bugzilla.gnome.org/show_bug.cgi?id=762516
-
Philippe Normand authored
In some cases the stream configuration can fail, for instance if the stream is protected and no decryptor was found. For those situations the demuxer shouldn't emit any data on the corresponding source pad of the stream and bail out. https://bugzilla.gnome.org/show_bug.cgi?id=762516
-
Philippe Normand authored
When the cenc metadata is stored outside of the moof box and the stream is exposed it is possible that the cenc metadata hasn't been processed yet while the first buffer is being pushed. When this happens the buffer can't possibly be decrypted downstream so don't push it. https://bugzilla.gnome.org/show_bug.cgi?id=762516
-
- 24 Feb, 2016 1 commit
-
-
- 23 Feb, 2016 10 commits
-
-
Sebastian Dröge authored
-
Dave Craig authored
Remove calls to gst_pad_has_current_caps() which then go on to call gst_pad_get_current_caps() as the caps can go to NULL in between. Instead just use gst_pad_get_current_caps() and check for NULL. https://bugzilla.gnome.org/show_bug.cgi?id=759539
-
Dave Craig authored
Remove calls to gst_pad_has_current_caps() which then go on to call gst_pad_get_current_caps() as the caps can go to NULL in between. Instead just use gst_pad_get_current_caps() and check for NULL. https://bugzilla.gnome.org/show_bug.cgi?id=759539
-
Dave Craig authored
This can happen when the pipeline is currently shutting down. https://bugzilla.gnome.org/show_bug.cgi?id=759539
-
-
-
Aurélien Zanelli authored
If we have an error during fwrite call, file stays open and thus next incoming buffer will trigger an assert when trying to opening a new file. This happens if we do not restart element, file is closed at stop, and if application handles the returned GST_FLOW_ERROR to keep bin alive. https://bugzilla.gnome.org/show_bug.cgi?id=762434
-
Matej Knopp authored
Such files will not play on Android, because of bug in libwebm matroska parsing, which is still present in 6.0.1 https://bugzilla.gnome.org/show_bug.cgi?id=762349
-
-
Vincent Penquerc'h authored
This block is needed in the Matroska file, but data coming from RTP may not have one. https://bugzilla.gnome.org/show_bug.cgi?id=761489
-
- 22 Feb, 2016 4 commits
-
-
Mark Nauwelaerts authored
... as streams are so ordered by id by e.g. decodebin (and as typically already honoured by other demuxers).
-
Mark Nauwelaerts authored
-
Luis de Bethencourt authored
VP9_PAY_PICTURE_ID_7BITS and VP9_PAY_PICTURE_ID_15BITS are mutually exclusive options of the picture-id-mode. We can break after the first case. 1 or 2 bytes need to be added to the header length depending on the PictureID size. https://tools.ietf.org/html/draft-uberti-payload-vp9-00#section-4.2 CID 1353479
-
Vineeth TM authored
buffer being mapped is not being unmapped in some cases https://bugzilla.gnome.org/show_bug.cgi?id=762420
-
- 21 Feb, 2016 2 commits
-
-
Stian Selnes authored
This is a normal scenario and should not be a warning. https://bugzilla.gnome.org/show_bug.cgi?id=762208
-
Tim-Philipp Müller authored
This hasn't been touched for generations, doesn't work, and is just causing confusion. We also don't want to maintain these files manually.
-
- 20 Feb, 2016 1 commit
-
-
Tim-Philipp Müller authored
-
- 19 Feb, 2016 13 commits
-
-
Matej Knopp authored
Instead of erroring out, just use the default color table. https://bugzilla.gnome.org/show_bug.cgi?id=761637
-
Tim-Philipp Müller authored
-
Tim-Philipp Müller authored
-
-
-
Tim-Philipp Müller authored
-
Havard Graff authored
Probably found a bug as well, in that there are some timestamps in there that are looking very wrong. (marked with FIXME) https://bugzilla.gnome.org/show_bug.cgi?id=762267
-
Havard Graff authored
Use fail_unless and friends instead of g_assert Factor seq-num checking out to separate function Check more return-values from push and crank and others https://bugzilla.gnome.org/show_bug.cgi?id=762254
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
Philippe Normand authored
-
- 18 Feb, 2016 3 commits
-
-
Tim-Philipp Müller authored
Set GSETTINGS_BACKEND=memory, apparently there's something about fork() and the dconf backend (or whatever else that drags in or activates) that messes up locking and causes timeouts due to deadlocks in g_mutex_lock(), since everything works fine with CK_FORK=no as well.
-
Sebastian Dröge authored
Otherwise it will be mapped writable all the time and we can't read from it anywhere. https://bugzilla.gnome.org/show_bug.cgi?id=762239
-
Stian Selnes authored
Make sure that the packets queued when detecting a big gap are pushed after reset (5 consective seqnums) and not dropped. https://bugzilla.gnome.org/show_bug.cgi?id=762211
-