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=753852
In case discover_uri returns NULL info, passing the info to discoverer APIs
result in critical assertion errors. Hence instead of passing NULL info along,
print the error and return.
https://bugzilla.gnome.org/show_bug.cgi?id=753701
When running gst-play against a directory name, and suffix the path with a
directory separator (e.g. tab completion), gst-play was printing two directory
separators in a row. g_build_filename fixes this, and additionally allows for
both '/' and '\' as separators on Windows.
In case of very short files we might end up seeking in
steps of a fraction of a second, which is silly and gives
the impression that seeking doesn't actually work. Make
minimum seek step a second instead.
For positive seeking segment.stop value will be -1,
when we change rate to -1, then the stop value will be udpated
with the current position. And then again if we change rate to 1,
the segment.stop value does not get updated and remains as position
where we last changed rate to -1. Hence playback stops at that point.
In case of positive rates, call gst_element_new_seek with correct values
https://bugzilla.gnome.org/show_bug.cgi?id=751213
Printing 64 whitespaces to erase the "Paused" message (after \r) would make
it wrap to the next line on shorter terminals. Instead we only print the
amount of spaces needed. Also mark the "Paused" string for translation
while we're at it.
Use smaller steps for lower rates to allow more
fine-grained control. Handle jump across 0 properly
from both sides (just flip direction where we would
have gone down to 0 instead). Don't artificially
limit rates to +/- 10x. Print new rate.
https://bugzilla.gnome.org/show_bug.cgi?id=745174
Just shows devices with basic info and exits. Or will
wait for more devices to show up or be removed with
the --follow option. It's also possible to pass filters
as command line arguments in the form DEVICE_CLASSES
or DEVICE_CLASSES:CAPS.
Currently the API is far from optimal and the user has to work around
our badly defined API to simply install missing plugins.
API:
new:
gst_discoverer_info_get_missing_elements_installer_details
deprecated:
gst_discoverer_info_get_misc
gst_discoverer_stream_info_get_misc
https://bugzilla.gnome.org/show_bug.cgi?id=720596
First set the pipeline to the PAUSED state to check if we are dealing
with a live pipeline or not. Then move to the desired state.
If we don't do this, it is possible that we receive a BUFFERING message
before we know that the pipeline is live and we would set the pipeline
to PAUSED and deadlock.
