Other similar options are in the form of --foo-override not
--override-foo. The display-fps one was backwards so flip it around the
other way for consistency reasons.
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.
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.
In many cases, this is purely cosmetic because poll still only accepts
microseconds. There's still a gain here however since
pthread_cond_timedwait can take a realtime ts now.
Additionally, 37d6604d70 changed the value
added to timeout_ms in X11 and Wayland to ensure that it would never be
0 and rounded up. This was both incomplete, several other parts of the
player have this same problem like drm, and not really needed. Instead
the MPCLAMP is just adjusted to have a min of 1.
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 0c9ac5835b.
Fixes: #12575
fbe154831a 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.
When implementing vo_dmabuf_wayland, it always did a copy of the image
from the current frame and worked with that. The reason was because
mpv's core held onto the frame and caused some timing issues and
rendering glitches depending on when it freed the image. This is pretty
easy to fix: just make vo_dmabuf_wayland manage the the frames. In vo.h,
we add a boolean that a VO can set to make them manage freeing frames
directly. After doing this, change the buffers in vo_dmabuf_wayland to
store the whole vo_frame instead of just the image. Then, just modify
some things a bit so frame is freed instead of the image. Now, we should
truly have zero-copy playback. Well as long as you don't use libass to
render anything (that's still a copy from system memory).
0739cfc209 added the draw_frame API
deprecated draw_image internally. VOs that still used draw_image were
around, but really there's no reason to not just "upgrade" them anyway.
draw_frame is what the "real" VOs that people care about (gpu/gpu-next)
use. So we can just simplfy the code a bit now. VOCTRL_REDRAW_FRAME is
also no longer needed so that can be completely deleted as well. Note
that several of these VOs are legacy crap anyway (e.g. vaapi) and maybe
should just be deleted but whatever. vo_direct3d was also completely
untested (not that anyone should ever use it).
This causes only problems, because we convert mp_time to realtime, which
is not atomic, so we introduce error. And even though on sane platforms
it should work fine, after all the sleep time is in the past.
winpthreads like to sleep for like over 10ms when the time is less than
current time, but not more than 1s.
296d40dc6f changed how the vo handled
redraw requests in order to fix a race condition that can occur with
pausing. However, there was a slight oversight because a redraw request
that occurred while the core was unlocked and the video was still
playing would still be kept true (previously, this was always cleared).
That redraw is essential if mpv is paused otherwise the old issue comes
back, but if the video is playing it's unnecessary since the next loop
around will simply draw whatever we needed. The extra redraw could cause
a frame drop for some people in certain instances, so the solution is to
simply always clear redraw requests if !in->paused. This eliminates the
extra redraw but still keeps it when pausing.
Fixes#12426 and fixes#11579.
So strangely enough, estimated_vsync_interval is stored as a double but
nominal_vsync_interval is not and neither is the vsync_interval. Those
are stored as int64_t. This loss of precision can matter even in common
cases. For instance, take a typical 60 Hz monitor. Instead of 16666.6666
(repeating) being calculated as the vsync interval, you would get 16666
since the decimals are truncated. This is not really good at all and
affects the calculated speed values you get when using display sync. For
consistency and better precision, these should all be doubles just like
estimated_vsync_interval. Technically this means that we won't be able
to store as high of an integer value but such values would be absurdly
huge and never actually needed. Also estimated_vsync_interval already
can't handle such a case anyway.
libplacebo doesn't like it when the queue_params PTS is less than the
actual PTS of the frame for the first frame and skips mixing it during
interpolation. This can happen if you seek while paused because mpv will
always keep the vsync_offset value as if it was still playing. So in
some cases, this can be a negative value and thus the PTS will end up
decreasing and libplacebo interprets this frame as a first frame. This
skips mixing the frame and thus you get a black screen. To fix this
this, just realize that vsync timings are completely meaninglessly in
while paused. If you are not actively pushing frames, there's no reason
to care about vsync_offset. So just clear it and make it zero when the
VO's internal state is paused and we're trying to render a frame. Makes
libplacebo happy and fixes#11958.
this changes mp_image_new_ref() to handle allocation failure itself
instead of doing it at its many call-sites (some of which never checked
for failure at all).
also remove MP_HANDLE_OOM() from the call sites since this is not
necessary anymore.
not all the call-sites have been touched, since some of the caller might
be relying on `mp_image_new_ref(NULL)` returning NULL.
Fixes: https://github.com/mpv-player/mpv/issues/11840
There is a very subtle race in vo that can manifest itself on pause
events. In the renderloop, render_frame, unsurprisingly, does the heavy
lifting of actually queuing up and flipping the frames. This is called
during normal playback. Sometimes various parts of the player can make a
redraw request which will latter trigger another render of the frame
later down in the loop (do_redraw). Because these requests can happen at
essentially anytime, sometimes the redraw request will happen *before*
do_redraw and it'll be caught in render_frame. When this happens,
the existing render_frame run works perfectly fine as a redraw so it
clears out the request which is sensible. Normally this is all locked of
course, but there's one catch. render_frame has to unlock itself when
propagating down into specific VOs/backends. That's what causes this
bug.
While render_frame is unlocked, other parts of the player can send
redraw requests which will cause in->request_redraw to become true. The
logic in the code always clears out this parameter after a successful
render, but this isn't correct. When in->request_become becomes true in
the middle of render_frame, there needs to be one more draw afterwards
to reflect whatever actually changed (usually the OSD). Instead, this
gets simply discarded. If you rapidly spam pause while rendering things
to the OSD at the same time, it's possible to for the last render to
be behind a frame and appear as if your osd event was ignored.
Once you realize what is happening, the fix is quite simple. Just store
the initial value of in->request_redraw before the unlock step. After we
do the render step and unlock again, only set in->request_redraw to
false if there was an initial redraw request. We just finished doing a
redraw, so it is safe to clear. Otherwise, leave in->request_redraw
alone. If it is initially false, then it will still be false and nothing
changes. However if it updated to true in the middle of the rendering,
this value is now preserved so we can go and call do_redraw later and
show what that last frame was meant to be when you pause. One
unfortunate thing about this design is that it is technically possible
for other internal things in vo to update during that unlocked period.
Hopefully, that doesn't actually happen and only redraw requests work
like this.
Fixes#8172 and #8350.
See https://sw.kovidgoyal.net/kitty/graphics-protocol/
This makes no attempt at querying terminal features or handling
terminal errors, as it would require mpv to pass the response codes
from the terminal to the vo instead of interpreting them as
keystrokes made by the user and acting very unpredictably.
Tested with kitty and konsole.
Fixes#9605
Wayland VO that can display images from either vaapi or drm hwdec
The PR adds the following changes:
1. a context_wldmabuf context with no gl dependencies
2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects
no-op because there is no need to map/unmap the drmprime buffer,
and there is no need to manage any textures.
Tested on both x86_64 and rk3399 AArch64
This driver makes use of dmabuffer and viewporter interfaces
to enable efficient display of vaapi surfaces, avoiding
any unnecessary colour space conversion, and avoiding scaling
or colour conversion using GPU shader resources.
Render subs at the output resolution, rather than the video resolution.
Uses the new APIs found in libplacebo 197+, to allow controlling the OSD
resolution even for image-attached overlays.
Also fixes an issue where the overlay state did not get correctly
updated while paused. To avoid regenerating the OSD / flushing the cache
constantly, we keep track of OSD changes and only regenerate the OSD
when the OSD state is expected to change in some way (e.g. resolution
change). This requires introducing a new VOCTRL to inform the VO when
the UPDATE_OSD-tagged options have changed.
Fixes#9744, #9524, #9399 and #9398.
Ever instance of m_obj_list is a constant and for all of them, the field
is true. Just remove the field all together.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
As discussed in #8799, this will eventually replace vo_gpu. However, it
is not yet complete. Currently missing:
- OpenGL contexts
- hardware decoding
- blend-subtitles=video
- VOCTRL_SCREENSHOT
However, it's usable enough to cover most use cases, and as such is
enough to start getting in some crucial testing.
Based on the implementation of ffmpeg's sixel backend output written
by Hayaki Saito
https://github.com/saitoha/FFmpeg-SIXEL/blob/sixel/libavdevice/sixel.c
Sixel is a protocol to display graphics in a terminal. This commit
adds support to play videos on a sixel enabled terminal using libsixel.
With --vo=sixel, the output will be in sixel format.
The input frame will be scaled to the user specified resolution
(--vo-sixel-width and --vo-sixel-height) using swscaler and then
encoded using libsixel and output to the terminal. This method
requires high cpu and there are high frame drops for 720p and
higher resolution videos and might require using lesser colors and
have drop in quality. Docs have all the supported options listed
to fine tune the output quality.
TODO: A few parameters of libsixel such as the sixel_encode_policy
and the SIXEL_XTERM16 variables are hardcoded, might want to
expose them as command line options. Also the initialization
resolution is not automatic and if the user doesn't specify the
dimensions, it picks 320x240 as the default resolution which is not
optimal. So need to automatically pick the best fit resolution for
the current open terminal window size.
We've had some serious issues with GNOME in the past, but since then
their compositor has undergone some major internal improvements. The
most severe one [1], random vsync spikes and mistimed frames, can no
longer be reproduced by the original author of the issue. There are some
minor UI-related things (lack of window decorations for instance since
there is no xdg-decoration support), but users don't seem to complain
about that too much and they aren't revelant to playback.
3.38 isn't out quite yet, but that should also fix playback issues when
on a multimonitor setup (the fix is in the master branch at the moment).
In terms of playback, the only real concerning issue is the lack of idle
inhibit so a warning is still displayed. But GNOME has their own
workaround that users can use for that so if anyone happens to complain,
we can just point them to that.
[1] https://gitlab.gnome.org/GNOME/mutter/-/issues/957
Commit 6a13954d67 lowered the frequency of wakeups with this
condition. But it seems it sometimes the audio sync mode really should
get the wakeup before the frame is rendered. Normally, vo_thread is
supposed to perform this wakeup. Now the wakeup frequency is twice of
what should be needed - whatever, maybe it can be fixed properly once or
if timing is moved to the VO entirely in the future.
Fixes: #7777 (probably, untested)
This was not intended to be committed in 0e3f893606. It disables
the extra wakeup if working==true. I've convinced myself that the wakeup
was really needed at the time, so no idea how I didn't notice this until
someone pointed it out on the commit diff on github (lol).
The caller of render_frame() re-iterates without waiting if this
function returns true. That's normally meant for DS, where we draw
frames as fast as possible to let the driver perform waiting.
In display-sync mode, the core doesn't need to woken up every vsync, but
only every time a new actual video frame needs to be queued. So don't
wake up if there are still frames to repeat.
In audio-sync mode, the wakeup is simply redundant, since there's a
separate timer (in->wakeup_pts) to control when to queue a new frame. I
think.
This finally brings the required playloop iterations down to almost the
number of video frames. (As originally intended, really.)
Also a fairly risky change.
The wakeup at the end of VO frame rendering seems redundant, because
after rendering almost no state changes. The player core can queue a new
frame once frame rendering begins, and there's a separate wakeup for
this. The only thing that actually changes is in->rendering. The only
thing that seems to depend on it and can trigger a wakeup is the
vo_still_displaying() function. Change it so that it needs an explicit
call to a new API function, so we can avoid wakeups in the common case.
The vo_still_displaying() code is mostly just moved around due to
locking and for avoiding forward declarations.
Also a somewhat risky change (tasty new bugs).
Add an infrastructure for collecting performance-related data, use it in
some places. Add rendering of them to stats.lua.
There were two main goals: minimal impact on the normal code and normal
playback. So all these stats_* function calls either happen only during
initialization, or return immediately if no stats collection is going
on. That's why it does this lazily adding of stats entries etc. (a first
iteration made each stats entry an API thing, instead of just a single
stats_ctx, but I thought that was getting too intrusive in the "normal"
code, even if everything gets worse inside of stats.c).
You could get most of this information from various profilers (including
the extremely primitive --dump-stats thing in mpv), but this makes it
easier to see the most important information at once (at least in
theory), partially because we know best about the context of various
things.
Not very happy with this. It's all pretty primitive and dumb. At this
point I just wanted to get over with it, without necessarily having to
revisit it later, but with having my stupid statistics.
Somehow the code feels terrible. There are a lot of meh decisions in
there that could be better or worse (but mostly could be better), and it
just sucks but it's also trivial and uninteresting and does the job. I
guess I hate programming. It's so tedious and the result is always shit.
Anyway, enjoy.
When frame-stepping with display-sync mode enabled in high framerate
video, the frame was sometimes not redrawn correctly. Only the first OSD
interaction (or something similar) made it visible.
In this case, the core schedules many frames as dropped (because it's
ignorant of pausing/frame-stepping, as in theory the player is _not_
paused during frame-stepping, only at the end of it). There's a race
between the VO rendering the queued frame, and the core calling
vo_set_paused() after it has queued the frame. If the latter happens
first, the existing logic to redraw the previous dropped frame does
things correctly. If the former happens, the frame is not redrawn
automatically, but will be redrawn on the next user input (or if OSD is
enabled, and the pause state change updates it, which leads to an
immediate redraw).
Fix this by never actually dropping a frame in paused mode. The request
by the core to drop it is simply ignored.
Maybe this could be done slightly nicer by updating the pause state with
the VO atomically. Then we wouldn't have the frame drop counter going up
either (it's actually dropped, but then redrawn; but I doubt any user,
or me in a few weeks, would understand this). But I'm not really
interested in polishing this by increasing the complexity of the
frame-step code.
- remove VOCTRL_FULLSCREEN and VOCTRL_GET_FULLSCREEN
- have your own m_config_cache for the fullscreen option
(vo->opts_cache cannot be used because you lose per-option change
notifications, and it'd be a mess anyway)
- use VOCTRL_VO_OPTS_CHANGED to update it
(it's used for convenience)
- when updating it, check for the fullscreen option
(wasn't sure how to do it best; currently, it compares the raw
option pointers, but this could be changed)
- do not send VO_EVENT_FULLSCREEN_STATE on FS change
- instead write the option on FS change
(assign in opt. struct + m_config_cache_write_opt)
