When printing the name of the video track on the OSC, mpv almost always
prefixes it with "unknown". This is referring to the language tag which
essentially nobody ever does for the video track since it doesn't make
any sense. Instead of putting unknown when there's no language, just
make it an empty string instead. "Unknown" confuses can confuse users
here and practically nobody would guess that it's referring to language.
We still will print the language for a video track in case someone out
there really does tag it, but that should be rare.
When playing a sparse video stream, the debug log gets hit with the
video EOF constantly since the audio is still playing. There's no
practical use for this so just do add some logic to only signal it once
if it is sparse.
There's an edge cause with gapless audio and pausing. Since, gapless
audio works by sending an EOF immediately, it's possible to pause on the
next file before audio actually finishes playing and thus the sound gets
cut off. The fix is to simply just always do an ao_drain if the ao is
about to set a pause on EOF and we still have audio playing.
Fixes#8898.
This is pretty obscure but if you screw around with the play-dir option
to essentially create a ping-pong loop; mpv will get hit by an assertion
error. What's happening here is that changing the play-dir always
requires a seek. This is handled in player/command along with the other
runtime option changes. However, queue_seek can actually clear the value
of mpctx->stop_play if the file is ending. So while loadfile is
terminating playback and the play-dir gets changed, the value of
mpctx->stop_play gets cleared because of seek. This then hits that
assertion later when mpv tries to finish the file.
The fix is to just add some weird logic to play-dir in player/command.
We have to be sure that mpctx->play_dir matches the new direction
immediately when we get the change so explictly set it here and don't
wait for it later. Secondly, keep the old value of mpctx->stop_play
before the seek and restore it afterwards. This ensures that termination
still happens cleanly and allows the ping-pong loop to work. Fixes#10782
When getting subtitles, sd_lavc checks if the current pts plus a small
offset (1e-6) is greater than the sub->pts as well as checking if the
pts is less than the sub->endpts. The problem with the endpts check is
that there are subtitles out there (pgs ones) that have overlapping
durations and thus you'll get a case where pts is greater than endpts
because a new subtitle shows up. However, the old subtitle is still
meant to be on the screen. This results in a flickering effect where the
subtitle flashes and then appears the next frame. The easy enough fix is
to just loosen the condition and remove the endpts check altogether.
That ensures that the subtitle remains selected for the entire duration.
Unsure if this possibly could regress some other kind of subtitle out
that that uses sd_lavc, but this does appear to fix a real issue with
pgs subtitles. Fixes#8202 and #10051.
Internal subtitles were not shown when switching between tracks while
mpv was paused. The reason for this is simply because the demuxer data
isn't available yet when the track switch happens. Fixing it is
basically just retrying until the packet is actually available when the
player is paused. Fixes#8311.
1df0a42a8c changed aspect-ratio from
floats to doubles, but forgot to change this function for
pretty-printing them as fractions for the video-aspect-override property
This specific option type is only used for the video aspect. The
underlying type was a float to represent the inputted value, but it's
actually not precise enough. When using something like 4:3, the values
of the incorrect digits are actually significant enough to make av_d2q
return a very funky numerator and denominator which is close to 4/3 but
not quite. This leads to some "off by one pixel" errors. Weirdly, mpv's
actual calculations for this were already being done as double, but then
converted to floats for this specific type. Just drop the conversion
step and leave it all as double which has the precision we need (i.e.
AVRational is now 4/3 for the this case). Fixes#8190.
983e8f0100 resulted in the correct
dimensions, but it was not actually right because vo_gpu_next still had
the src and dst rects the same. This just needs to work like how vo_gpu
does where the src is the image params and the dst is desired output. So
basically, just copy that code over here. Fixes#12108 and as a bonus,
overriding the aspect ratio now results in correct screenshots
(previously didn't work at now and then with the above commit it had
correct dimensions but still incorrect output).
The difference this makes is that the OS API will notice
when we underrun (as opposed to being fed silence).
Other AOs mostly seem to not do this because they've committed
to filling a buffer of a certain size no matter what, but I have
not observed any ill effects for AudioTrack in my testing.
This looks like a pretty bad bug but only became a problem
with the last commit that allows rates like 22.5kHz to pass through
directly instead of being resampled.
Using the width and height params directly doesn't actually work if PAR
is something other than 1. Instead, use mp_image_params_get_dsize and
calculate the correct dimensions which matches the vo_gpu behavior.
ffmpeg does not tag yuv levels for GRAY formats, but apparently they
should be infered as full range. Instead of defaulting to limited range
always. Fixes (M)JPEG playback.
This mimic ffmpeg's behaviour.
See: d295b6b693/libswscale/utils.c (L926-L962)Fixes: #12089
1 is not enough to prevent PL_QUEUE_MORE, because the pl_queue is
designed to always know the next frame (in addition to the current).
Before haasn/libplacebo@112bb886, this was was (wrongly) silently
omitted by the pl_queue code, but that fix exposed this.
While it's technically API misuse on mpv side, due to the mpv vo code
having its own internal queueing and timing control, it shouldn't
actually make any difference in practice (and likely, the error message
showing up is the only meaningful bug here - the issue is entirely
cosmetic).
Fixes: https://github.com/mpv-player/mpv/issues/12101
Configuration of filter parameters was moved from pl_filter_function (of
which the user had to make a copy) to pl_filter_config, with the
pl_filter_function remaining immutable.
Implement this new logic in a way that can reasonably exist side-by-side
with the old configuration API. Once we drop support for PL_API_VER
below 303, we can drastically simplify this code.
The win32 code already updates itself on dpi changes. However, it never
signalled mpv's core when this happened which meant that the
display-hidpi-scale property never changed. Simply send the
VO_EVENT_DPI event when appropriate. Fixes#12081.
Currently relative time parsing is buggy when any of the non-leading
units are non zero. For example, "-1:30" should result in -90 but
currently it results in -30 (as a result of `-60 + 30`).
Also reject timestamps where non-leading units are out of range. E.g.
"1:100" would be rejected, but "100" will still be accepted as 100
seconds.
In the same way that fallback in receive_frame() needs to be repeated
until we get a working decoder, we have to do the same thing in
reinit(). Calling force_fallback() only once can still yield a non
functional decoder.
The reason why we have these multiple paths which each require their
own fallback logic is that we can fail at different stages:
* hwdec init
* decoder init <- repeated fallback was missing here
* frame decoding
Fixes#12084
The manual currently says that if dscale is unset, --scale will be
applied. However, this only works at init time. If you change the dscale
filter to be empty later, vo_gpu will segfault and vo_gpu_next will
throw an error and refuse the changes. That's because when the option is
unset at runtime, the value becomes "" not NULL and the vo's never
accounted for this. Fixes#12031.
This is higher quality but comes with a slight performance hit,
especially for weaker iGPUs, so I don't want to enable it out of the box
even when --hdr-compute-peak=auto.
After second thought version.py does not do anything useful. Meson has
built-in function vcs_tag that mostly replicate what version.py did. For
the build time we can just use __DATE__ and __TIME__. Of course this
changes time string format a little, but in my opinion it looks nicer in
fact.
Also it will use local time, instead UTC. But I would argue that date
string is only informative for users to check how old the specific mpv
build is. It doesn't have to be precise, it weren't for years anyway
before recent change.
Get rid of the time during the while loop and just let this run forever
in case of a failure and also bump the timeout in meson to 60 seconds
since we know it is possible for msys to take a very long time on
occasion. That should be plenty of time for it to finish.
