Sometimes property might return a subclass type when object is subclassed.
This especially happens with custom GdkPaintable implementations.
For this reason instead of comparing object type, check if it inherits what we want.
When seeking to a marker position, logic always used NORMAL seek method since
FAST would be too inaccurate. This is fine, but when user sets preferred seek
method to ACCURATE we should use it always (including seeks to marker positions).
Sometimes data is similar and can be determined to be a playlist
by NOT including some specific syntax (e.g. HLS). For this reason
add ability to define an exclusion requirement for playlist parsers.
Similar to queue alternation functions present in reactable, also
add ones for timeline alternations as these are a must for non-newly
created items.
For consistency, remove auto thread switching logic from insert/remove
functions in ClapperTimeline object. Such behavior is unexpected and
I feel it could lead to potential issues such as deadlocks.
It was ported to Clapper Enhancers repo as a plugin called "Control Hub"
for better clarity what it does. Applications using old one should slowy
move towards using new implementation instead.
Slight cleanup related to media item construction.
Also fixes an issue where item ID was not being set when
created with g_object_new (what bindings usually use).
In cases where there are multiple objects resolving a playlist at once
(e.g. player starts playing playlist item that Media Scanner also works on),
just ignore parsing results from the other parser. We keep/use parsing
results from whichever parser parsed the playlist first.
Instead of doing this inside player, logic was reworked and moved into playlist demuxer
itself. It uses GstQueries to communicate with upstream elements. This way we can post
an error from running pipeline which helps keep this logic in single place and have it
shared with other pipelines (like the one used in Media Scanner Enhancer).
As part of the rework, nested playlist limit was added and set to 10 redirects.
Seems like a safe/optimal number and this simplifies stuff a lot. Instead of
keeping a list of strings with previous redirected URIs, we can just store the
one most recent in media item.
Fixes a problem where error message from unplayable URI content
(e.g. non-existing file) arrives on pipeline bus before resolved
playlist which contains that URI.
With this change, a playlist can be resolved into individual items
which are put into queue even if first item of it is unplayable.
We do not want to create situations where multiple threads are running
cache cleanup at once (since they all think last one was run long ago).
This can be prevented with a combination of global mutex and a "trylock",
so we can simply avoid both mutex locking and starting another cleanup.
This should be used internally for whether title is still used from parsing, not if parsing was successful.
Fixes an issue where in such cases correct title is not updated later on.
In some cases, simple properties in reactable enhancers are not enough.
This allows enhancers to do something on a signal from user (e.g. button/shortcut press).
It can also be used to communicate with the player for things that were
already done externally (like playlist parsing in Media Scanner enhancer).
Allows to mark a job with a given ID as started, then when another thread/instance
wants to process the same ID we can detect it and await previous job finish.
This is especially useful for not extracting the same URI concurrently while
still allowing to process multiple different URIs at once without blocking.
By enforcing keyfile GSettings backend with a custom file path,
we can store all enhancers settings within known location.
It makes it much easier to share them in between apps in Flatpak.
We only need to post events in the pipeline for navigation to work.
This was never used for anything and it generates a lot of noise
in the pipeline bus when cursor is moving over video.
A detailed signal that allows for applications to receive element
messages posted on the pipeline bus. Useful if app cares about
some custom message that player normally does not handle.
For example audio player might want to read "level" messages in
order to show current audio level or implement visualizations.
A widget similar to video but for audio playback only. Widgets from
ClapperGtk library like buttons, seek bar, etc. can be used in it
for building an audio player with ease.
Create a base class called "ClapperGtkAv" and subclass it into "ClapperGtkVideo".
This allows to have player and session inhibit logic in base class and share it
with other subclassed widgets.
When tags are populated elsewhere, do not run discovery on them again.
It is possible they were discovered in more efficient maner
(e.g. from playlist data itself).
This avoid us downloading each media item separately after all
playlist items are queued.
Move as harvest URI demuxer since it is supposed to work only with
harvest data from extractable src. Also change caps media type
to "text/x-uri" which is non-standard, but we have to differentiate
single URI from harvest and URI list (one or more URIs).
Handle "ClapperPlaylistParsed" messages on playbin bus by updating current media
item (playlist) to redirect to the first item in that playlist (with changed tags)
and appending remaining items to the queue after that playlist position.
This basically means that playlist gets resolved into simply adding more
items to the queue. This should also work with nested playlists within playlist.
