| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Avoids the 2 unneeded return values of string.find().
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
b388c735408af1a78e8f6165fa3af31bc623ef8f should have deleted this line
since the insert is done a little below it instead, but it was missed
during review.
|
|
|
|
|
| |
https://github.com/yt-dlp/yt-dlp/security/advisories/GHSA-v8mc-9377-rwjj
https://github.com/yt-dlp/yt-dlp/commit/1ceb657bdd25
|
|
|
|
|
|
|
|
|
|
|
|
| |
since i was going to fix the include order of stdatomic, might as well
sort the surrouding includes in accordance with the project's coding
style.
some headers can sometime require specific include order. standard
library headers usually don't. but mpv might "hack into" the standard
headers (e.g pthreads) so that complicates things a bit more.
hopefully nothing breaks. if it does, the style guide is to blame.
|
|
|
|
|
|
|
| |
replace it with <stdatomic.h> and replace the mp_atomic_* typedefs with
explicit _Atomic qualified types.
also add missing config.h includes on some files.
|
|
|
|
|
| |
even msvc (which mpv apparently doesn't support) supports C11 atomics
now. no need to carry around fallback with subtle semantic differences.
|
|
|
|
|
| |
It is useless to show this because it's just a bogus value taken from
--mf-fps.
|
|
|
|
|
|
|
|
| |
To avoid switching to scientific notation. Apparently it is "jarring"
for some users.
This preserves status quo from before 9dddfc4f where pretty printer were
truncated to 3 decimal places.
|
|
|
|
|
|
|
|
|
| |
With the previous series of commits, all internal usage has been
replaced by the nanosecond functions. There's not really any point in
keeping these around anymore plus there are macros for unit conversions
now so we can just axe them. It's worth noting that mpv_get_time_us()
obviously still needs to work for API reasons, but we can just divide
mp_time_ns() by 1000 to get the same thing.
|
|
|
|
| |
No change in the actual API.
|
|
|
|
|
| |
The playloop is the only thing that adjusts the timeout with a value
other than 0, so nothing else needs to be changed.
|
|
|
|
|
|
|
| |
The whole mess with setting the option value explictly and saving the
old stop_play value only needs to happen if we're at the end of file.
Doing it in general is unneccessary and breaks other things.
Fixes #12424.
|
|
|
|
|
|
| |
These are ancient and have existed since before stats.lua lived in the
mpv repository. We don't need to worry about ancient mpv versions
anymore, so remove these.
|
|
|
|
|
|
|
|
|
| |
The text didn't line up with with the percentages above it because it
didn't use a monospace font.
Instead insert the text at the same position in the template as the
percentages and convert one o.prefix_sep from the percentages into hard
coded \h\h to ensure alignment even when the user changes o.prefix_sep.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Use "%.7g" to show 7 significant digits. Removes the trailing zeros, and
in general makes it more readable, than fixed 3 decimal digits.
For avsync use "%+.2g" to add plus sign, similar to display-sync
values.
|
|
|
|
|
| |
There is already other place to indicate hw decoding. "cuda" or "d3d11"
is not a pixel format.
|
|
|
|
| |
Makes it more readable in my opinion.
|
| |
|
|
|
|
|
|
| |
- rename prefix to `Framerate:`
- if both estimated and specified values are the same display fps once
- skip the suffix if both the estimated and specified values agrees
|
| |
|
|
|
|
|
| |
SDR white (203) is indeed not interesting, but anything else, even if
lower is.
|
|
|
|
|
|
|
|
| |
Source video parameters are interesting, but we mix them with video
output/target parameters. Which will differ. Add "Display" showing
true output params from VO, including HDR passthrough info and
everything. This makes much more consistent output and alows to quickly
diagnose how is source video translated to target display.
|
|
|
|
| |
fps property was not renamed in events.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was wrongly assuming that playlist_path is always set for the
current playlist entry, but it's only set when a file was added by
expanding a playlist.
The crash in playlist_get_first_in_next_playlist can be reproduced with
mpv foo.mkv foo.zip, playlist-next, playlist-prev,
playlist-next-playlist. You need to run playlist-next, playlist-prev
first because foo.zip's playlist_path is NULL until you do that, which
makes playlist_get_first_in_next_playlist return immediately.
The crash in cmd_playlist_next_prev_playlist can be replicated with mpv
--loop-playlist foo.zip foo.mkv, running playlist-next until foo.mkv,
and playlist-play-next. Again, you need to open foo.zip first or its
playlist_path is NULL which skips running strcmp(entry->playlist_path,
mpctx->playlist->current->playlist_path).
Fixes https://github.com/mpv-player/mpv/issues/12495#issuecomment-1760968608
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Use EDL for single tracks with metadata to set the uploader, channel url
and description metadata with --ytdl-format=best. Currently, these are
only set with the other ytdl formats with video and audio in different
streams.
The uploader tag is commonly available in sites other than Youtube too,
so it may be simpler to always use EDL with single tracks.
|
|
|
|
|
|
|
|
| |
Added to the functions `mp.add_timeout` and `mp.add_periodic_timer`.
If the `disabled` argument is set to `true` or a truthy value, the
timer will wait to be manually started with a call to its `resume()`
method.
|
|
|
|
|
|
| |
9606c3fca9d568dc43711017dcb35a408c0d2883 added mp_time_ns(). Since we
apparently expose the mp_time_us() to clients already, there's no reason
to not also expose the new nanosecond one.
|
| |
|
| |
|
|
|
|
|
| |
This is weird. The caller should be responsible for converting the value
if desired. Move the conversion to player/command.c instead.
|
|
|
|
|
| |
This binding commonly closes similar input buffers like vim's
Command-line mode and dmenu.
|
|
|
|
|
|
|
|
|
|
|
|
| |
playlist-prev-playlist goes to the beginning of the previous playlist
because this seems more useful and symmetrical to
playlist-next-playlist. It does not go to the beginning when the current
playlist-path starts with the previous playlist-path, e.g. with mpv
--loop-playlist foo/, which expands to foo/{1..9}.zip, the current
playlist path foo/1.zip beings with the playlist-path foo/ of {2..9}.zip
and thus playlist-prev-playlist goes to 9.zip rather than to 2.zip.
Closes #12495.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Lines that would be outside of the visible area are now culled.
The log messages were already culled, however with the introduction
of suggestions, they also needed a small update.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Completion suggestions are now nicely formatted into a table.
Maximum width of the table is estimated based on OSD size and
font size.
This requires a new scaling factor option `font_hw_ratio`.
A factor of 2.15 works great for me,
but the default is 2.0 to avoid problems with other fonts.
The space between columns is automatically adjusted to be
between 2 and 8 spaces.
It tries to use as few rows as possible.
|
|
|
|
|
|
|
| |
Tab completion now shows a list of all potential completions
between the log messages and prompt.
The text is colored to differentiate it from regular text.
The color matches the theme and is similar to the mpv logo.
|
|
|
|
|
|
|
| |
The text styles are now in a table.
The color definitions of the theme where the colors were taken from
are now included in a comment for future reference.
The colors have been converted to BGR as is required by ASS.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
vo_still_displaying() is racey with vo_request_wakeup_on_done() and above
that it doesn't work as expected. VO can run out of work and go to sleep
for 1000s, while the play thread still returns on vo_still_displaying()
check, because of a check `now < frame_end` so it never advances and go
to sleep itself.
This fixes dead lock that we have when image parameters changes during
playback.
This reverts commit 0c9ac5835be70ae26e4aa875e833fe2c7b3b3bf3.
Fixes: #12575
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fbe154831a8addfc18a4f81e1c4b9284c31acace added a new VOCTRL to signal
when the OSD changed for gpu-next's handling of subtitles, but this is
both not necessary and actually incomplete. The VOCTRL would signal OSD
changes, but not all subtitle changes (like selecting another
non-external sub track for example). VOCTRL_OSD_CHANGED was used to
increment p->osd_sync which would then redraw the blended subtitles if
the player was paused.
But there's already a VOCTRL_PAUSE and VOCTRL_RESUME. Plus, the
sub_bitmap_list object will have items in it if it changed in any way,
so we don't need the VOCTRL_OSD_CHANGED method at all. That can be
removed.
The check that fp->osd_sync < p->osd_sync stays in place since that's an
optimization while the video is playing, but we also check the pause
state as well since the VO can know this. If we're paused, then always
do update_overlays since core must be signalling a redraw to us if we
get a draw_frame call here. Additionally in update_overlays itself, the
p->osd_sync counter is incremented if we have any items since the frame
signature will need that. As for the actual bug that is fixed, changing
subtitle tracks while paused with blended subtitles now correctly works.
Previously, it was never updated so the old subtitle stayed there
forever until you deselected it (since VOCTRL_OSD_CHANGED triggered
there).
Also include some cosmetic code fixes that were noticed.
|
|
|
|
|
|
| |
e277fadd60350caad1fc31e92a5076692e61dcc9 originally added this but it
never actually did anything in the function... wm4 probably changed his
mind but forget to delete it so just remove it here.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
2c6a3cb1f27e02b2e66390a2465ab648905a64d0 originally added this struct
member and then 1be863afdbe9017aa227234e8525b209fb818224 later added
some more logic to loadfile that uses this. There's been more changes
since then of course, but bits using playback_short and playback_start
have mostly stayed the same. It's a bit strange it's worked this way for
so long since it makes an assumption on how long files should be and
leads to weird, broken behavior on playlists with shorter videos. The
main reason for playlist_short, as far as I can tell, is to deal with
some fringe cases with short videos and trying to go back in the
playlist. More specifically, if you use --loop=inf on a very short video
(say less than 1 second) and try to go back in the playlist, you won't
be able to without any of this special logic that deals with it. But the
current approach has several side effects like going back multiple items
in the playlist instead of just one if the video is less than one
second. This is just bad so delete everything related to playlist_short
and playlist_start.
Instead, let's handle this by keeping track of playlist-prev attempts.
Going forward in the playlist doesn't require any special handling since
a bad/broken file will just advance to the next one. So it's only going
backwards that requires some special consideration. If we're going
backwards and the user isn't using force, then mark the playlist entry
with a special flag. If the file loads successfully in
play_current_file, we can just clear the flag and not worry about it.
However if there's a failure, then we set a bool telling
play_current_file that it should go back one more item in the playlist
if possible and try again. This way, we avoid the previously mentioned
--loop=inf edgecase and the user can still attempt to retry previously
failed items in the playlist (like a url or such).
Fixes #6576, fixes #12548.
|
|
|
|
| |
fixes: #11180
|
|
|
|
|
| |
I made a mistake in 0070a5820e here because there were 2 separate groups
of "front" filenames.
|
|
|
|
|
|
|
|
|
|
| |
Combine the cover art whitelist with the extensions in
--cover-art-auto-exts instead of hardcoding them. This is shorter,
checks for more extensions, saves us from updating the whitelist
everytime we add a new image extension, and since the whitelist had
gotten so big and the priority is calculated as
MP_ARRAY_SIZE(cover_files) - n, files like cover.jpg were taking
priority over cover art loaded by --cover-art-auto=exact.
|
|
|
|
|
|
|
|
| |
The stream selection state wasn't improved. I didn't realize this messed
with caches. All in all, just not a good idea. Back to drawing board I
guess.
This reverts commit f40bbfec4fcd2d9a787a4d98ec7698a646e5607e.
|
|
|
|
|
| |
There is no reason to use microseconds precision. We have precise timers
all all relevant platforms.
|