The fact that Scenario.pipeline was not accessible in a thread way lead
to the fact that all users had to take the unref the last pipeline ref
in the main thread, otherwise we were crying. This was an ugly
restriction which lead to issue when using scenario on gst-rtsp-server.
This break the API as this commit remove the GstValidateScenario.pipeline
field but it is worth it.
Note: The notion of "live" here is in the *content* sense and not in the
GStreamer sense.
Ex:
* A rtsp stream is always "live" in the GStreamer sense but might not always
provide live content.
* HLS/DASH streams are not "live" in the GStreamer sense but might
provide "live" content.
Some scenarios might:
* require live content
* not be compatible with live content
This patch adds two new properties for scenarios:
* live_content_required (default False) for scenarios that can only work with
live content.
* live_content_compatible (default False) for scenarios that can work with
both live and non-live content.
This patch adds support for reading a "live" property from stream_info
Since glib version 2.54, g_object_newv() is deprecated.
This patch changes that function with a simpler g_object_new(),
since no properties are set.
https://bugzilla.gnome.org/show_bug.cgi?id=782860
When replacing an action structure, also update the action name with
the (new) name from the new structure. Otherwise we end up with
a bogus name from the previous (deleted) structure.
The name of the action comes directly (i.e. not copied) from the
contained GstStructure field. Therefore make sure to take that
name from the proper structure field (copied just before) and
not from an outside one.
GOptionEntry's arg_data is of type gpointer which differs in
constness from const gchar*, so remove constness from outfolder.
This fixes a build issue with msvc.
https://bugzilla.gnome.org/show_bug.cgi?id=782031
And let following actions to be executed (setting the action as
INTERLACED) which will make sure the track switch happened at some
point. It means the user has to set the pipeline to PLAYING so we can
make it works but we do not have choice here I think
https://bugzilla.gnome.org/show_bug.cgi?id=781213
Protect the expected seek values with the same lock as the one
that will be used to read/validate the resulting segments and flush
values.
Avoids races with duplicated seeks (i.e. a seek that was already
sent and handled via another pad, such as in demuxers).
https://bugzilla.gnome.org/show_bug.cgi?id=781112
