The VO generic code tries to be helpful and resets this after
each reconfig. However for the simpler VOs the target params
are constant after a reconfig or even for the entire lifetime.
So it's clearly better to let the VO decide.
This also allows the VO to use a static buffer instead.
this partially reverts commit 7b5a258. back then the only properly
working vo on macOS was cocoa-cb (libmpv). it would always use the
deprecated opengl cocoa backend or no vo at all. because of that libmpv
was moved to the top of the auto-probing order, so the preferred vo
was used on macOS only.
we now have a working vulkan gpu/gpu-next backend on macOS which should
be the new default vo. though disabling the auto-probing again for
libmpv would probably cause the undesired behaviour on macOS that
cocoa-cb would never be auto selected again. especially if not build
with vulkan support or without vulkan driver on macOS, this would lead
to no video output at all. so instead of completely reverting the
mentioned commit, we instead move libmpv to the bottom of the
auto-probing order but only auto select it when mpv was built with
cocoa-cb support. this restores the previous behaviour on all other
platforms besides macOS, but also lets us auto select cocoa-cb if
supported.
Since 03cf150ff3, the only purpose of this
VOCTRL was to signal a redraw to the vo. It actualy could have been
removed in 531868fe0d, but this was
missed. The UPDATE_VIDEO flag is better anyway because it allows us to
handle a wide variety of options scattered around that require the VO to
update itself and redraw. We can remove both of the custom callbacks in
vo.c and only leave the VOCTRL_VO_OPTS_CHANGED one. Additionally, that
commit also introduced vo_set_want_redraw, but this is redundant and not
needed. The VOs that use VOCTRL_UPDATE_RENDER_OPTS already set
vo->want_redraw, and those are the only VOs where these options are
relevant in the first place. So we can remove this as well and just let
the big callback in player/command do everything.
This avoids clearing the queued frame and the currently displayed one on
VO reconfiguration requests that happen when new frames arrive. Instead,
let those frames be fully displayed.
Fixes mf:// playback issues introduced after commit ef11d31.
Instead of removing the frame timing check embrace and fix it to wake up
the playloop as needed. The frame display duration is problematic to
handle as both VO and playloop thread would already be sleeping, but in
certain use cases it is needed to display frames in full, so in this
case, let the VO sleep to the end of frame, wake up the core as
requested and go back sleeping.
Note that this patch series reintroduces 0c9ac5835, which is esenitally
fixed in this commit. It is still not perfect, but it is better than
just busy waiting on playloop, even if those events when this would be
needed are quite rare.
vo_rpi and its related code has pretty much historically been a
disaster in mpv. The build regularly gets broken and since nobody uses
it, it takes months for anyone to notice. There was also that time where
fullscreen was broken for about a year and a half. Also building in waf
was entirely broken for about a couple of years or so due to mysterious
reasons no one ever figured out (meson magically fixed it).
Anyways, once again the build is broken due to rpi being forgotten about
again, but instead of pretending to support this crap. Just drop it all.
Nowadays, mmal hwdec is a relic since these devices are better off using
the v4l2m2m ffmpeg fork instead which actually uses KMS properly. RPI 1
and 2 probably can't do this and will remain broken but oh well blame
Broadcom for being special snowflakes and not using standard APIs (my
rockpro worked out of the box; just saying). RPI 2 is nearly 10 years
old anyways, so I think you can afford a new SBC by now. If we were
nicer, there would be a deprecation period, but this is broken in the
last major release anyway so too late.
Closes#13402.
When adding things like brightness or gamma, the video obviously needs a
redraw if paused. This happened to work in the normal case because the
OSD notification triggered a redraw, but if you use no-osd the picture
won't change. Fix this by adding another option flag, UPDATE_VIDEO, and
simply signalling we want a redraw. This gets handled along with the
normal osd redrawing check in the playloop so something like "no-osd add
gamma 1" actually works.
7b8a30fc81 made it possible for a VO to
have direct ownership of frame objects since the it may be beneficial
for the frame to follow the lifecycle of that particular VO instead
(i.e. the wayland compositor for dmabuf-wayland). But when frames are
dropped, this always has to be unconditionally freed since the VO isn't
aware of it. Fixes#13364.
This mostly is added to resolve player command synchronization with VO
thread discussed in 477a0f83.
The current uses does not necessarily need this as they are all managed
by playloop. But for future use with other params that will be handy.
Those params are mostly to observe current state of VO and does not
necessarly need to be locked along with frame drawing, that changes the
params once at the end.
The `current_frame` can be redrawn even if the remaining `num_vsync` is
equal to 0. In this scenario, the vsync offset would be incremented
beyond the target point.
This filters out vastly inaccurate values from presentation feedback
that can happen shortly after restarting playback or seeking.
Makes estimated vsync converge almost instantly instead of waiting
until those outliers are dropped from the past samples.
Relative to frame PTS timeline as oposed to display vblank.
Those values are relative to unadjusted video timeline. They will be
used by gpu-next where it expect virtual frame vsync, not display vblank
time.
Most importantly, the wait_until addition was missed while doing the
unit conversions to nanoseconds which meant mpv woke up roughly every
second since not nearly enough time was added. It was meant to be 1000
seconds (1e9 in microseconds). Use a macro so it's more readable. Also
put some other wild 1e9 calculations inside of a macro as well.
Fixes a899e14bcc.
Currently VOCTRL are completely unusable for frequent data query. Since
the HDR parameter addition to video-params, the parameters can change
each frame. In which case observe on those parameter would be triggered
constantly. The problem is that quering those parameters involves VOCTRL
which in turn involves whole render cycle of delay.
Instead update VO params on each draw_frame. This requires changes to VO
reconfiguration condition, but in practice it should only be triggered
when image size or data layout changes. In other cases it will be
handled internal by VO driver.
I'm not quite happy with this solution, but don't see better one without
changing observe/notify logic significantly. There is no good way
currently to handle VOCTRL that are constantly queried.
This adds unfortunate synchronization of player command with VO thread,
but there is not way around that and if too frequent queries of this
param becomes a problem we can thing of other solutions.
Changes the way to get data from VO driver added by a98c5328dc
Fixes: 84de84bFixes: #12825
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
