Concurrent Windows' colored debug message and g_print will print
string hard to read. Instead, use gst_print* which serialize
debug output and the APIs call.
Commit 215cfcf993 (gstreamer: Fix memory leaks when context parse
fails) fixes some memory leak, but in one of the newly added calls to
g_clear_error() the wrong variable was passed.
When failing to parse command line options, free the "err" variable, not
the "error" one.
https://bugzilla.gnome.org/show_bug.cgi?id=773907
Add missing 'else' and print caps and taglists without the
annoying duplicate string escaping, making both nicer to read.
Fixes string leak and coverity CID 1358492.
When g_option_context_parse fails, context and error variables are not getting free'd
which results in memory leaks. Free'ing the same.
And replacing g_error_free with g_clear_error, which checks if the error being passed
is not NULL and sets the variable to NULL on free'ing.
https://bugzilla.gnome.org/show_bug.cgi?id=753851
TRUE is 1, but every other non-zero value is also considered true. Comparing
for equality with TRUE would only consider 1 but not the others.
Also normalize booleans in a few places.
If the toplevel bin is not not a pipeline, we place the bin in a
pipeline. Also make sure that we connect to the deep-notify of this new
pipeline because we will g_signal_handler_disconnect() from it later.
It's considered a programming error in recent GLib versions now.
We may already have removed the source by returning FALSE from
the callback if it was fired. Fixes warning with newer GLibs
when interrupting a pipeline with Control-C.
Wait for all PROGRESS messages (if any) to complete before going to the PLAYING
state. This is the only way we can wait for live elements to complete their
operations.
This is interesting for elements like rtspsrc that do some asynchronous network
requests as part of going to the PAUSED state. It could be possible that it, for
example, provides a clock and then we would like to wait until it completes
so that we can use the provided clock when going to PLAYING.
When we receive a buffering message of 100% in the paused state, we exit
the event_loop and move to the PLAYING state. What should happen is that
we wait for both ASYNC-DONE and 100% buffering before continueing.
Current implementation uses a traditional signal handler and a 250ms
timeout callback in the event loop. Adding a GSource with
g_unix_signal_add() to the GMainLoop is a much more elegant solution.
The signal handler with this approach can send a message to the bus
directly rather than set a flag as all dispatching intricacies are handled
by GLib.
https://bugzilla.gnome.org/show_bug.cgi?id=693481
