- Nov 06, 2014
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
Tim-Philipp Müller authored
Fixes 'make check' on debian powerpc32 buildbot: libs/libsabi.c:95:26: fatal error: struct_ppc32.h: No such file or directory
-
- Oct 24, 2014
-
-
This gives control to the notify function allowing it to finish other watch related functionality. https://bugzilla.gnome.org/show_bug.cgi?id=737752
-
Also we get a GstSample, not a GstBuffer here.
-
Fix error code for audio decoder
-
-
- Oct 14, 2014
-
-
Sebastian Dröge authored
This was never reset when going from PAUSED->READY and resulted in encoders being not reusable after EOS. They just rejected any buffer because they received EOS in their previous life. The flag wasn't used anywhere except for rejecting buffers after EOS, and this is now handled by GstPad directly.
-
vorbis_reorder_map is defined for eight channels max. If we have more than eight channels, it's the application which shall define the order. Since we set audio position to none, we just interleave all the channels without any particular reordering. https://bugzilla.gnome.org/show_bug.cgi?id=737742
-
Otherwise, frame is leaked. https://bugzilla.gnome.org/show_bug.cgi?id=737706
-
When playing chained data the audio ringbuffer is released and then acquired again. This makes it reset the segbase/segdone variables, but the next sample will be scheduled to play in the next position (right after the sample from the previous media) and, as the segdone is at 0, the audiosink will wait the duration of this previous media before it can write and play the new data. What happens is this: pointer at 0, write to 698-1564, diff 698, segtotal 20, segsize 1764, base 0 it will have to wait the length of 698 samples before being able to write. In a regular sample playback it looks like: pointer at 677, write to 696-1052, diff 19, segtotal 20, segsize 1764, base 0 In this case it will write to the next available position and it doesn't need to wait or fill with silence. This solution is borrowed from pulsesink that resets the clock to start again from 0, which makes it reset the time_offset to the time of the last played sample. This is used to correct the place of writing in the ringbuffer to the new start (0 again) https://bugzilla.gnome.org/show_bug.cgi?id=737055
- Sep 24, 2014
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
- Sep 23, 2014
-
-
Reset last_timestamp_out when applying the output segment change, to avoid decoder confusion over new timestamp timelines when a seamless segment change happens. Move some locks/unlocks to later when they're actually needed. https://bugzilla.gnome.org/show_bug.cgi?id=734617
-
Tim-Philipp Müller authored
Don't try to set port attribute that's not advertised by the adaptor. Fixes videotestsrc ! xvimagesink aborting with X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 151 (XVideo) Minor opcode of failed request: 13 () on intel HD4600 graphics with kernel 3.16, xserver 1.15, intel driver 2.21.15.
-
- Sep 19, 2014
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
- Sep 18, 2014
-
-
Thiago Santos authored
The allocation query failure doesn't mean that the negotiation has failed as the element can allocate buffers itself. Instead, only fail if the pads are flushing and the allocation query failed. https://bugzilla.gnome.org/show_bug.cgi?id=735844
-
Arnaud Vrac authored
-
Arnaud Vrac authored
-
Arnaud Vrac authored
The source pad might be flushing while negotiating, resulting in set_caps or the ALLOCATION query failing. In this case set the reconfigure flag on the source pad so that negotiation is retried on the next buffer.
-
- Sep 17, 2014
- Sep 16, 2014
-
-
Sebastian Dröge authored
audioresample and videoscale is something the application will have to do if required, but we can at least help here by adding the audioconvert/videoconvert elements. https://bugzilla.gnome.org/show_bug.cgi?id=735748
-
- Sep 15, 2014
- Sep 13, 2014
-
-
Issue: During a PAUSED->PLAYING transition when we are rendering an audio buffer in AudioBaseSink we make adjustments to the sink's provided clock i.e. fix clock calibration using the external pipeline clock, within "gst_audio_base_sink_sync_latency function inside gstaudiobasesink.c". For the calibration adjustment we need to get the sink clock time using "gst_audio_clock_get_time". But before calling "gst_audio_clock_get_time" we acquire the Object Lock on the Sink. If sink is a pulsesink, "gst_audio_clock_get_time" internally calls "gst_pulsesink_get_time" which needs to acquire Pulse Audio Main Loop Lock before querying Pulse Audio for its stream time using "pa_stream_get_time". Please see "gst_pulsesink_get_time in pulsesink.c". So the situation here is we have acquired the Object lock on Sink and need PA Main Loop Lock. Now Pulse Audio Main Thread itself might be in the process of posting a stream status message after Paused to Playing transition which in turn acquires the PA Main loop lock and needs the Object Lock on Pulse Sink. This causes a deadlock with the earlier render thread. Fix: Do not acquire the object Lock on Sink before querying the time on PulseSink clock. This is similar to the way we have used get_time at other places in the code. Acquire it after the get_time call. This way PA Main loop will be able to post its stream status message by acquiring the Sink Object lock and will eventually release its Main Loop lock needed for gst_pulsesink_get_time to continue. https://bugzilla.gnome.org/show_bug.cgi?id=736071
-
Sebastian Dröge authored
GstVideoFrame has another reference, so the buffer looks unwriteable, meaning that we can't attach any metas or anything to it https://bugzilla.gnome.org/show_bug.cgi?id=736118
-
- Sep 11, 2014
-
-
Thiago Santos authored
Use the object lock to avoid concurrent processing which leads to small disasters (assertions or crashes)
-