- Aug 28, 2013
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
- Aug 27, 2013
-
-
Alessandro Decina authored
-
Alessandro Decina authored
Reset the write position to 0 and truncate the file on FLUSH_STOP.
-
Alessandro Decina authored
-
- Aug 26, 2013
-
-
Tim-Philipp Müller authored
It's just noise.
-
- Aug 22, 2013
-
-
Edward Hervey authored
This avoids triggering plenty of extra code/methods/overhead downstream when we can just quickly check whenever we want to set caps whether they are identical or not https://bugzilla.gnome.org/show_bug.cgi?id=706600
-
- Aug 21, 2013
-
-
-
YYLEX_PARAM is no longer supported in Bison 3. https://bugzilla.gnome.org/show_bug.cgi?id=706462
-
- Aug 20, 2013
-
-
Olivier Crête authored
Also add unit tests for gst_buffer_memcmp https://bugzilla.gnome.org/show_bug.cgi?id=706162
-
Tim-Philipp Müller authored
-
Sebastian Dröge authored
-
-
-
- Aug 19, 2013
-
-
-
-
-
This makes gst_parse_bin_from_description() return an element instead of a bin if there's only one element. Also changed gstparse.c to use this, so gst-launch won't create superfluous bins. https://bugzilla.gnome.org/show_bug.cgi?id=703405
-
- Aug 18, 2013
-
-
Sebastian Dröge authored
-
- Aug 16, 2013
-
-
Tim-Philipp Müller authored
Fixes spurious crash in test_simple_shutdown_while_running unit test.
-
Tim-Philipp Müller authored
When a buffering query is handled it uses the get_buffering_percent() function to get some statitics. Unfortunately this function also calculates whether the queue should be buffering and adapts the global queue2 state in case of state transitions from/to buffering (including whether a buffering message was posted on the bus!). This means that there is a race which can cause buffering messages to never posted if the global state changes happen as a result of aa query instead of resulting from bytes flowing in/out. Spotted by Sjoerd Simons. Change to only query state in get_buffering_percent() and update state only in update_buffering(). https://bugzilla.gnome.org/show_bug.cgi?id=705332
-
Wim Taymans authored
When the capacity of the queue changes, make sure we post an updated buffering message because we might suddenly have completed the buffering stage.
-
-
-
- Aug 14, 2013
-
-
Tim-Philipp Müller authored
-
Wim Taymans authored
Use custom code to implement flush-stop, we can't reuse the set_flushing code because we can't touch the live_playing flag and we need to signal the streaming thread.
-
Wim Taymans authored
-
Wim Taymans authored
Unlock the streaming thread when flushing so that we can insert the flush-stop correctly.
-
Edward Hervey authored
-
Edward Hervey authored
Just creates noise and bogus symbols
-
Edward Hervey authored
note: the #ifndef move is actually a move of the "SECTION" docstring
-
- Aug 13, 2013
-
-
Edward Hervey authored
-
Edward Hervey authored
In some specific cases (like transmuxing) we want to force the element to actually parse all incoming data even if the element deems it is not necessary. This property simply ignores requests from the element to enable passthrough mode which results in processing always being enabled. https://bugzilla.gnome.org/show_bug.cgi?id=705621
-
Thiago Santos authored
Adds a variant of the _push function that doesn't check the queue limits before adding the new item. It is useful when pushing an element to the queue shouldn't lock the thread. One particular scenario is when the queue is used to serialize buffers and events that are going to be pushed from another thread. The dataqueue should have a limit on the amount of buffers to be stored to avoid large memory consumption, but events can be considered to have negligible impact on memory compared to buffers. So it is useful to be used to push items into the queue that contain events, even though the queue is already full, it shouldn't matter inserting an item that has no significative size. This scenario happens on adaptive elements (dashdemux / mssdemux) as there is a single download thread fetching buffers and putting into the dataqueues for the streams. This same download thread can als generate events in some situations as caps changes, eos or a internal control events. There can be a deadlock at preroll if the first buffer fetched is large enough to fill the dataqueue and the download thread and the next iteration of the download thread decides to push an event to this same dataqueue before fetching buffers to other streams, if this push locks, the pipeline will be stuck in preroll as no more buffers will be downloaded. There is a somewhat common practice in dash streams to have a single very large buffer for audio and one for video, so this will always happen as the download thread will have to push an EOS right after fetching the first buffer for any stream. API: gst_data_queue_push_force https://bugzilla.gnome.org/show_bug.cgi?id=705694
-
-
Tim-Philipp Müller authored
-