Convenience to override name if imgfmt is not set.
Allows to create mp_image_params without setting imgfmt. Will be useful
for the next change where mp_imgfmt is not available. This is workaround
that will be remved once all codebase switches to pl_fmt.
mpv isn't really a game and categorising our App bundle as game seems
counterintuitive. though as a video player it does have some
similarities, possibly needing considerably CPU and GPU resources and
low presentation latencies.
the macOS Game Mode promises exactly that, it gives App the highest
priority access to CPU and GPU resources and lowers usage for background
tasks.
sadly the Game Mode can only be activated by categorising the App as a
game and that is only possible with an App bundle and not as a command
line tool.
only add the "Show log File…" menu item config when invoked from the
bundle, instead of testing on menu item creation. this is similar to the
touch bar menu items now.
keeping track of the dynamic menu items lets us directly access them by
key. we don't need to search in the config array for the right config
and menu item.
the check broke when the runtime check was removed, eg the menu item was
never added to the menu. since we only add the menu item to the config
when touch bar support is available the check is completely unnecessary.
Not sure if this is particularly useful, but we might as well generate
these as well. Also use the docutils wrapper since that's what the meson
build does.
Some incorrect syntax is used in DOCS/man/input.rst with c678033c1d
causing failure of PDF manual generation with rst2pdf. There are single
rather than double back-ticks for insert-at and insert-at-play so this
is fixed and a couple of typos are also corrected with this commit.
the render size cached in ctx->vo->dwidth/dheight can be outdated in
some circumstances at the time the context needs resizing. instead use
the current render size.
MoltenVK itself tries to work around a supposedly Metal problem that
itself causes flicker, black screens or broken rendering. it sets the
drawableSize to 1x1 to forcefully complete the presentation. though if
1x1 resolution frame is presented it causes a visual flicker or rather
a solid coloured frame. it causes even more problems since sometimes it
does not reset the drawableSize to the proper resolution and keeps
rendering everything in 1x1.
work around this workaround by discarding drawableSize that are <=1 in
any direction.
Fixes#13505
c2129c18f8 saves the button down serial to
pointer_serial of the seat so that it can be used for window dragging
later. However, this overwrites the serial saved at the enter event.
Since the serial in wl_pointer_set_cursor must be the latest
wl_pointer_enter serial number sent to the client, if a button down
serial overwrites that, setting cursor no longer works until the cursor
enters the window next time.
Fix this by using separate serials for these two types of events.
refqueue gets the field of the frame from mp_image which almost always(if not
always) assumes bottom field order first. By default this behavior should not
change but specifying the field order should bypass this.
Previously there was no way to specify the field order of interlaced videos
when deinterlacing with inbuilt filters. Lavfi deinterlacers seemed to prefer
top field order while inbuilt ones (vdpaupp, vavpp, d3d11vpp) seemed to prefer
bottom field order. The default "auto" option should work exactly as before
while specifying either "tff" or "bff" should force the specified field order
It's been a longstanding issue in wayland* that the first frame on a
hidpi screen will have wrong scaling. A well behaved client immediately
corrects this, but it's noticeable and also can affect window placement
due to the way resizng works. Preferred scale from the fractional
protocol and preferred buffer scale can actually solve this problem. It
depends on compositors mostly, but one could simply send the event
before the client maps its surface so it knows what the correct scale is
in the first place. I'm not sure if any compositors currently behave
like this (sway seems to still require the client to render before
sending any scaling information at least), but it makes to sense to
account for this possibility.
*: https://gitlab.freedesktop.org/wayland/wayland/-/issues/133
Ended up being too flawed and caused trouble in other areas. There's
other approaches to trying to solve the issue this meant to address in
the works that should be better, so let's wait on that. Fixes#13613 and
fixes#13622.
This reverts commit e3af545421.
This seems more robust than relying on the audio status to actually be
playing. For files where there is no audio or the audio start is
delayed, this guards against that but it allows the subtraction to
always occur otherwise on normal files with audio.
avif files will commonly be probed as "mov,mp4,m4a,3gp,3g2,mj2" by
ffmpeg, but demux_lavf currently has some logic to skip
avformat_find_stream_info for these kinds of files. It was introduced in
6f8c953042. Presumably, the optimization
of mentioned in that commit is still valid however for avif we
specifically need to do the avformat_find_stream_info call. Without it,
several codec proprieties like width, height, etc. are unavailable. So
just check the extension type and disable the skipinfo optimization.
Explicitly send an UP event after the client finishes a resize for
touch event, don't resize if locked_size is set for touch event,
and use the correct type for resize edges.
VOCTRLs are processed in the GUI thread through the mp_dispatch mechanism.
Window dragging requests are asynchronous on x11 and wayland, so the item
is processed quickly without problem. However, currently win32 uses the
SendMessage call for this, which is synchronous. This causes the playback
to stop while the dragging request is being processed because the
dispatch queue is blocked.
Work around this by setting a flag instead if the window dragging is
requested, and immediately starts dragging after processing the dispatch
queue. This doesn't block the dispatch queue while also avoiding any
extra latency added by the Windows message queue.
5736737750 removed the check because it was
not needed to prevent fullscreen window from being dragged. However, this
causes an undesirable behavior: when using a touch screen to drag a window
on Windows 11, DWM shrinks the window content a bit with an acrylic
backdrop to indicate that the window is being dragged. This also happens
when trying to drag the window in fullscreen. Add the check to prevent
this from happening.
Currently, VO dragging logic is hardcoded into each VO, where a left mouse
button down event unconditionally begins dragging if the VO dragging test
passes. This method is extremely unflexible as the VO has no knowledge of
what is happening in the input system: while begin dragging with the second
click of a doubleclick is undesired, it cannot determine whether a click
is a double click or not because it's determined by the input system.
The better way to do it is to handle it somewhere in the downstream
consumers of the events instead, as they have more information to make
this decision. The input system is the perfect place for this as the logic
for checking doubleclick already exists. So just issue a begin-vo-dragging
command if it detects a left mouse button down which isn't also a
doubleclick in this case, and delete all hardcoded VO dragging logic
in win32, x11, and wayland.
Note that this solution hardcodes left mouse button down for now, but
because the VO dragging is now centralized, it's possible to make more
improvements, such as a deadzone mechanism to fix the conflict with
MBTN_LEFT mouse bind.
