Cropping by decoder has limitations with regards to aligment and hwdec.
It doesn't work to offset top left corner with hwdec and even with
software decoding it don't crop fully when resulting data would not be
aligned.
VO cropping is way more robust.
Setting `--video-crop=0x0+0+0` applies full frame crop, ignoring the
container one. Setting --video-crop=0 disables manual crop and restores
container one if it is available.
This makes it easier to apply crops without need to manually calc the
offset. I wanted for it to be top-left corner based, but maybe it was
not that good idea in retrospect.
Also rename scrw/scrh, since they don't refer to screen. It was copied
form m_geometry apply.
Third try is the charm? I stupidly missed that this option already
existed in my previous commits. Instead, add an auto value to it and
enable it by default for sd_lavc but not sd_ass. On my limited samples,
it seems to fix the gaps issue that can occur but without regressing
some duration timings for sub_lavc subtitles. Well hopefully anyway.
Fixes#12327.
Yet another bad idea. It turns out that there's already a sub-fix-timing
option which logic for this exact thing (overlaps/gaps) fixing. Also it
works better than this since it doesn't appear to artifically increase
sub duration either. Fixes#12327.
This reverts commit 725b631ec3.
mpv saves cache by default nowadays, but vo_gpu is pretty spammy and
saves a bunch of files per shader. If someone is using the non-XDG
config directory, this all gets dumped directly into ~/.mpv which isn't
so nice. Save it to a sub directory called "cache" instead (or
alternatively submit to your XDG overlords). For unfortunate reasons,
macOS uses XDG_CONFIG_HOME and has the same legacy fallback mechanism,
so this applies to it too.
We currently only allow specifying the Vulkan device to use by name. We
did this to avoid confusion around devices being enumerated in an
unpredictable order. However, there is a valid edge case where a system
may contain multiple devices of the same type - which means they will
have the same name, and so you can't control which one is used.
This change implements picking devices by UUID so that if names don't
work, you have some option available. As Vulkan 1.1 is a hard
requirement for libplacebo, we can just use UUIDs without conditional
checks.
Fixes#10898
In the previous change, I added the uuid files. In this change, we
check the libavutil version and if it's too old, we compile in our
local copy.
We have to change the include paths of the uuid code to find some other
libavutil headers, but nothing beyond that.
To avoid taking a dependency on ffmpeg 5.1 before we're ready (we need
a newer Ubuntu LTS release to drop ffmpeg 4.x support), ut not force us
to wait to add support for picking Vulkan devices by UUID, I'm copying
the uuid code from ffmpeg into mpv. It's one file with no private
dependencies, so it's easier to copy than to reimplement in any other
way.
Licence is LGPL so matches us.
We were over-enthusiastic when introducing --no-config into the
autocompletions. When autocompleting profiles, you actually need the
config, because that's where the profiles come from.
zsh is untested - I don't use it.
The old mplayer / zap style format is not fully standardized across
channel scanners, so autodetection may fail if the file name
does not indicate the delivery system.
While ZAP config files should contain strings in most fields,
their field number in the DVB-T / ISDBT case matches the number of fields
for VDR config files, and some channel list writers (namely, dvbv5-scan)
may insert "0" in unused string fields.
To disentangle such config files from real VDR config files,
add a check for the "INVERSION_" field which should always be filled.
dvb_get_channels is expected to append to an existing channel list.
For adapters supporting many delivery systems, a subsequent channel list
may turn up with a non-existent channel config, and the pointer
to the previously parsed channel list may be lost
(i.e. the list will be leaked and no channels detected).
Fix this by passing through the existing list (which may be NULL)
in case no new channels are found.
This is similar to DVB-T, but requires slightly different treatment
as there is no T/T2 differentiation.
Use a new channels.conf.isdbt file as channels config file.
Causes bad performance with interpolation because the changing hue angle
invalidates the mixing cache, as a result of libplacebo implementations
(specifically, the fact that this graph is drawn during the color
management process, instead of as a separate overlay).
Fix it by just hard-coding a particular, relatively interesting plane
(pi/4 approximately maps onto the red-blue axis).
Before this change, mpv used to get the total duration from
`avformat_find_stream_info` and used the per-track duration as a
fallback. This change reverses this order of preference.
The timestamps returned by `avformat_find_stream_info` are truncated or
rounded or floored (depending on the decoder) at the 6th decimal place.
For e.g. `avformat_find_stream_info` may return us a duration like
44.138667, whereas the duration we get from the per-track struct has a
higher degree of precision like 44.13866666666... and so on.
This caused various problems such as the playback_pts being a bigger
value than the duration, which would cause time-remaining to be a
negative value in some cases. Or cause you to reach a negative starting
timestamp when looping on an audio file with `gapless-audio`.
Moreover, we already skipped calling `avformat_find_stream_info` for
mp4, so we had already been utilizing this per-track fallback method for
finding the duration for mp4 files. It should be noted that while this
change is only required for audio-only formats, there is no harm in
doing this for videos as well.
There are way too many preexisting scripts that rely on this behavior
for video panning, like for example scripts that allow you to use mpv as
an image viewer. If this behavior is desired then it may be better to
add a new option for panning relative to the destination instead.
The restriction of video-pan-x/y being clamped to {-3, 3} also results
in the video being impossible to pan if it was zoomed in beyond a
certain degree.
This reverts commit 7d6f9e3739.
the osc currently allows for changing volume via scrolling when on top
of the volume icon. this does the same thing for the seekbar by allowing
seeking via scroll.
The default revert will always add 9 extra characters which means it
could go over the 72 character soft limit if the commit being reverted
has a long subject. We won't fuss about this so just shut up the lint in
this case.
`--vo=gpu-next` no longer uses this option, being replaced entirely by a
luminance-based approach internally. And even for `--vo=gpu`, the values
other than 'hybrid' are universally inferior in quality.
In the interest of gradually reducing the amount of option bloat here,
remove this mostly-pointless option.
fbe8f99194 made it possible for mpv to
autoselect forced subtitles again (it was bugged and would ignore
without slang being specified). Unfortunately, I forgot to take slang
into account here, so it would always autoselect the subtitles if they
are available. Fix this by checking both that it matches the lang and
that the previous track pick wasn't already matched (os_langs being true
is essentially equivalent to there not being any specified slang). This
way, it still respects the order of languages in your slang list.
Probably someone out there will be upset that forced subtitles aren't
always preferred regardless of the order, but that can be another option
for later I guess.
Prevents transient brightness spikes on scene transitions at the cost of
sometimes forcing an extra indirect pass (in particular, when
downscaling). But on GPUs powerful enough to run gpu-hq, the extra
indirect pass shouldn't matter too much. This option mostly exists for
weak iGPUs.
DVD/PGS are definitely not common, and ones that make use of the forced
subpictures flag even less so. For this button to be useful, the
subtitle track would need to be DVD or PGS, the track would need to make
use of the forced flag, the user would have to know what forced
subpictures are, and the user would need to have the preference of only
viewing forced subpictures on a subtitle. The function of this button is
too niche to be on the osc, if this behavior is desired the user can
simply bind a key in their input.conf. Moreover, this button only adds
confusion because there's no intuitive way to show what it does, and
there's no explanation for it anywhere in the manuals. osc real-estate
is quite limited as it is, so let's not waste any space on buttons with
highly questionable utility at best and confusing or bad UX at worst.
Gated behind option for backward compatibility.
Note that this will not magically start working with hwdec, as we do not
have crop detection for hwdec.
Kacper Michajłow
Dudemanguy
Philip Langdale
Oliver Freyermuth
Niklas Haas
llyyr
NRK