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
gst-launch.c: In function ‘print_toc_entry’:
gst-launch.c:446:3: error: the size of array ‘spc’ can’t be evaluated [-Werror=vla]
gst-launch.c:446:3: error: variable-sized object may not be initialized
Remove trace, we use debug log for that
Make alloc trace simpler, removing some methods.
Activate alloc trace with a GST_TRACE=3 environment variable.
Dump leaked objects atexit.
Provide an offset in the object where the GType can be found so that more
verbose info can be given for objects.
Remove -T option from gst-launch because tracing is now triggered with the
environment variable.
There are many good use cases for GstIndex and we want
to add it back again in some form, but possibly not with
the current API, which is very powerful (maybe too powerful),
but also a bit confusing. At the very least we'd need to
make the API bindings-friendly.
Remove SIGUSR* handling from gst-launch, since it might interfere
with other things (e.g. libleaks), and should be done differently
anyway (either via support for simple timed-commands scripting or
remote control via DBus or so).
This reverts commit 9ef1346b1f.
Way to much for one commit and I'm not sure we want to get rid of the pad caps
just like that. It's nice to have the buffer and its type in onw nice bundle
without having to drag the complete context with it.
