Following the precedent set by the DoVi metadata, we encode this as an
ancillary attached directly to the frame, since it contains
frame-dynamic data.
We make the decision to follow ATSC A/341 Amendment 2094-40 instead of
the original SMPTE ST2094-40:2016 specification, because the latter
includes a lot of extra metadata fields which the former intentionally
leaves unused, and which are also unused in practice (both in
implementation and in files). We can easily add them later should a need
arise.
Also, again following the precedent set by `vlc_video_dovi_metadata_t`,
we encode AVRationals directly as `float`. This saves us from having to
do another unnecessary conversion step in the actual usage site (e.g.
the libplacebo vout) by allowing the use of `av_q2d` directly.
The vout is created first, based on the input format. Then filters
(filter_t) could be added, possibly producing pictures in a different
format.
input ---> filters ---> MISMATCH [I420] vout
I420 RGBA
To avoid a mismatch between the output of the last filter and the
expected format of the vout input, a converter was added when necessary
to compensate:
input ---> filters ---> converter ---> [I420] vout
I420 RGBA I420
But this was often a waste, and it caused problems for opaque formats.
Instead, request the vout to adapt itself to the actual format produced
by the last filter. If it can, we can avoid an additional converter.
input ---> filters ---> MISMATCH [I420] vout
I420 RGBA
input ---> filters ------------------> [RGBA] vout
I420 RGBA
If the vout does not support the new format (or does not accept to
update its format), a converter is still added like before.
Co-authored-by: Alexandre Janniaux <ajanni@videolabs.io>
The player will be used by the extensions to listen to events, like the
media changed for input-listener capabilities or meta changed for
meta-listener capabilities.
In the previous design for the vlc_extensions, the whole extension
system was setup by the UI, and since the UI were subscribing to
playlist events signalling that the input item changed, the UI was
forwarding those calls to the extension subsystem. However, there is now
the unified interface to control or listen to the playback, ie. the
vlc_player, which can better fit this goal.
It allows to split this need from the question of where the
vlc_extensions are initialized.
We'll try to use vlc_logger instead of object message whenever the
extension manager is required for that. Using a logger removes the
dependency to vlc_object_t and its hierarchy and is simpler to use.
The private sys type was extension_sys_t because that was the type
required by the structure. Now that it's a void pointer, we can rename
it to a more suitable name that can be found from a debugguer and
represent what the private implementation provides.
Refs #18033
extension_sys_t is a type that actually depends on the implementation
and it shouldn't be named uniformly to avoid ODR in C++ code. It also
allows naming the internal structures with a type that can be retrieved
from a debugger instead of being potentially mistaken by another type.
Extends commit 79afb971ff, ref #17078
Every controls are modifying an extension and require the extension to
be non-null as first parameter. Instead of forwarding the extension to
the va_list, extract it as first parameters unconditionnally.
This prepares some work to replace the pf_control callback by dedicated
operations and start reworking some code style along the way.
Several vlc_vector functions must not be called with count == 0:
- it's useless (e.g. pushing 0 items to a vector)
- with the current implementation, it can cause memcpy() to be called
to copy 0 bytes (useless) with NULL pointer for the src parameter
(triggers an error in ASAN).
The Windows SDK and mingw-w64 5+ have a clean way to group packing blocks
together. mingw-w64 generates some bogus warning (clang) when using
packing from a header, so keep it to MSVC for now.
The PRId64, PRIi64, etc. are properly defined since at least mingw-w64 5 which
is the minimum we support.
snprintf, vsnprintf and swprintf officially exists in the Windows SDK and in
mingw-w64 5.
restrict is forcibly defined to __restrict for C++ compatibility, even with cl.exe.
And __declspec(__restrict) is not valid, it creates a lot of warnings.
Before 3b26eefc99, the caller was not
responsible to destroy the request but he could cancel it via:
vlc_thumbnailer_Cancel()
WaitForTheCb()
ReleaseResourceAssociatedWithTheCb()
This new commit, in addition with
3b26eefc99 (that was not complete), allow
the user to cancel/destroy the request, without waiting for any
callback:
vlc_thumbnailer_DestroyRequest()
ReleaseResourceAssociatedWithTheCb()
vlc_thumbnailer_Cancel() has been renamed to
vlc_thumbnailer_DestroyRequest(), this new call must always be called to
release resources and can be called before receiving the callback in
order to cancel it.
Fixes#27766
Steve Lhomme
Niklas Haas
Romain Vimont
Alexandre Janniaux
Alaric Senat
Thomas Guillem
Johannes Kauffmann