Were brought up recently in the user channel, and seemed like an
easy enough win. Unfortunately `sh_stream` currently lacks other
fields, so the rest of the flags will be added as the player's
functionality gets extended further.
Ref: https://datatracker.ietf.org/doc/rfc9559/
* Early exit if there is no useful data in the AVReplayGain
structure (FFmpeg does check that gain of at least one thing is
not INT32_MIN, but leaves the peak unchecked so it can be zero).
* Less depth in the if structure.
This simplifies the code, not requiring a loop.
Moves the getter definition somewhat upwards to allow
for its usage in a function that was defined before it.
The first AVPacket method has been deprecated in FFmpeg, and only
the HEVC decoder would read this information from there. The native
AV1 decoder as well as the libdav1d wrapper only support the newer
propagation method via codec context's side data. {ad,sd,vd}_lavc
call mp_set_avctx_codec_headers which copies the side data from
codecpar to codec context, so no changes are required on the
receiving end.
This process has been deprecated since avformat 60.15.100 and
since avcodec 60.30.101 AV_PKT_DATA_DOVI_CONF has been read from
AVCodecContext's coded_side_data. Additionally, the HEVC decoder
is the only one which currently reads this side data from packets,
the native AV1 decoder as well as the libdav1d wrapper instead only
support the newer propagation method via codec context's side data.
How this currently is supposed to propagate is:
* demux_lavf copies the codec parameters into sh_stream's lav_codecpar.
* {ad,sd,vd}_lavc call mp_set_avctx_codec_headers that calls
avcodec_parameters_to_context, which then sets global side data
to the codec context.
As this logic is already in place, so no additional changes are required
for things to work and the deprecated function call can just be
cleaned up.
Ref: FFmpeg/FFmpeg@5432d2aaca
Ref: FFmpeg/FFmpeg@804be7f9e3
Ref: FFmpeg/FFmpeg@12e5116872
Ubuntu 24.04's pkg-config is already an almost empty transitional
package that depends on pkgconf, and pkgconf contains the
`/usr/bin/pkg-config` binary.
Thus while we are moving macOS to it, we shall do the same with
this mingw-w64 build.
This works around an issue with recent Github CI runners where
Homebrew is in an intermediate state. This is where old pkg-config
is installed, yet pkg-config as a package has become an alias
for pkgconf, thus causing failures to automatically switch symlinks
from one to the other.
Ref: actions/runner-images#10984
No idea how things previously worked without having these set, but
apparently they did...
If this was a normal encoder to muxer case, we would utilize
`avcodec_parameters_to_context`, but alas this is not.
Fixes: #13794
Homebrew has finally given up supporting macOS 11, and all updated
dependencies are being built locally. Additionally, python3.12 - being
a dependency of libass in Homebrew - seems to completely fail under
cairo's meson usage on macOS 11, even if we let it build.
Thus, finally remove macOS 11 from our macOS build matrix, leaving
12 and 13.
ref: Homebrew/brew#16019
This way we receive such minor details as the profile (necessary for
ARIB captions, among others) during init. This enables decoders
to switch between ARIB caption profile A and profile C streams.
They should not be modifying the argument, so clearly marking it
as const makes sure we don't do it in the future as well as allows
for read-only optimizations.
Workflow virtual machines have now been updated so that moby package
contains rule for the newly added syscalls, such as 'clone3'.
Effectively reverts 64fa440c69 .
This older image has been deprecated and will be removed in December.
The images have also already had planned outages during which the CI
flow has been affected. Thus it feels like a good idea to clean
this up at this point.
Ref: actions/runner-images#5583
Originally, I considered warning once to be useful for figuring
out whether the change in logic regarding resetting requested
mode actually fixed the reported issue or not, but alas not everyone
was happy with that decision. Thus the log level will always be
debug. This enables us to lose one level of indent as well as a
variable, which is always positive.
Additionally, make the message more explicit regarding what could
possibly be implied by the mismatch, as it seems like this was
not always clear.
Otherwise mpv and the compositor can end up in an eternal loop where
mpv requests one mode, and compositor tells that the mode is not
that (and will most likely not change).
Additionally, log these mismatches - first time as a warning, and
later as debug logging.
It is verbose, but makes it more explicit that requested_decoration
takes in three values:
* 0: no specific mode requested by mpv
* ZXDG_TOPLEVEL_DECORATION_V1_MODE_CLIENT_SIDE: (!border)
* ZXDG_TOPLEVEL_DECORATION_V1_MODE_SERVER_SIDE: (border)
The first set iterates through all standard FFmpeg layouts and
checks that those which fit MP_NUM_CHANNELS succeed.
The second set iterates through built-in named channel layouts,
and attempts to convert them to AVChannelLayouts.
This is the new FFmpeg channel layout structure, which now
combines channel count and layout into a single location.
Only unspecified (channel count only) and native (channel layout
mask based) layouts are currently supported for the initial move
towards non-deprecated APIs.
This way mingw-w64 becomes the first CI workflow to build gpu-next.
Unfortunately, currently neither wscript or meson has gpu-next or
libplacebo-next as an option that one can require.
This fixes build failures with avcodec 58.113.100 or before,
matching FFmpeg release versions 4.0 to 4.3.
This flag was added in between avcodec 58.113.100 and 58.114.100
during the FFmpeg 4.4 development cycle. It lacks its own version bump,
so instead a check for the define is utilized instead.
Additionally, warn the user if they request GPU film grain with
too old of an FFmpeg.
Fixes#10088
The VO is available during decoder initialization mostly for direct
rendering purposes, so if f.ex. a complex filter chain is utilized,
there is no video renderer information available via
mp_filter_find_stream_info during creation of the decoder filter.
Thus, check for whether the VO is available before attempting to
check the capabilities flag from it.
Additionally - to simplify logic - makes explicitly requesting GPU
film grain to always disable decoder film grain functionality. The
warning is still shown if the VO is available and no support for
film grain application is available.
Fixes#10079
This lets us remap various messages which might now be happening at
each frame onto the trace level, thus unaffecting the initial debug
log level.
Additionally - thanks to this ability - the previously globally denied
message queue abandonment messages can now be handled and mapped to
trace log level, as on that log level they may be of use.
Recommended by rossy and based on his libplacebo commit
6d72f6445566eddb0493447d0bda72d98a99d40c .
Instead of always having the reference outside of calling resize,
request a backbuffer at start and relieve the backbuffer at
submission for presentation.
Query the description of the swap chain, which should in all theory
contain the format of the backbuffer. Then utilize a newly added
ra_d3d11 function to map the format to an ra_format. After that,
utilize the depth of the first plane of the format, as previously.
The field has been deprecated, yet the upcoming new default is not yet
the default. Thus, until lavc major hits 60 and the default behavior
finally gets changed, we have to explicitly set the field's value.
The deprecation had already been handled by adding the required
version limitation for this code in bbbf3571ed ,
this change merely just removes the warning which would otherwise
appear until lavc major version gets bumped to 60.
By receiving the graphics API-specific contexts from the generic
pl_gpu instance, it is not necessary to store them separately.
As the current priv struct stores nothing else, this allows its
removal. This removal cleans up related compiler warnings regarding
unused variables in case of opengl and d3d11 being disabled in
mpv/libplacebo.
Functions to receive the underlying vulkan,gl,d3d11 structure were
added in libplacebo version 4.182. Our current requirement for
gpu-next is 4.190, and thus we can freely utilize these helper
functions.
We only wish to touch actual video frames, which should have an
allocated image attached to them, so just check the frame type
early, and exit by passing through such non-video frames to further
filters in the chain without attempting to process them.
Fixes a crash in case of non-video (EOF/NONE) frames being passed
onto the filter when the dovi option was set to false since
05ccc51d53 .
Since libavcodec major version 59, the requested "ass" format became
the default as the old timing-included format was disabled starting
with that version. Additionally, this option by itself has since
been deprecated as it no longer serves any purpose.
References:
FFmpeg/FFmpeg@1f63665ca5FFmpeg/FFmpeg@176b8d785bFixes#9413
This fixes a mismatch between configure working and build time
failing with Linux + OSSv4, enabling compilation on Debian based
Linux systems with the oss4-dev package.
Fixes#9378
The bytes_read struct member in AVIOContext is now officially public,
so its usage no longer has to be specified as non-compliance with
FFmpeg's ABI/API rules.
That said, unfortunately there was a short period of time between
August 2021 and October 2021 where the struct member did not exist
in FFmpeg's git master, so keep a feature check for it alive for
now to enable building with those versions. Thankfully, no release
version of FFmpeg will be without this field, so it should be
possible to drop this check with time.
Finally, simplify the function in case the struct member is not
found. After all, there is zero reason to iterate through the AVIO
contexts if we cannot get the information we require.
Based on the idea behind emersion's change to drm_info
(https://github.com/ascent12/drm_info/commit/869e789a645b92a99e592a230fe39b0c59a2cd7d).
Lets us by default skip devices which are not capable of doing what
the DRM master output requires (not primary devices), as some devices
have card0 actually not be such.
Negative part is that the number given to drm-connector is no
longer a direct mapping against a file name.
Unfortunately, this functionality in large part based on a struct
member that was made private in FFmpeg/FFmpeg@7489f63281
in May. Unfortunately, this was not noticed during review.
This reverts commit 0862664ac9.
This CI builder bases on openSUSE Tumbleweed, and recently had
its glibc updated. This led to new syscalls such as 'clone3' not
being allowed through the security layer.
Can be reverted after Github Actions updates their security policy.
actions/virtual-environments#3812
This brings enabled features on the same level as disabled and
auto-detected features by having both alternatives available.
Looking at the commit message of 652895abdc
this seems to have been the intent from the start, but this specific
definition was missing from the option creation in Features.
Its define (HAVE_FFMPEG_STRICT_ABI) is now utilized in a single
location, where an internal libavformat struct member is utilized.
This struct member is now (after around 10 years) finally removed
from public visibility in FFmpeg's master.
After a review of functionality, the information in bytes_read is
passed onto the demuxer layer, and then utilized for
{cache,hack}_unbuffered_read_bytes. This information is then utilized
for:
1. Calculation of bytes_per_second in demux/demux.c::update_cache,
which fills the information for properties "cache-speed" as well as
"raw-input-rate" (of which stats.lua is the most prominent user).
2. bytes_per_second also affects how often update_cache is called in
addition to the two locations it is called unconditionally in
(read_packet, demux_update).
In other words, the information provided does not appear to control
crucial mpv functionality, but rather its lack would seem to mostly
affect the speed of certain properties updating, or having valid
values. For the former, stream size as well as timed metadata get
updated in update_cache - although the demux layer does throttle
the update of certain things to once per second in that function.
For the latter, "cache-speed" and "raw-input-rate" lose read data
statistics from AVIOContexts opened by the opened FFmpeg AVFormatContext
itself, as opposed to the primary one - which goes through mpv's
stream reading implementation.
By enabling this feature, and disabling this abuse of private API
lets users build mpv by default with the latest master FFmpeg, thus
giving us the breathing room to look into some of the details of
this case, and either decide to:
1. Post a patch to add this information back to FFmpeg proper.
2. Remove or replace this functionality in another manner.
End user impact:
Any IO not handled by mpv itself - but rather by IO contexts newly
opened by the input format - is not visible through the properties
"cache-speed" and "raw-input-rate". Examples of such input formats
are the HLS and DASH readers in FFmpeg.
Historical git references:
- Addition of unbuffered_read_bytes: 4dfaa37384
- Rework to have the reporting function: ebf183eeecFixes#9159
Now loading cover art through mp_add_external_file requires an
additional argument to be set to true. This way not all video-add
commands end up being marked as cover art when they move through
mp_add_external_file, as originally changed in 55d7f9ded1 .
Additionally, this lets us clean up some logic that would otherwise be
duplicated between open_external_files and autoload_external_files, if
the logic had been kept split from mp_add_external_file.
Fixes#8358
This enables us to get more of a message than just "Download failed.",
possibly helping people help themselves to get the download going.
References #8417
Set pcm state to SND_PCM_STATE_XRUN in case -EPIPE is received,
and handle this state as per the usual logic.
This way snd_pcm_prepare gets called, and the loop continued.
Inspired by a patch posted by malc_ on #mpv.
As we are now on 20.04, these packages are now available in the
repositories. Additionally, they don't need to be separately pulled
in, as gcc-mingw-w64 already does that.
Jan Ekström