New GStreamer adaptive demuxers work only within playbin3. In order to not
introduce new APIs (setting adaptive bitrate) that do not work by default
and to have the whole "clapper-enhancers" concept working correctly, its
about time to move on to playbin3.
Add APIs to allow apps to select start, min and max bitrates for adaptive streaming.
Combining min+max values can allow to implement a video quality selector,
although possible bitrates/qualities are not communicated with an app yet.
Allow loading external plugins called "Enhancers" that as the name suggests,
enhance Clapper library capabilities.
Currently implemented is a "ClapperExtractable" interface meant to extract
an actual media that GStreamer can later play from an initial input URI.
Additionally, an internal GStreamer elements that work with it are ported/moved
here from "gtuber" library that this functionality replaces.
* New translations clapper-gtk.pot (Hindi)
* New translations clapper-app.pot (Russian)
* New translations clapper-gtk.pot (Czech)
* New translations clapper-gtk.pot (Persian)
* New translations clapper-gtk.pot (Norwegian)
Since missing plugin string is translated, word describing its type
(e.g. Decoder) might come before plugin name itself, so we need to
check whole text to find substring instead of checking only prefix.
Fixes#477
No need to list API features if API is not being built.
This avoids an issue with meson script error when Clapper API
build is skipped, since these are not declared then.
Fixes#468
Do not require applications to import GStreamer and their devs to learn its
basics just to set this single element. Similarly as ClapperGtkVideo sets
"clappersink" during construction, it can also set "scaletempo" as this is
the most common choice for an audio filter.
Elements can still be changed like before if desired by setting corresponding
player properties.
Allow creating item with a previously downloaded cache file.
When set, file at location will be tried to be loaded first.
If this fails, URI will be used as normal.
Short video might be fully downloaded before playback starts.
This prevents us from emitting "download-complete" signal with
corresponding media item when download cache is enabled.
Check if we have pending item, as this will be the item downloaded
in such case (before it becomes playing item).
A possibility exists that something else keeps a reference to the player
even after video is disposed. In this case signals from the player would
not be disconnected.
We have to disconnect them manually here to ensure their callbacks will
not be used after disposal.
