HDR or any color-space pass-through should be opt-in, as we cannot
control the user's compositor or display. Allowing HDR signals to be
pushed by default may lead to surprising results for some users.
Additionally, for an optimal experience, this option should be paired
with the target-peak of the display.
Make the pass-through opt-in and let the user decide if they want or
need it. By default, mpv should render a safe and consistent sRGB
output. mpv's tone mapping is generally of higher quality than any
external solution.
This reverts commit 23843b4aa5.
This update introduces a demux_packet_pool, allowing for the reuse of
previously allocated packets when needed.
sizeof(AVPacket) is not a part of the lavc public ABI, which prevents us
to allocate memory in larger blocks. However, we can substantially
decrease the amount of alloc/free operations during playback by reusing
both mpv's demux_packet and AVPacket.
This adjustment addresses the root cause of issue #12076, which,
although resolved upstream, did not fully tackle the persistent problem
of allocating small blocks of aligned memory. This issue largely stems
from the FFmpeg design of the AVPacket API. After this change memory
will no longer be allocated once cache limits is reached.
The demux_packet_pool is shared as a global pool of packets for a given
MPContext.
This change significantly speeds up the demuxer deinitialization,
benefiting file switching scenarios, especially when a large demuxer
cache is used.
See: #12294
See: #12563
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
When playing a video, 55% of CPU used in strlen, callgraph flip_page: ta_talloc_strdup_append ,
ta_talloc_asprintf_append and ta_talloc_strndup_append .
Before the fix: 2 fps when playing 1080p 24 fps video (--vo-kitty-use-shm=no),
24 fps after the fix.
video/out/kitty: move bstr cmd to priv
The options in vd_lavc are all related, but they don't all require the
same thing for runtime changes. To avoid having to manually add UPDATE_*
to every single option flag, the options can be split into two separate
structs. The vd_lavc_conf becomes a catch all for all the --vd-lavc
options that require the full UPDATE_VD flag. The rest of the options
are split off into the new hwdec_conf instead. Additionally,
--vd-lavc-software-fallback is renamed to --hwdec-software-fallback and
moved to the hwdec_conf as well. The new name better reflects what it
does and it logically fits with those more. UPDATE_* flags are added on
everything now so these should all now be changeable on runtime.
There's several path-related options that do not handle common shortcuts
(like ~/). Fix this by using mp_get_user_path where appropriate which
expands the path so users get more intuitive behavior. Fixes#15598.
This adds a "native" Wayland clipboard backend based on the
ext-data-control-v1 protocol.
This backend overcomes the limitation of the VO (Wayland core protocol)
backend, and does not require the presence of the VO window to receive clipboard
updates.
This backend also supports primary selection if supported by the compositor.
The backend runs in a separate thread, so clipboard reading
does not stall the player like the VO backend.
basically a copy of tsl0922/mpv-menu-plugin#77
if you have 200+ menu items and update `menu-data` about 400 times,
clicking menu item will not execute any command, the reason is that the
menu identifier greater than the max value of 16-bit unsigned integer.
1. make menu id always less than 0xF000 as mpv-player/mpv@861908c7 said
2. old menu items are never reused, should delete by DeleteMenu()
instead of RemoveMenu(), destroys the handle and frees the memory
If you have two seats connected, both with the pointer capability, and
use two hands to start a drag and drop operation with each pointer, then
move one pointer to the mpv window, then the other, mpv fails the
!wl->dnd_offer->offer assert in device.enter, because it expects that
the compositor wouldn't just call device.enter again before device.leave
or offer.finish.
The data device is per-seat, so this commit makes mpv track the data
device's offers per-seat rather than in vo_wayland_state, which makes
more sense and is easier to reason about when multi-seat is involved.
This is useful for text input in, for example, console.lua. Each
character in the commit string gets turned into an mpv key press.
Pre-edit strings are not handled, since there's currently no good way to
handle that or make it useful to text input scripts. Like win32, which I
tested in wine, another limitation is that the composition window is
always positioned at the top left of the window, since we cannot get
useful positioning hints from mpv scripts. It allows the composition
window to be within the window and avoids obstructing the console
prompt.
This can be enabled/disabled with --input-ime=<yes|no> (default: yes).
Some Wayland clients not offering text/plain will send their non-text
data regardless of the MIME type requested in wl_data_offer.receive. We
should just not call receive if they haven't offered a MIME type we
want.
Implement VOCTRL_GET_DISPLAY_FPS and VOCTRL_GET_DISPLAY_RES by returning
values obtained from Vulkan.
Currently, display fps and resolution info is not available in the
displayvk context. Display fps is needed for display sync to work
properly. The information is also used as the value of a few properties.
This slightly improves parity with the drm context.
When this was originally implemented, I lazily skipped the optimization
when using display sync because mpv would rip through all the frames
without waiting since there was no blocking. With the previous commits,
we now fall back on the audio sync logic when the window is not visible,
so the extra condition can be removed.
The previous commit put all the pieces in place so now this can be
implemented. Scheduling frames is already written with the assumption
that display sync maybe turn on/off at any time. So all that needs to be
done is check if the VO reports that it is not visible. If so, simply
flip mpctx->display_sync_active to false for that frame and skip the
display sync frame handling. It will become true again when the mpv
window comes back into view.
x11 and wayland VOs + backends all have logic that skips drawing frames
when the mpv isn't visible for efficiency reasons. This is implemented
in each individual VO, but it is useful for the core to be aware of this
as well. Currently, the display-sync modes on x11 do not try to be
efficient and always render anyways because there is no blocking on the
graphics API level if you skip rendering a frame (wayland works here by
accident). This means mpv would otherwise blaze through frames which is
not what anyone wants. We can instead improve this by implementing the
blocking mechanism in the core and using that when appropriate. This
commit does not implement that yet, but simply switches the draw_frame
to a boolean. Receiving false means that the VO is not drawing frames
and it should be treated as if the surface was hidden.
the equivalent options have been deprecated since mpv 0.35 in ac39661
and 2207236.
also bumping the MPV_CLIENT_API_VERSION to 2.5, since 2.4 was forgotten
in 6f619d5.
There were a few pitfalls with the way this was previously implemented
because --geometry implicitly depended on --auto-window-resize being
enabled to operate in a few cases. Instead, let's change the logic a bit
so that instead we choose whether or not to reuse the old rc (i.e. don't
resize) and use the wh_valid and xy_valid fields within the m_geometry
struct instead of using x11->geometry_change. This fixes several edge
cases involving setting the position with --geometry when using
--auto-window-resize=no.
This is still used for caclulating a/v sync and delay remaining even
for initial samples, so we should always update it to the actual vsync
for those initial samples so we have something to work with at least.
And if we receive bogus values, also reset it to 0 along with
prev_vsync.
Not having base_vsync set to _some_ value completely breaks
vsync_skip_detection, and mpv stays stuck in a permanent mistimed state
where every frame is marked as delayed and never recovers from it.
This is already done in WndProc, but the flag was not set if we exited
event loop and were processing mpv dispatch messages in fallback loop.
This fixes the case when Window is destroyed externally or otherwise
event loop fails for whatever reason. Calling vo_w32_uninit does call
DestroyWindow() through dispatch, which in turn calls WndProc, so we
need to guard recursive call.
This ignores --video-align-{x,y} when the video is smaller than the
window in the respective direction.
After zooming in, panning and zooming out, this is useful to recenter
the video in the window.
Unlike doing this by observing osd-dimensions in a script, this is done
before rerendering, so you don't see the image being rendered uncentered
for an instant after zooming out, before being rerendered centered.
Also update --video-align docs while at it.
This doesn't work well with --video-pan-{x,y} because you can move the
output rectangle far away from the image, and when zooming out pan is
abruptly reset to the center. It doesn't feel like natural like zooming
out after changing --video-align-{x,y}. So this commit doesn't set pan
to 0. Also this leaves a way to move scaled images within the window
even with --video-recenter.
Kacper Michajłow
sfan5
Sami Farin
Dudemanguy
Christoph Heinrich
nanahi
Attila Fidan
verygoodlee
Filip Hejsek
Neko Asakura
der richter
llyyr
Guido Cella