Add data cache functions and use them to store enhancer data into local cache file.
This way we can restore all properties and interfaces used in enhancer without
creating its instance. This avoids loading interpreters like Python at init time
making startup a lot faster.
At this point its sole remaining place where its used is one debug message.
For this reason remove it. With this, enhancer plugin files no longer need to
have this in them unless they want to keep Clapper 0.8 compat (otherwise unused).
Add support for configuring Clapper Enhancers. In order to do that,
introduce enhancer proxy object that act as intermediary between
player and enhancer plugin.
We cannot give direct access to enhancer instances from code, since
they are managed (created and destroyed) by player as/when needed.
Also due to some interpreted languages not working with multiple
threads. Instead, give proxy objects that will store each enhancer
configuration to be applied when an enhancer instance is created.
With this, implementations also gain ability to browse available
enhancers, see what they support and change their properties.
Enhancers are now also assigned to player, instead of being only global.
This allows to configure them separately on a per player instance basis.
Writing configurable enhancers is super easy too, as all plugin has
to do is install standard GParamSpec properties to its class with a
corresponding gschema file (for global props only) and its done.
Allow setting an additional dir(s) with "CLAPPER_ENHANCERS_EXTRA_PATH" env.
This should allow to add other enhancers without removing default ones.
If app/user needs to remove default ones, "CLAPPER_ENHANCERS_PATH" env
can be set to empty.
Instead flushing right after select streams request, wait until
they are selected before doing a flush.
This fixes a hang when changing audio language with hlsdemux2.
When new instance of adaptive demuxer is created (different video is played)
this prop value would become zero. We want to avoid that and instead report
only bandwidth after fragment is downloaded, so when video will be unplayable,
next one will not start from lowest quality.
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
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.
The aim here is to stream an online video/audio while also at the
same time download/cache it to disk (excluding adaptive content).
After download is complete, further playback and seeking are done using the
locally cached file. This functionality uses GStreamer "downloadbuffer" element.
Player will emit a signal with a local download location after it completes,
so application will know where downloaded file for media item is stored in
case it wants to reuse it in the future.
It is up to application to set download dir and later manage downloaded
content in it, removing files its not going to use on next application
run and any incomplete downloads.
Billboard does not post automatic volume/speed announcements. It did at
some point during development, but it was scrapped in favour of letting
app use callbacks of "notify" signals to call announce speed/volume.
It seems GTK continues using created contexts, so we cannot unref it here.
Looking at GTK sink implementation for GtkVideo, I see that they do not
unref it either, but since we use surfaceless context it would be probably
better to have a static GstDisplay and reuse the same context in future.
Some media files have custom/proprietary metadata.
It should be safe to simply ignore these, since we do
not map metadata to any sort of Clapper stream anyway.
Fixes#441
