| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Should have done this 1000 years ago. Now GL backends can use mp_log
macros directly on the MPGLContext, instead of doing stupid things like
for example MP_WARN(ctx->vo, ...).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is just a pointless refactor with the only goal of making
image_writer_opts.format a number.
The pointless part of it is that instead of using some sort of arbitrary
ID (in place of a file extension string), we use a AV_CODEC_ID_. There
was also some idea of falling back to the libavcodec MJPEG encoder if
mpv was not linked against libjpeg, but this fails. libavcodec insist on
having AV_PIX_FMT_YUVJ420P, which we pretend does not exist, and which
we always map to AV_PIX_FMT_YUV420P (without the J indicating full
range), so encoder init fails. This is pretty dumb, but whatever. The
not-caring factor is raised by the fact that we don't know that we
should convert to full range, because encoders have no proper way to
signal this. (Be reminded that AV_PIX_FMT_YUVJ420P is deprecated.)
|
|
|
|
| |
Nobody cares about those.
|
|
|
|
|
|
|
| |
The function tried to do something clever but ignored the fact that
the middle button followed the left button rather than the right.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
|
|
|
|
|
|
| |
I guess that's the full extent I still care about nVidia's broken
garbage. In theory, we could always force the video mixer (which is the
only method getting the video data that works), but why bother.
|
|
|
|
|
|
|
|
|
|
|
|
| |
due to the see-through nature of the title bar and our standard black
window background, the title bar appears dark grey opposed to the
expected light grey.
we change the window background to white but at the same time set the
background of the enclosed view to black. that way the title bar has a
white background and the background of our video stays black in all
cases. this prevents white flashing in some cases when the video is
resized with too heavy render settings.
|
|
|
|
| |
Fixes #4194
|
|
|
|
|
| |
The hack becomes unnecessary with newer versions, but it's still needed
for older ones.
|
|
|
|
| |
(Helps shell completion.)
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The existing code modifies f.radius so that it is in terms of the
filter sample radius (in the source coordinate space) and has
some small errors because of this behavior.
This commit changes f.radius so that it is always in terms of
the filter function radius (in the destination coordinate space).
The sample radius can always be derived by multiplying f.radius
by filter_scale, which is the new, more descriptive name for the
previous inv_scale.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Modifications to the input coordinates should all be performed
before the final range check against the filter boundaries.
However, in the existing code, the blur/taper is applied after the
filter radius check is performed. Thus, effectively the filter radius
cutoff is applied to only-downscaling-metric-modified coordinates, not
the final coordinates.
Correct this issue and restructure the returns a bit to make it
more obvious what is being done.
|
|
|
|
|
|
|
| |
Depends on FFmpeg commit ade7c1a2326e2bb9b.
It has yet to show whether it actually does what it should. Probably
doesn't.
|
|
|
|
|
|
| |
I find it slightly helpful in some situations.
Also change the code to have a single exit path to make this easier.
|
|
|
|
| |
It didn't deinterlace at all. Oops.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'm not sure what's going on here, but it appears kodi switches forward
and backwards references for advanced VPP deinterlacing modes. This in
turn makes deinterlacing with these modes apparently work. If you don't
switch the directions, you get a stuttering mess.
As far as the libva trace dump is concerned, this makes mpv's libva
deinterlacing API use behave like kodi's, and appears to reproduce
smooth video with advanced libva deinterlacing enabled.
I'm hearing that Mesa actually does it correctly, and I'm not sure what
will happen there. For now, passing "reversal-bug=no" as sub-option to
the vavpp filter will undo this behavior.
|
|
|
|
|
|
|
| |
Fully initialize two structs (not doing so may or may not have been a
bug).
Actually destroy the VABufferID we create (moderate memory leak).
|
|
|
|
|
|
|
|
|
|
|
| |
forcibly moving a window from one screen to another is supposed to put
it in a position that looks relative the same as on the old screen, as
in bottom, top, left and right margin look the same, without changing
the window size. in some situations the old code moved the window off
screen or on top of the menu bar so it ended up at a somewhat random
position. the new code fixes some edge cases but is probably not
completely correct since the priority is to make sure that the window
ends up on the right screen.
|
|
|
|
|
|
|
|
|
|
|
| |
when forcibly moving windows to a different screen with --screen or
--fs-screen we need to move the window into the screen bounds if the
window is out of bounds, otherwise it can end up on the wrong screen.
previously it always recalculated the bounds and moved the window when
toggling fullscreen, now it only does the bound calculation when
changing screens.
Fixes #4178
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
i falsely assumed that the windowDidChangeScreen was meant to report
‘physical’ screen changes but was wondering why it triggers on other
events too. it actually is a event that informs us when anything
referenced by our current NSScreen is changed. even when something
referenced in the NSScreen changed the old and new NSScreen are still
equal if the physical screen didn’t change. with that my previous
optimisation broke some cases where the physical screen didn’t change
but things it referenced did, leading to a segfault when theses were
accessed. to keep the optimisation we will always update our internal
NSScreen reference but the rest only when the physical screen was
changed.
|
|
|
|
| |
Fixes #3242
|
| |
|
|
|
|
|
|
|
|
| |
What a fucking waste of time. It depends on with which headers you
compile as well, so the situation is worse and more confusing than
you'd think. God knows what brain fart made them change the numeric
ID without changing the extension name or any other ways to keep
ABI-compatibility and without any warning.
|
|
|
|
|
|
|
|
|
|
|
|
| |
FFmpeg could crash with vaapi (new) and --vo=opengl + interpolation.
It seems the actual surface count the old vaapi code uses (and which
usually never exceeded the preallocated amount) was higher than what
was used for the new vaapi code, so just correct that. The d3d helpers
also had weird code that bumped the real pool size, fix them as well.
Why this would result in an assertion failure instead of a proper error,
who knows.
|
|
|
|
|
|
| |
Don't give the driver more forward/backward refernces than it requested
in num_forward_references/num_backward_references. This shouldn't
matter, I'm just trying to play it safe.
|
|
|
|
|
|
| |
This is probably wrong. Just don't bother with it. The only potentially
negative effect is from calling vaQueryVideoProcPipelineCaps() every
frame.
|
|
|
|
|
|
| |
Locale-independent, and doesn't have the char vs. unsigned char problem.
(Although in this case, the code was fine, because bstr.start is
unsigned char.)
|
|
|
|
|
|
|
|
|
|
| |
fffab30 introduced a small regression where the cursor couldn't be
unhidden after refocusing. the problem is that no mouseUp event was
reported in our events_view. work around this with a separate event
monitor. this also fixes another regression when the window is being
dragged from the title bar.
#4174
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a race condition created by the previous commit, and possibly
others. Sometimes interpolated frames weren't redrawn as uninterpolated
ones.
The problem is that redrawing/drawing a frame can't reset the VO
want_redraw flags, because logically these have to happen after the core
acknowledged and explicitly reissued a redraw. The core needs to be
involved because the OSD text and drawings could depend on the playback
or window state.
Change it such that it always goes through the core.
Also, VOs inconsistently called vo_wakeup() when setting want_redraw,
which is also taken care of by this commit.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When pausing, we sent BOCTRL_PAUSE and VOCTRL_RESTORE_SCREENSAVER. These
essentially wait until the video frame has been rendered. This is a
problem with the opengl-cb, if GL rendering is done in the same thread
as libmpv uses. Unfortunately, it's allowed to use opengl-cb this way.
Logically speaking, it's a deadlock situation, which is resolved with a
timeout. This can lead to quite ugly effects, like the on-pause frame
not being rendered until the timeout has passed. It has been interpreted
as video continuing to play.
Resolve this by simply not blocking on pause. Make the screensaver
controls async, and handle sending VOCTRL_PAUSE in the VO thread.
(All this could be avoided by redoing the internal VO API.)
Also see #4152.
|
|
|
|
|
| |
Flags like MP_IMGFLAG_YUV were meaningless for hwaccel formats, and
setting fields like component_bits made even less sense.
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
Doesn't matter, since it's the flush call, but be nice. In particular,
don't upset coverity.
|
|
|
|
| |
OK, they're redundant. Now stop wasting my time, coverity.
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
They're unrelated. Sue me.
|
|
|
|
|
| |
Well, not like we can detect whether it's missing from libavcodec, but
it's still slightly better.
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
holding shift swaps the scroll wheel axes and deltaY returned zero.
summing up deltaX and deltaY will always give us the right button.
Fixes #3506
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Regression from recent refactor.
|
|
|
|
| |
Plus add a helper.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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...)
|
|
|
|
| |
Gives us automatically support for all formats vo_opengl supports.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Wrong colors. This didn't matter for the OpenGL interop code, because
the CV format was mapped to the correct texture format.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Introduce mp_imgfmt_to_cvpixelformat(), and change the existing
mp_imgfmt_from_cvpixelformat() to a table to avoid duplication.
|
|
|
|
|
|
|
|
| |
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 |