| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Regression introduced by direct rendering code additions. Found by same
static analyzer.
|
|
|
|
| |
Detected by a well known static analyzer.
|
| |
|
|
|
|
| |
Untested. If it works, fixes #4919.
|
|
|
|
| |
That's just unnecessary.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With video paused, changing the brightness controls (or similar) would
sometimes not rerender the video frame. So the OSD would redraw, but the
video wouldn't change. This is caused by output caching, and a redraw
request is free to return the cached frame. Change it such to invalidate
the cached frame if any of the options or the equalizer change.
In theory, gl_video_reset_surfaces() could be called if the equalizer
changes - this would apparently force interpolatzion to redraw all
frames. But this looks kind of crappy when changing the equalizer during
playback. It'll "eventually" use the correct settings anyway, and when
paused interpolation is off.
|
| |
|
|
|
|
| |
Fucking shit.
|
|
|
|
|
|
|
| |
This was phased out, and was used only by vdpau by now. Drop the
mechanism and the vdpau special code, which means screenshots won't
include the vf_vdpaupp processing anymore. (I don't care enough about
vdpau, it's on its way out.)
|
|
|
|
| |
Sigh.
|
|
|
|
|
|
|
|
|
|
|
|
| |
The mechanism introduced in b135af6842bf assumed AVHWFramesContext would
be enough. Apparently it's not - the intended use with Rockchip (not
Rokchip btw.) requires accessing actual frame data in order to access
the AVDRMFrameDescriptor struct.
Just pass the entire mp_image to the new function. This is more
flexible, although it slightly worries me that it will be less reusable
for things which require setting up mp_image_params before any real
frames are processed (such as filters).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The same should happen with any other side data that matters to mpv,
otherwise filters will drop it.
(No, don't try to argue that mpv should use AVFrame. That won't work.)
ffmpeg_garbage() is copy&paste from frame_new_side_data() in FFmpeg
(roughly feed201849b8f91), because it's not public API. The name
reflects my opinion about FFmpeg's API.
In mp_image_to_av_frame(), change the too-fragile
*new_ref = (struct mp_image){0};
into explicitly zeroing out the fields that are "transferred" to the
created AVFrame.
|
|
|
|
|
|
|
|
| |
Merge mp_image_copy_fields_to_av_frame() into mp_image_from_av_frame(),
same for the other direction.
There isn't any good reason to keep them separate, and the refcounting
handling makes it only more awkward.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It seems this will be useful for Rokchip DRM hwcontext integration.
DRM hwcontexts have additional internal structure which can be different
depending on the decoder, and which is not part of the generic hwcontext
API. Rockchip has 1 layer, which EGL interop happens to translate to a
RGB texture, while VAAPI (mapped as DRM hwcontext) will use multiple
layers. Both will use sw_format=nv12, and thus are indistinguishable on
the mp_image_params level. But this is needed to initialize the EGL
mapping and the vo_gpu video renderer correctly.
We hope that the layer count is enough to tell whether EGL will
translate the data to a RGB texture (vs. 2 texture resembling raw nv12
data). For that we introduce MP_IMAGE_HW_FLAG_OPAQUE.
This commit adds the flag, infrastructure to set it, and an "example"
for D3D11.
The D3D11 addition is quite useless at this point. But later we want to
get rid of d3d11_update_image_attribs() anyway, while we still need a
way to force d3d11vpp filter insertion, so maybe it has some
justification (who knows). In any case it makes testing this easier.
Obviously it also adds some basic support for triggering the opaque
format for decoding, which will use a driver-specific format, but which
is not supported in shaders. The opaque flag is not used to determine
whether d3d11vpp needs to be inserted, though.
|
|
|
|
|
|
|
|
| |
Mostly an obscure option for testing. But --videotoolbox-format can be
deprecated, as it becomes redundant.
We rely on the libavutil hwcontext implementation to reject invalid
pixfmts, or not to blow up if they are incompatible.
|
|
|
|
| |
These were changed in 7897f79217af to match X11 and Windows.
|
|
|
|
|
| |
This was for the "opengl" compat VO entry, which is now handled
differently.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was confusing at best. Change it to output the actual choices.
(Seems like in the end it's always me who has to clean up other people's
bullshit.)
Context names were not unique - but they should be, so fix it. The whole
point of the original --opengl-backend option was to side-step the
tricky auto-detection, so you know exactly what you get. The goal of
this commit is to make --gpu-context work the same way. Fix the
non-unique names by appending "vk" to the names.
Keep in mind that this was not suitable for slecting the "UI" backend
anyway, since "x11" would force GLX, whereas people on not-NVIDIA
actually want "x11egl". Users trying to use --gpu-context=x11 to force
the X11 backend would always end up with GLX, which would at least break
VAAPI hardware decoding for them. Basically the idea that this option
could select the "UI" type is completely broken - it selects an
implementation, which implies a UI. Selecting the UI type This would
require a separate mechanism. (Although in theory this separate
mechanism could be part of the --gpu-context option - in any case,
someone would have to implement it.)
To achieve help output that can actually be understood, just duplicate
the code. Most of that code is duplicated anyway, and trying to share
just the list code with the result of making the output unreadable
doesn't make too much sense. If we wanted to save code/effort, we could
just remove the help output altogether.
--gpu-api has non-unique entries, and it would be nice to group them
(e.g. list all OpenGL capable contexts with "opengl"), but C makes this
simple idea too much of a pain, so don't do it.
Also remove a stray tab from the android entry on the manpage.
|
|
|
|
|
|
|
|
|
|
| |
If the chroma location is missing, vo_gpu will use centered chroma.
Select a better chroma location by default: normally, it will always be
MPEG video chroma location. If full levels are used, use JPEG chroma
location, because that sort of sounds like it could make sense as it
might coincide with JPEG being decoded.
See e.g. #4804.
|
|
|
|
| |
This matches the other Vulkan contexts.
|
|
|
|
| |
Apparantly the context was renamed.
|
|
|
|
|
|
| |
Unfortunately I'm also adding the full text of the LGPL license text,
because the GPL one was already present in this repository, and I don't
want to imply that the GPL somehow has priority.
|
|
|
|
| |
For symmetry with --alang and --slang. 100% useless, but why not?
|
|
|
|
| |
also one minor cosmetic change: comment the "coming soon" dummy page
|
|
|
|
|
| |
Change true/false to yes/no because lua script configs only take these
values for booleans.
|
| |
|
|
|
|
|
| |
Otherwise if display connection or xkb init failed the uninit function
could segfault.
|
|
|
|
|
| |
Ordered chapters behavior changed at some point, and all of this was
outdated.
|
|
|
|
|
|
| |
Every compositor (including toy compositors) has had support for wl_output v2
since forever, so there's little point in supporting degraded output for 5 year
old releases (especially considering we require zxdg6 which is far more recent).
|
|
|
|
|
|
|
| |
This adds symbol information to the generated SPIR-V, which shows up in
the SPIR-V assembly dump. It's also useful for potential RA backends
that use SPIRV-Cross, since the symbol information is used in the
generated shader source.
|
| |
|
|
|
|
| |
Fuck this thing.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rename --enable-preliminary-lgpl2 to --enable-gpl. This concludes the
relicensing. Some things are still to do (relicensing some still-GPL
optional code), but we consider the code included by --enable-gpl to be
fully relicensed.
The relicensing was performed by asking every known author for
permission for relicensing it to LGPL version 2.1 "or later". If an
author could not be contacted or permission could not be obtained, and
the contribution was considered relevant for copyright purposes, the
affected code was either excluded from LGPL mode (not built), or removed
or rewritten. This is the standard in open source relicensing processes.
Keep in mind that using LGPL mode is still on the user's own risk. Even
though I claim that the relicensing was pretty clean and thorough
(measured on the standards of the open source community¹), and I
followed the advice of some actual experts, there is still a residual
uncertainty due to the fact that I'm not an all-knowing entity (authors
could have taken someone else's code and pretend it's their own) nor a
lawyer (meaning I might lack associated authority or expertise), and the
fact that the judicial system is far from deterministic. The relicensing
was performed merely to the best of my knowledge. I reject all
responsibility outside of that.
This commit also cleans up the "Copyright" file to reflect the finalized
relicensing process.
¹ Not to imply that the standards of commercial companies are much
higher. Some major tech companies get away with stuff I would not
consider clean.
See #2033.
|
|
|
|
|
|
|
|
| |
This should actually cover all of them, if you take into account that
some unchanged GPL source files include header files with such checks.
Also this was done already for the libaf derived code.
This is only for "safety" and to avoid misunderstandings.
|
|
|
|
|
|
|
| |
It turns out compositors which do scaling scale the cursor as well,
so every single surface needs to get scaled too.
Also, 32 corresponds to the default size for both GTK+ and KDE.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This new interface in libva2 offers a cleaner way to export surfaces
which can then be imported to EGL. In particular, this works with
the Mesa driver, so we can have proper playback without a pointless
download and upload on AMD cards.
This change does nothing with libva1, and will fall back to the
libva1 interface (vaDeriveImage() + vaAcquireBufferHandle()) if
vaExportSurfaceHandle() is not present.
|
|
|
|
| |
They are no longer global, so they work vaguely sensibly.
|
|
|
|
| |
stats.rst is heavily based on osc.rst
|
|
|
|
|
|
|
|
|
| |
Signed-off-by: wm4 <wm4@nowhere>
Rename --stats to --load-stats-overlay and add an entry to options.rst
over the original commit.
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously multiple timers were used to realize oneshot, toggling
(redrawing) and page keybindings. The oneshot case in particular also
relied on mp.osd_message to display text only for a given duration.
This was changed to only use one timer in total now. Because now each
case has a defined "start" and "end" point (including oneshot)
mp.set_osd_ass() can be used to print stats as well. This is currently
optional and has to be activated using the config option
persistent_overlay=true.
One shortcoming: oneshot and toggling are mutual exclusive right now.
Previously you could enter toggling while oneshot stats were shown,
this is not possible anymore to reduce the number of cases to be
considered. This can be added later on if desired.
|
|
|
|
|
|
| |
It used a bad heuristic that got even worse/less reliable with recent
changes in mpv. In fact, it's not reliable at all.
Watch out for dropped frames instead. That's a useful indicator.
|
|
|
|
|
| |
Fixes #44
(well, partially, I'm still not sure about the time)
|
| |
|
|
|
|
|
| |
Clarified the relationship between `Dropped` and `VO`, and also merged
the DS-exclusive stats into the DS line.
|
|
|
|
|
| |
It's apparently already stated as part of the upload pass name.
This reverts commit ec837f64c29a1b825e28b65edc34059b6c1cad40.
|
| |
|
| |
|
|
|
|
| |
Due to popular demand
|
|
|
|
| |
There was a superfluous newline and some indentation
|
| |
|
|
|
|
| |
There's no point in disabling it anyway
|
| |
|
|
|
|
| |
There is enough space now
|
| |
|
|
|
|
| |
Fixes #42
|
|
|
|
| |
There's no reason it's not.
|
|
|
|
|
|
| |
Almost cosmetic change.
This tables-in-table was done back when we actually processed strings
but that's long ago now and no longer needed nor useful.
|
|
|
|
|
|
|
| |
Previously I could trigger a bug with intense button mashing, however,
was unable to reproduce it and therefore debug it.
This change now seems to be resilient against button mashing, let's hope
it really is.
|
|
|
|
|
|
| |
A keybinding in input.conf like:
e script-binding stats/display-page-2
can be used to directly show the respective page (2, in this case)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Please note that the latest version of this script needs a very recent
version of mpv (from yesterday, to be precise, see the readme).
For older versions, please go to "releases".
HOW IT WORKS:
While the stats are visible (i.e. text is printed to the OSD) a
subsequent click on a numeric key (1, 2, ...) will display the
corresponding "page".
This works no matter if the stats are toggled or just shown as a single
invocation. In case of a single invocation, the newly displayed page
will be shown for the full duration again.
The selected page will be remembered (not persistantly though).
So far, only 3 pages are available.
1: the default page, stats as they used to be
2: extensive VO performance stats (to be redesigned/changed soon)
3: dummy
In the future, many more pages are possible.
Implementation is likely to change again (functionality will stay
the same). A new timer had to be introduced to remove the forced
keybindings in the oneshot case. The toggle case can remove them without
a timer. Ensuring that each mode won't remove timers of the other mode
didn't really turn out neat.
Therefore, I intend to change this again, maybe by merging the
oneshot case into the toggle case.
|
|
|
|
|
| |
We now require a modern mpv version.
`property_aliases` is kept for future use.
|
|
|
|
|
| |
For vsync measurements this is not currently done because they don't
track their average
|
|
|
|
|
|
|
|
|
|
|
| |
Due to the large amount of per-pass data, the function takes a parameter
indicating whether or not to print a simplified view instead.
The overall intent is to print the simplified view for now, but supposed
printing the full view on a dedicated "tab" (or extra view type), and as
such, `o.print_perfdata_passes` will go away again. I've only introduced
it for now so users can play around with this functionality if they want
to, until Argon- gets around to implementing stats "tabs".
|
| |