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
Fix up default location of the registry.
Mention more options for GST_DEBUG (wildcards and
named debug levels).
Explain what to do with the dot files that can be
produced by setting GST_DEBUG_DUMP_DOT_DIR.
https://bugzilla.gnome.org/show_bug.cgi?id=693607
Remove GST_MAJORMINOR and replace it by GST_API_VERSION
Also set GST_VERSION_{MAJOR,MINOR,MICRO,NANO} explicitely
now.
All versions are at 1.0.0 now for the release soon but
API/ABI can still change until the 1.0.0 release.
Next release versions until 1.0.0 will be 0.10.9X and
these will be release candidates. GST_VERSION_* will
nonetheless stay at 1.0.0.0.
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 the getcaps function on the pad and use the CAPS query for
the same effect.
Add PROXY_CAPS to the pad flags. This instructs the default caps event and query
handlers to pass on the CAPS related queries and events. This simplifies a lot
of elements that passtrough caps negotiation.
Make two utility functions to proxy caps queries and aggregate the result. Needs
to use the pad forward function instead later.
Make the _query_peer_ utility functions use the gst_pad_peer_query() function to
make sure the probes are emited properly.
Instead of printing separate 'Current' and 'Default' values
(the former obtained via g_object_get() and the latter from
the property GParamSpec), simply print the Current value as
the Default value. This is the right thing to do for almost
all elements and avoids confusion if a subclass of a base
class chooses a different default than the base class.
The fixate caps function was not used externally and we have vmethods in the
base classes where it is needed.
Update some docs.
simplify some fixate functions in the base classes. Also pass the untruncated
caps to the vmethod.
The unversioned tool wrappers are confusing and annoying for packagers,
users and developers alike. A gst-launch pipeline that works in 0.10
will likely not work in 0.11 (e.g. because elements or properties get
renamed, or syntax changes). The unversioned tools also yield useless
results when used with gdb or valgrind. Packagers need to co-ordinate
the packaging of all major versions to make sure there are no conflicts
when both try to install the same files. When two major versions are
in use (e.g. 0.10 and 0.11/1.0), it may be unclear (when looking at
things on IRC/pastebin/mailing list etc.) which version is actually
being used when there are unversioned wrappers. For all these reasons,
it seems best to just remove them for now.
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).
People should just query the registry themselves or write a small
python script if they need this functionality (which is likely
less work than parsing the XML that this script outputs, and I'm
not aware of anything using the xml2text xsl either).
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.
