- 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)
-
When switching URI from about-to-finish, playbin starts decoding the new URI and the queue2 inside uridecodebin starts emitting buffering messages immediately. However, the queue(s) inside playsink still have buffers to play and the pipeline doesn't need to pause for buffering, so we should not send those buffering messages up to the application, otherwise there is an audible glitch caused by pausing the pipeline for a very short time. https://bugzilla.gnome.org/show_bug.cgi?id=727255
-
when downsampling, the output buffer can be filled before all the input samples are consumed. this is correct: when downsampling, several input samples are needed for each output sample, so when only a small number of input samples are available the number of output samples produced can be 0. the resampler, however, was discarding those extra input samples instead of clocking them into its filter history for the next iteration. this patch fixes this by removing the check that the output buffer is full. the code now always loops until all input samples are consumed, and relies on the calling code to have provided a suitably sized location for the output. note that there are already other checks in place in the calling code to ensure that this is the case. https://bugzilla.gnome.org/show_bug.cgi?id=732908
-
- Sep 04, 2014
-
-
Fixes a crash when controlsrc, readsrc or writesrc are modified from gst_rtsp_source_dispatch_read/write and gst_rtsp_watch_reset at the same time. https://bugzilla.gnome.org/show_bug.cgi?id=735569
-
s3 is not being initialized when run in a loop and the same was being freed, which resulted in the crash https://bugzilla.gnome.org/show_bug.cgi?id=735952
-
- Sep 01, 2014
-
-
Thiago Santos authored
Adds a new test to textoverlay to make sure it can properly handle elements that have ANY caps but fail to add the overlay meta in the allocation query. This test verifies that textoverlay won't use the caps features even knowing that the overlay meta is accepted when querying the downstream caps because it also needs downstream to confirm by putting the meta in the allocation query. https://bugzilla.gnome.org/show_bug.cgi?id=735800
-
Thiago Santos authored
When downstream claims to accept the overlay meta but fails to provide it in the allocation query, properly fallback to setting a new caps without the overlay meta as that is not going to be used. Only do this if the original caps doesn't have the overlay already, otherwise there isn't much that can be done. https://bugzilla.gnome.org/show_bug.cgi?id=735800
-
Sebastian Dröge authored
It's not done in any other code calling negotiate and will cause deadlocks as it is sending events and queries in the pipeline. Specifically this pipeline was deadlocking: gst-launch-1.0 videotestsrc ! textoverlay ! textoverlay ! fakesink
-
- Aug 27, 2014
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
- Aug 26, 2014
-
-
Sebastian Dröge authored
-
- Aug 18, 2014
-
-
Thiago Santos authored
Otherwise we might change some capsfeatures from ANY to the specific value from the filter and do not filter those out in case the sink doesn't support them https://bugzilla.gnome.org/show_bug.cgi?id=734822
-
- Aug 13, 2014
-
-
Thiago Santos authored
-
Sebastian Dröge authored
Otherwise we end up allowing video/x-raw with arbitrary caps features that are not handled by our converters. https://bugzilla.gnome.org/show_bug.cgi?id=734683
-
- Aug 11, 2014
-
-
Thiago Santos authored
Make textoverlay negotiate caps more correctly. 1) Check what caps we received in the video-sink 2) If it already has the overlay meta -> use it directly 3) If it doesn't, textoverlay try adding the overlay meta and using it, if downstream doesn't support it, just use what is received in the video-sink 4) Check if the allocation query also supports the meta to enable really using it Before it wasn't really doing renegotiation of any kind, just re-checking if it should use the overlay meta or not Also had to update the caps in the test as memory:SystemMemory seems to be required when you use a caps feature otherwise intersection/subset checks will fail. https://bugzilla.gnome.org/show_bug.cgi?id=733916
-
Thiago Santos authored
Avoids returning values that upstream can't produce https://bugzilla.gnome.org/show_bug.cgi?id=733916
-
Sebastian Dröge authored
Otherwise playsink might get shut down without us noticing that our pad references are gone now. Probably fixes https://bugzilla.gnome.org/show_bug.cgi?id=733165
-
- Jul 31, 2014
-
-
Edward Hervey authored
Fixes make distcheck
-