- Apr 18, 2014
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
- Apr 12, 2014
-
-
Coverity 1139589, 1139588
-
-
Checking the size available was incorrect, and the infos for per-pad EOS are available. Same logic as audiomixer. fixes: https://bugzilla.gnome.org/show_bug.cgi?id=727025
-
Drop the reference instead of waiting for either finalize(), or for a new source when reused. Everyone else already forgot about the old source.
-
Tim-Philipp Müller authored
The typefinder returns LIKELY for as little as one possible sync and no bad sync (not even taking into account how much data was looked at for that). It's generally just not fit for purpose, so should just not return anything like LIKELY at all ever, even more so since it only recognises one out of ten H263 files, and likes to mis-detect mp3s as H263. https://bugzilla.gnome.org/show_bug.cgi?id=700770 https://bugzilla.gnome.org/show_bug.cgi?id=725644
-
- Apr 04, 2014
-
-
Vincent Penquerc'h authored
Clock slaving can clip start time to zero, giving us a shorted duration than we originally got. To keep in sync, we must then discard the samples falling before that zero timestamp. This possibly fixes random distortion caused by constant PA underflows which are never resynced.
-
- Mar 03, 2014
-
-
This patch adds read source on the write socket in tunneled mode and we get a callback when client disconnects the GET channel. Fixes https://bugzilla.gnome.org/show_bug.cgi?id=725313
-
- Feb 28, 2014
- Feb 23, 2014
- Feb 20, 2014
-
-
Thiago Santos authored
When seeking back to original state after duration seeks, let upstream know that we want the whole file, including the last byte that wasn't requested on the duration seeks. https://bugzilla.gnome.org/show_bug.cgi?id=724633
-
- Feb 18, 2014
-
-
Sebastian Dröge authored
Otherwise there's an interesting race condition when we destroy the inputselector (actually it will be destroyed later when its state change message gets destroyed) and afterwards release its sinkpad. This is the code path when the last channel is removed from the input selector. Gave this warning sometimes, for chained oggs or whenever else we change decode groups: GStreamer-CRITICAL **: Padname '':sink_0 does not belong to element inputselector0 when removing
-
- Feb 17, 2014
-
-
Sebastian Dröge authored
If the text pads does not go away we just set the overlay to silent, which allows us to immediately re-enable subs later again. However before this change we also released the streamsynchronizer text pads, which deadlocked because there was still dataflow going on. Just do this only if we remove the complete chain. https://bugzilla.gnome.org/show_bug.cgi?id=683504
-
- Feb 11, 2014
-
-
Sebastian Dröge authored
The caps query might give us ANY caps while the pad has fixed caps configured currently.
-
- Feb 10, 2014
-
-
Sebastian Dröge authored
We should not leak element factories ideally.
-
Sebastian Dröge authored
Otherwise they would be preferred over all decoders independent of their ranks. https://bugzilla.gnome.org/show_bug.cgi?id=722316
-
-
Sebastian Dröge authored
-
- Feb 08, 2014
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
- Feb 04, 2014
-
-
Sebastian Dröge authored
-
- Jan 24, 2014
-
-
Wim Taymans authored
Make a little table of conversions and manually score them. Use this info to define better weights for the scoring algorithm. give separate scores for doing changes and the impact of the change, This allows us to avoid conversion when we can but still allow fairly lossless changes. The old code did not penalize GRAY conversions, PAL conversions were punished too low and depth conversions too high. Fixes https://bugzilla.gnome.org/show_bug.cgi?id=722656
-
Wim Taymans authored
Make dummy resamplers for all cases and only execute the horizontal resampler instead of crashing. See https://bugzilla.gnome.org/show_bug.cgi?id=722742
-
- Jan 21, 2014
-
-
Wim Taymans authored
We call the _get_time function from the provided clock and we don't lock the sink object for performance reasons. Make sure we only read and check variables once so that they don't change while we are executing the code. Fixes https://bugzilla.gnome.org/show_bug.cgi?id=720661
-
- Jan 17, 2014
-
-
Thiago Santos authored
They end up stored in the 'pending_events' list and should be freed after calling stop
-
- Jan 15, 2014
-
-
Thiago Santos authored
Check that even if the subclass doesn't call set_output_format, the base class should use upstream provided caps to fill the output caps that is pushed before the gap event is forwarded, otherwise it ends again fixating the rate and channels to 1. https://bugzilla.gnome.org/show_bug.cgi?id=722144
-
Thiago Santos authored
For default caps generation when handling gap events that are sent before any buffer, try to use caps that are closer to what upstream provided to avoid fixating rate or channels to 1 as default. So there are the steps: 1) Try to set rate, channels and channel-mask from upstream if provided 2) Fixate the rate and channels to the default rate and channels from audio lib 3) Fixate the caps just to be sure everything is fixed 4) If no channel-mask was provided and channels > 2, use a default channel-mask (taken from audioconvert code) https://bugzilla.gnome.org/show_bug.cgi?id=722144
-
A xvcontext can be created early in gst_xvimagesink_set_window_handle(). In this case don't recreate, i.e. overwrite it in gst_xvimagesink_open(). Otherwise XEvents won't be handled in the xevent listener thread. Fixes a regression when setting the window handle on the sink in the very beginning before changing its state. https://bugzilla.gnome.org/show_bug.cgi?id=715138
-
- Jan 14, 2014
-
-
Thiago Santos authored
Saves some cpu
-
Thiago Santos authored
Before trying to generate a default fixated caps when handling a gap event, make sure that the same strategy that is used when handling a buffer has been attempted. Otherwise audiodecoder will ignore upstream caps settings such as rate and channels and will likely end with a caps with channels=1 and rate=1. https://bugzilla.gnome.org/show_bug.cgi?id=722144
-
Thiago Santos authored
Adds 2 tests to verify that output caps are the expected value, reusing input structure values for both buffers and gaps https://bugzilla.gnome.org/show_bug.cgi?id=722144
-
Thiago Santos authored
Simple test that just check that audio decoding works as expected https://bugzilla.gnome.org/show_bug.cgi?id=722144
-
Vincent Penquerc'h authored
A change in gst_ogg_demux_do_seek caused oggdemux to wait for a page for each of the streams, including a skeleton stream if one was present. Since Skeleton only has header pages, that was never going to end well. Also, the code was skipping CMML streams when looking for pages, so would also have broken on CMML streams. Thus, we change the code to disregard Skeleton streams, as well as discontinuous streams (such as CMML and Kate). While it may be desirable to consider Kate streams too (in order to avoid losing a subtitle starting near the seek point), this may be a performance drag when seeking where no subtitles are. Maybe one could add a "give up" threshold for such discontinuous streams, so we'd get any page if there is one, but do not end up reading preposterous amounts of data otherwise. In any case, it is important that the code that determines the amount of streams to look pages for remains consistent with the "early out" conditions of the code that actually parses the incoming pages, lest we never decrease the pending counter to zero. This fixes seeking on a file with a skeleton track reading all the file on each seek. https://bugzilla.gnome.org/show_bug.cgi?id=719615
-
Vincent Penquerc'h authored
Ogg data is read chunk by chunk, and the chunk size used was originally taken from libvorbisfile. However, this value leads to poor performance when used on an Ogg file with large pages (Ogg pages can be close to 64 KB). We can't just use a larger chunk size, since this will decrease performance on small page streams, so we use an adaptive scheme where the chunk size is twice the largest page size we've seen so far in the stream. For "typical" Ogg/Vorbis, this gives us almost the same chunk size (a bit lower), and this lets us get better performance on streams with large pages.
-
-
- Jan 13, 2014
-
-
Thiago Santos authored
Adds a test that simulates a scenario where the first buffers after a segment can't be decoded and the decoder asks for those frames to be released. The videodecoder base class should make sure that the events attached to those first buffers are pushed even if the buffers aren't going to be. https://bugzilla.gnome.org/show_bug.cgi?id=721835
-
Thiago Santos authored
Events must be persisted after a frame is dropped to avoid losing obligatory information for the stream. https://bugzilla.gnome.org/show_bug.cgi?id=721835
-
Thiago Santos authored
Checks that buffers are pushed backwards in reverse playback https://bugzilla.gnome.org/show_bug.cgi?id=721666
-