This better reflects what it actually does. As a bonus, script writers
won't be misled into thinking that fps displays the actual video or
display fps.
The point of the mpctx->delay field is for calculating a/v sync and
adjusting the frame timings appropriately. However, the frame_time was
always subtracted from mpctx->delay regardless of the audio status. This
meant that for a video with no audio, every single frame had a
subtraction with nothing ever added to it meaning that you get massive
negative delay times. For weird videos where the audio starts way later,
the massive delay leads to the VO sleeping for basically about as long
as the video was previously playing without audio. This results in
nothing being rendered during that brief period of time and just overall
badness. When using display-sync, it happens to work since the video
doesn't adjust itself based on audio and it renders anyway.
The fix is to simply not touch mpctx->delay in player/video.c unless
there's actually audio playing. This is what the rest of the code
already does aside from setting it to 0 on resets or EOFs. Move the
calculation into adjust_sync after the audio status check. It works
exactly the same as before except that we don't constantly subtract
bogus values when there's no audio playing. The reverse situation in
player/audio.c also has the same issue. For something that is only
audio, mpctx->delay is always added to but nothing will ever subtract
from it. It's not really clear if this particular version could ever
cause a real bug, but logically it needs to be guarded in the same way.
The field here should only be updated if the video is actually playing.
Fixes#12025.
The end position of the word to be completed is never used because all
patterns end with $. Remove it or it would complicate implementing
completers with more patterns.
This will allow providing more nested completions without pre-generating
an enormous amount of completions, and it is more efficient since it
only generates the completions needed for each completion attempt.
In the pursuit of stability.
It is slower and QEMU-based, but if this isn't stable, I don't know what
will be.
Bump the timeout to 30 minutes, just in case. It seems to take 12-15
minutes to finish.
Peak detection greatly increases HDR experience. Performance hit of
non-delayed detection is not that significant and is in line with
current default settings.
This fixes warnings generated for `-Wunused-result` when mpv is built
with `-O1 -D_FORTIFY_SOURCE=1` or higher on clang since read/write
functions are declared with the `warn_unused_result` attribute.
Cast to void to avoid these warnings.
It was found that this causes issues with at least ao_coreaudio,
essentially revealing a way bigger issue:
Some AOs don't check for 0 and/or have no way to deal with short writes.
Someone will have to figure out a fix later but get rid of the direct
cause for now.
This reverts commit ae908a70ce.
Any track that has attached picture is also always considered an image.
Not every image is neccesarily an attached picture though. So change the
check here to capture more possible cases where we should be updating
the subtitle. With the previous commits, this fixes#12387.
Add a simple helper to codec_tags to check if the codec name matches one
of the images. If so, then we set still_image and image in the stream as
true (slightly different semanatics).
demux_mf has a big const struct which is essentially a nice list handy
list of codecs that are considered images. This is generally useful for
all demuxers (demux_mkv could use this), so instead of making yet
another list, lift it out and put it in a common place. Some things
slightly changed so it matches the very similiar mimetype mapping struct
below it. demux_mf calls a helper mapping function instead.
This actually started having a linking error a few days ago, but the ci
never actually actually exited 1 for some reason so it was never caught.
The actual commits where this started happening are unrelated (reverted
all of the them to be sure) and there's no other obvious things like a
meson update that would cause this. All I can assume is some other
package within BSD itself, but I can't be bothered to debug it. Anyways,
just disable iconv in the build for now so the CI stops failing.
Presumably there's something wrong in the environment with GNU's
libiconv and the built-in one clashing somehow. Also, sdl unbelievably
defines HAVE_ICONV in their public header so we have to disable that
too.
Since vmactions is basically a bootlooping disaster* with no signs of
life from upstream, let's try a different action instead and hope it
works better. We don't need to force the latest release channel, so
delete that part. Also make the pkg install just one command for
simplicity.
*: https://github.com/vmactions/freebsd-vm/issues/74
I won't even comment how terrible this option is and why in 2023 default
is not at least `autocrlf=input`.
Disable the conversion to CRLF. We build everything in MSYS2 sysroot,
which supports/expects LF. While the checkout itself is done with
actions/checkout@v3 and this causes problems.
C standard says that `= {0}` activates and initializes first member of
union. We expect whole union to be zeroed, it is used as default value.
Initialize union with one zeroed default instance to ensure proper init.
Fixes: #12711
Make it not possible to build mpv without the latest libplacebo anymore.
This will allow for less code duplication between mpv and libplacebo,
and in the future also let us delete legacy ifdefs and track libplacebo
better.
Some hwdecs (eg: dxva) have no frames constraints and no static
supported_formats, which ends up segfaulting. This change fixes the
segfault, but also includes additional changes to avoid concluding that
direct output of hardware decoded video is impossible.
In the case where there are no frame constraints and no
supported_formats, we basically have no idea what the hardware actually
supports. Previously, we just tried to display the frame, but all the
work I did to detect incompatible formats causes this scenario to now
conclude that no formats can be displayed, and forces a HW download to
system memory.
I have made a couple of small changes to assume that direct display is
possible. If it's not, the VO will error out down the line, which is
what happened previously.
I'm guilty of violating this, but surely I can't be the only one. 85 is
pretty small and there's plenty of lines in the codebase that go well
over that. Surely nobody programs on tiny screens anymore and the kernel
raised the limit to 100 a few years ago so let's just copy that.
Nobody except a chosen few (I'm not one of them) even knows what it
means. Multiple people thought it was actually some kind of rendering
bug. Just disable it by default. Closes#12671.
currently for a filename such as ".file" mpv incorrectly thinks of the
entire filename as being an extension. skip leading dots to avoid
treating "hidden/dot" files as extension.
Matroska spec says that DisplayWidth and DisplayHeight should be applied
after cropping, but this doesn't adhere to the real files which does not
follow this rule. Revert the change and we can re-evaluate if someone
complains with spec compliant files.
See: https://datatracker.ietf.org/doc/draft-ietf-cellar-matroska/
This reverts commit f8db02b59d.
Unfortunately there are files out there with broken tags where the
width/height doesn't match the actual width/height of the file. That
means the cropping logic which normally should be a no-op resulting in
(0, 0, w, h) ends up being a crop which is probably not wanted by the
user. Workaround this by simply keeping the entire crop rect as 0 when
there is no container cropping. All zeros is internally treated the same
as (0, 0, w, h) and avoids bad container data messing up the width or
height of the window. Also simplify the logic a bit and get rid of some
superflorous bools that had no real use. Fixes#12680.
