This returns the value of the target OS that mpv was built on as
reported by the build system. It is quite conceivable that script
writers and API users would need to make OS-dependent choices in some
cases. Such people end up writing boilerplate/hacks to guess what OS
they are on. Assuming you trust the build system (if you don't, we're in
really deep trouble), then mpv actually knows exactly what OS it was
built on. Simply take this information at configuration time, make it a
define, and let mp_property_platform return the value.
Note that mpv has two build systems (waf and meson), so the names of the
detected OSes may not be exactly the same. Since meson is the newer
build system, the value of this property follows meson's naming
conventions*. In the waf build, there is a small function to map known
naming deviations to match meson (i.e. changing "win32" to "windows").
waf's documentation is a nightmare to follow, but it seems to simply
take the output of sys.platform in python and strip away any trailing
numbers if they exist (exception being win32 and os2)*.
*: https://mesonbuild.com/Reference-tables.html#operating-system-names
*: https://waf.io/apidocs/Utils.html#waflib.Utils.unversioned_sys_platform
ytdl_hook always set force-media-title, making users unable to force
a media-title via options.
To prevent that, check if force-media-title is already set to avoid
overwriting it.
A better solution would be to use tags like is already done for some
metadata, however that doesn't work when `all_formats=yes` is used.
See cbb8f534b0
A comment was added to hint at why it isn't done via tags.
ref.
https://github.com/mpv-player/mpv/pull/10453#issuecomment-1445277496
This refactors exec to only return the result of the subprocess command,
and makes the rest of run_ytdl_hook use the fields of this result,
because specifying all those return values multiple times is unwieldy
now that exec is called several times, and this is easier to read
anyway.
I removed the line
err = string.format("%s returned '%d'", err, es)
altogether instead of updating the es variable, because there was no
chance of it being executed since it would only happen when
result.killed_by_us is true, but run_ytdl_hook returns early when it is.
This reorders some code and checks the image track-list sub-property
instead of the albumart one, so that when playing audio without enough
playtime-remaining and images, the "autocrop only works for videos."
warning is logged instead of the "Not enough time to detect crop." one.
It also avoids repeating this warning twice in the code.
As of e16d0dd15d current-tracks returns a video track even when
lavfi-complex is used, so the track-list loop in is_cropable can be
replaced with just checking current-tracks/video while still cropping
videos with lavfi-complex.
Changing the CONF_TYPE_FLAG was a bad idea because mpv_node.u.flag
continues to be an int, leading to a mismatch in type sizes which can
lead to problems with memcpy().
ref. #11373
This partially reverts commit 17d91b9d4d.
The m_option_type_flag is still needed for the CONF_TYPE_FLAG
(next commit).
Add a comment that m_option_type_flag shouldn't be used.
ref. #11373
This partially reverts commit 07545657bf.
The playlist title only got set when it was specified in the
playlist file.
If there is a title after opening a file, that should also be reflected
in the playlist.
ref. #4780
For hwdecs without devices we can't get instant feedback during probing
whether the hwdec can possibly work or not, so we definitely want to try them last.
Independently this would also have solved the issue addressed by the previous commit.
This fixes an issue where mpv would try mediacodec (which may not
be available depending on Android version) and pick v4l2m2m next
which ends up failing even though mediacodec-copy would have been available.
c784820454 introduced a bool option type
as a replacement for the flag type, but didn't actually transition and
remove the flag type because it would have been too much mundane work.
This was originally dropped because it was thought to be unneeded at the
time, but at least some devices (rockchip) apparently are still on old
compositors that use linux-dmabuf v2. It's not much code, and for
testing purposes it's good to have around since it's hard to test
drmprime otherwise. Some minor additions are here to support the newly
added vaapi-format mapping in v2 of the protocol.
This reverts commit a5b9d529ee.
effort=4 has a significant increase in quality/bpp compared to effort=3
with a very minor increase in encoding time. It's worth the trade-off
as a default setting for lossy encoding.
Older versions of pipewire segfault when calling spa_hook_remove() on
hooks that are zeroed.
Add a backfill for the logic added by pipewire 0.3.57.
Being able to remove zeroed hooks makes errorhandling much easier.
See #11309
This allows the logic in `convert_image` to fast-path if the image
params are equal. Without this check, the image params are basically
never equal, because that path goes through `mp_image_params_guess_csp`
while the `mp_image` itself does not.
Force it here for consistency across VOs.
After commit c98e7353, we blindly pass the screenshot colorspace to the
image writer. But since we want to introduces the ability to save images
in HDR and other exotic formats, we should strip this for unsupported
formats.
See-Also: #10988
When taking window screenshots with a colorspace override, tag them
appropriately, based on the best-known colorspace info. Note that this
is imperfect, we should ideally also attach the output ICC profile if
one exists. But this is better than nothing.
Also force 1:1 PAR in this case. In all other cases, default to sRGB.
When taking an unscaled screenshot, always render to an unspecified
SDR-like space. (Subject to change) Apply output-specific options (ICC
profile, color space overrides, custom LUT) only in window screenshot
mode.
I decided to split this off from subsequent refactors because it is IMO
a bug fix deserving of its own commit.
Screenshots are currently always RGB. Subject to change, but needs to be
communicated clearly if changed. This commit is not a functional change,
it's merely for code clarity.
Based on the new upstream helper function `pl_map_hdr_metadata` and the
existing AV_FRAME_DATA_DYNAMIC_HDR_PLUS. This allows us to use SMPTE
2094-40 dynamic HDR tonemapping in mpv, albeit with the limitation of
requiring `--tone-mapping=auto` in order to pick this curve upstream.
Dudemanguy