If imgfmt is a hwaccel format, hw_subfmt will contain the CPU equivalent
of the data stored in the hw frames.
Strictly speaking, not doing this was a bug, but since hwaccel formats
were tagged with MP_IMGFLAG_YUV, it didn't have much of an impact.
For example, previously, --audio-device='alsa/' would provide ao->device="" to
the alsa driver in spite of the fact that this is an already parsed option. To
avoid requiring a check of ao->device[0] in every driver, make sure this never
happens.
even though the mouse doesn’t move relative to the window itself, when
the window is being dragged, some outliers are still reported and
trigger the OSC.
fixes the case when mpv is opened and the cursor is within the window
bounds without moving the mouse. previously the window could only be
dragged around after the first mouse movement.
Currently, tracks have always associated streams, so there can't be a
NULL dereference on the next line. But all the code is written with the
possibility in mind that we might want tracks without streams, so make
it consistent.
Found by coverity.
Not so important by itself, but important for when we replace the vf
libavfilter wrapper with the common implementation. (Which will
hopefully happen, but not too soon.)
Preparation for enabling hw filters. mp_image_params can't have an
AVHWFramesContext reference (because it can't hold any allocations, and
isn't meant to hold "active" data in the first place.
So just use a mp_image. It has all real data removed, because that would
essentially leak 1 frame once the decoder or renderer don't need it
anymore.
Not needed under any circumstances. While the Windows ones export
functions to which we must link, these functions are always available,
even if libavcodec was compiled with D3D disabled.
hw_vaapi.c didn't do much interesting anymore. Other than the function
to create a device for decoding with vaapi-copy, everything can be done
by generic code. Other libavcodec hwaccels are planned to provide the
same API as vaapi. It will be possible to drop the other hw_ files in
the future. They will use this generic code instead.
This was a hack to let libmpv API users pass a d3d device to mpv. It's
not needed anymore for 2 reasons:
1. ANGLE does not have this problem
2. Even native GL via nVidia (where this failed) seems to not require
this anymore
even before the recent refactor the cursor was hidden when moving it to
the top of the screen in fullscreen and placing it on top of the now
visible menu bar.
we need to know when the menu bar is hidden so we don’t create a
‘dead zone’ at the top of the screen where the cursor can’t be hidden.
to determine when the menu bar is visible, and with that the title bar,
we get the height of the menu bar. the height is always 0 when hidden.
furthermore there is no way to get the title bar directly and with that
its height. so we calculate the frame rect of a NSWindowStyleMaskTitled
window from a CGRectZero content frame. the resulting height is the
height of a title bar.
with that we can exclude the top area for the cursor hiding and can be
certain when the menu bar is not hidden.
the cursor couldn’t be hidden when the cursor was at the same position
as the Dock, even if the cursor was next to it. this is especially
annoying in fullscreen since the Dock isn’t actually hidden but is still
reported as being visible. this basically made the part of the screen,
where the Dock resides, a ‘dead zone’. so instead of using the
visibleFrame we will just use the normal frame. there is no problem at
the top area of the screen, since a window can’t be placed above the
menu bar and in fullscreen the menu bar is always reported as not being
on screen.
i suspect this was done so the cursor wasn’t hidden when the it was
placed above the Dock when windowed. with the recent refactor this is
not needed any more.
we can simplify the code because we don't need to change the bool
pointer we were given by the VOCTRL_SET_CURSOR_VISIBILITY event. i
assume this was done to work around some bugs previously to the recent
cursor refactor. i kept that because i thought it was necessary, which
wasn't in the end. after the refactor it only caused some weirdnesses i
tried to work around. without it we can get rid of some special cases
and simplify the code quite a bit.
Implements --hwdec=videotoolbox on iOS. Similar to hwdec_osx.c, but
using CVPixelBuffer APIs available on iOS instead of the equivalent
IOSurface APIs in macOS.
We can drop the custom table.
For some reason, the interop does not accept GL_RGB_RAW_422_APPLE as
internal format for GL_RGB_422_APPLE, so switch the format table to use
GL_RGB (this way both interop and real textures work the same).
Another victim of the apparent requirement of exactly matching texture
formats is kCVPixelFormatType_32BGRA. vo_opengl wants to handle this as
normal RGBA texture, with a swizzle applied in the shader.
CGLTexImageIOSurface2D() rejects this, because it wants the exact
internal format. Just drop the format, because it's useless anyway.
(Maybe this is a bit too fragile...)
All supported pixel formats have a specific "mapping" of CPU data to
textures. This function determines the number and the formats of these
textures. Moving it to a helper will be useful for some hardware decode
interop backends, since they all need similar things.
GL_LUMINANCE_ALPHA is the only reason why per-plane swizzles exist.
Remove per-plane swizzles (again), and regrettably handle them as
special cases (again). Carry along the logical texture format (called
gl_format in some parts of the code, including the new one).
We also don't need a use_integer flag, since the new gl_format member
implies whether it's an integer texture. (Yes, the there are separate
logical GL formats for integer textures. This aspect of the OpenGL API
is hysteric at best.)
This should change nothing about actual rendering logic and GL API
usage.
Originally, there was probably some sort of intention to restrict it to
formats supported by the interop, or something. But in the end it was
overcomplicated nonsense.
In the future, we could use mp_hwdec_ctx.supported_formats or other
mechanisms to handle this in a better way.
mp_hwdec_ctx.ctx is not set to a dummy pointer - hwdec_devices_load() is
only used to detect whether to vo_opengl interop is present, and the
common hwdec code expects that the .ctx field is not NULL.
This also changes videotoolbox-copy to use --videotoolbox-format,
instead of the FFmpeg-set default.
The code for copying a videotoolbox surface to mp_image was duplicated
(with some minor differences - I picked the hw_videotoolbox.c version,
because it was "better"). mp_imgfmt_from_cvpixelformat() is somewhat
duplicated with the vt_formats[] table, but this will be fixed in a
later commit, and moving the function to shared code is preparation.
we reported some unnecessary mouse movements and not all mouse enter
and leave events. that lead to wrongly reported activity on hover areas
like on the OSC or comparable lua scripts. sometimes menu items were
shown that shouldn't be shown or they didn't vanish because of the
missing mouse leave event.
this incorporates @torque's fix for mouse leave events that weren't
triggered during a transition, like going to fullscreen. the
tracking area was updated but the mouse never left that area because
it was never over it.
besides some known cursor visibility bugs the aforementioned changes
also revealed some other bugs that weren't reproducible before because
of the missbehavior.
known issues, in some cases the cursor doesn't show or hide properly.
for example when switching spaces, switching Apps via CMD+Tab or a
system notification. former two could be fixed while keeping our current
blank cursor approach. though the notification case couldn't. there is
no event or similar to detect a notification and the cursor visibility
couldn't be recovered in any way.
new issues, i noticed that our event view isn't initialised yet when the
first VOCTRL_SET_CURSOR_VISIBILITY event gets dispatched, which depends
on the event view to be initialised. so the mouse cursor couldn't be
hidden when mpv was opened and the cursor was within the window bounds.
this wasn't noticeable before because of various bugs and unwanted
behavior that have been fixed with this. now, in case the event view
isn't ready yet, we set the visibility at a later point when the event
view is ready and a helper flag is set.
Fixes#1817#3856#4147
we have two problems here. first when mpv is started from the bundle it
uses its own environment variables and possibly can't find for example
the youtube-dl binary for our youtube-dl hook. second we couldn't
reliable determine when mpv was started from the bundle, which led to
the pseudo-gui usage even when the binary was invoked from a shell.
to prevent this we will wrap the bundle binary with a shell script,
which will only be called when we start mpv from the bundle. this way
we can get the same environment variables, like $PATH, for our bundle
and additional we can set the pseudo-gui only when started through this
script. it is also possible to detect the bundle usage properly and
accurately through the usage of another environment var.
Fixes#2061
quitting mpv from the Dock's context menu leaves the shell in a bad
state where you can't see your input any more and other weirdnesses.
in a big refactor (afdc9c4) the method to handle this case was actually
copied over but the the code to register the event itself was removed or
forgotten by accident, leaving some lines of dead code. i re-added the
event and slightly adjusted the function. the function was slightly
changed so the head of it is consistent with our other events and it is
associated with this commit and functionality in the future.
The "Files without Copyright notice are licensed as LGPLv2.1+."
statement makes it sound like the manpage and some other stuff are LGPL.
But the rule actually affects only some source files that were added in
mpv.
Change the wording, and also explicitly list the licenses for some non
source files. There might be more such cases.
