| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This replaces `vo-performance` by `vo-passes`, bringing with it a number
of changes and improvements:
1. mpv users can now introspect the vo_opengl passes, which is something
that has been requested multiple times.
2. performance data is now measured per-pass, which helps both
development and debugging.
3. since adding more passes is cheap, we can now report information for
more passes (e.g. the blit pass, and the osd pass). Note: we also
switch to nanosecond scale, to be able to measure these passes
better.
4. `--user-shaders` authors can now describe their own passes, helping
users both identify which user shaders are active at any given time
as well as helping shader authors identify performance issues.
5. the timing data per pass is now exported as a full list of samples,
so projects like Argon-/mpv-stats can immediately read out all of the
samples and render a graph without having to manually poll this
option constantly.
Due to gl_timer's design being complicated (directly reading performance
data would block, so we delay the actual read-back until the next _start
command), it's vital not to conflate different passes that might be
doing different things from one frame to another. To accomplish this,
the actual timers are stored as part of the gl_shader_cache's sc_entry,
which makes them unique for that exact shader.
Starting and stopping the time measurement is easy to unify with the
gl_sc architecture, because the existing API already relies on a
"generate, render, reset" flow, so we can just put timer_start and
timer_stop in sc_generate and sc_reset, respectively.
The ugliest thing about this code is that due to the need to keep pass
information relatively stable in between frames, we need to distinguish
between "new" and "redrawn" frames, which bloats the code somewhat and
also feels hacky and vo_opengl-specific. (But then again, this entire
thing is vo_opengl-specific)
|
|
|
|
|
|
|
| |
For some braindead reason, Microsoft decided to prevent you from
dynamically loading system libraries. This makes portability harder.
And we're talking about portability between Microsoft OSes!
|
|
|
|
|
|
|
|
|
|
|
|
| |
This partially reverts the change from a longer time ago to always build
DXVA2 and D3D11VA together.
To make it simpler, we change the following:
- building with ANGLE headers is now required to build D3D hwaccels
- if DXVA2 is enabled, D3D11VA is still forcibly built
- the CLI vo_opengl ANGLE backend is now under --egl-angle-win32
This is done to reduce the dependency mess slightly.
|
| |
|
|
|
|
|
|
| |
Slightly cleaner, possibly slightly more correct. (The last case should
be dead code now. In general, we can't know the implied colorspace from
a AV_PIX_FMT, at least not if FFmpeg adds a new one.)
|
|
|
|
|
|
|
|
|
| |
It never worked. It relied on some obscure texture format to provide the
equivalent of GL_RG or GL_LUMINANCE_ALPHA, but no hardware seemed to
report support for it ever. No idea what's the correct way to do this.
On D3D11 it exists, of course.
(Actually I'd like to remove the whole VO.)
|
|
|
|
|
|
| |
Another legacy annoyance. The only place where packed YUV is still
important is slightly older Apple hardware or drivers, which require
it for efficient hardware decoding.
|
|
|
|
|
| |
These were weird due to their past, and often undefined or ill-defined.
Time to get rid of them.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of setting up a weird swizzle (which is linked to how the
internal renderer code works, rather than the generic format code), add
per-component mapping to gl_imgfmt_desc.
The renderer still computes the weird swizzle, but at least it's
confined to itself. Also, it appears the hwdec backends don't need this
anymore.
It's really nice that the messy init_format() goes away too.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The changes to path list options is basically getting rid of the need to
pass multiple paths to a single option. Instead, you can use the option
multiple times. The old behavior can be used by using the -set suffix
with the option.
Change some options to path lists. For example --script is now append by
default, and if you use --script-set, you need to use ":"/";" as
separator instead of ",".
--sub-paths/--audio-file-paths is a deprecated alias now, and will break
if the user tries to pass multiple paths to it. I'm assuming that if
these are used, most users will pass only 1 path anyway.
--opengl-shaders has more compatibility handling, since it's probably
rather common that users pass multiple options to it.
Also document all that in the manpage.
I'll probably regret this later, as it somewhat increases the complexity
of the option parser, rather than increasing it.
|
|
|
|
|
| |
Fixes regression since b2f756c80e, which broke load-script command
when used with user paths (ex: ~~/script.lua)
|
|
|
|
|
|
| |
This takes car eof unsubtle bugs if something at init does not work
(specifically if mp_new_client() returns NULL). It also removes the need
for that PMP MF hack.
|
|
|
|
|
| |
This uses the same hack as Kodi uses, and I suspect MPlayer/ancient mpv
also did this (but didn't research that).
|
|
|
|
| |
That format is worthless anyway.
|
|
|
|
|
|
| |
I noticed that the previous default, bitstream, actually breaks with
some shitty anamorphic DVD rips that signal square pixel aspect in the
bitstream. So I think the "container" method is a better default.
|
|
|
|
|
|
|
|
|
|
|
| |
For vo_opengl and vo_direct3d, these are supported in a generic way.
For vf_vapoursynth, we could probably map its VSFormat struct in a
generic way, but for now do some bullshit.
vf_eq.c actually loses support for these formats. We could add generic
support too (anything that has 8 bit planes will work), but why bother.
The filter is deprecated anyway.
|
|
|
|
|
|
| |
These formats are supported in a generic way.
To get rid of IMGFMT_NV21, remove support from vo_direct3d.c completely.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add something that allows is to extract the component order from various
RGBA formats. In fact, also handle YUV, GBRP, and XYZ formats with this.
It introduces a new struct mp_regular_imgfmt, that hopefully will
eventually replace struct mp_imgfmt_desc. The latter is still needed by
a lot of code though, especially generic code. Also vo_opengl still uses
the old one, so this commit is sort of incomplete.
Due to its genericness, it's also possible that this commit introduces
rendering bugs, or accepts formats it shouldn't accept.
|
|
|
|
| |
Oh, this file still exists.
|
|
|
|
|
|
|
| |
No idea what I intended to write here, so I'm finishing it in some way
that makes sense (going by the commit that added it).
Fixes #4525.
|
|
|
|
|
|
| |
All relevant authors have agreed.
mpv as a whole is still GPL.
|
|
|
|
|
| |
Since strictly speaking, it's still optional. It's just very much
recommended not to disable it.
|
|
|
|
|
|
|
|
|
|
|
| |
UWP does not support the whole IMMDevice API. Instead, you need to use a
new API (available starting from Windows 8), which is in addition not in
MinGW, and extremely unpleasant to use.
The wasapiuwp2.dll wrapper is a small custom MSVC DLL, which does this
instead, and returns a normal IAudioClient.
Before this, ao_wasapi did not initialize on UWP.
|
|
|
|
|
|
|
|
| |
libmpv only. Some things are still missing.
Heavily reworked.
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
| |
These break on UWP. Based on a patch by Pedro Pombeiro.
|
|
|
|
|
|
|
|
|
|
| |
While this is perfectly OK on Unix, it causes annoying valgrind
warnings, and might be otherwise confusing to others.
On Windows, the runtime can actually abort the process if this is
called.
push.c part taken from a patch by Pedro Pombeiro.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In a bunch of cases, we emulate highly platform specific APIs on a
higher level across all OSes, such as IPC, terminal, subprocess
handling, and more. We have source files for each OS, and they implement
all the same mpv internal API.
Selecting which source file to use on an OS can be tricky, because there
is partially overlapping and emulated APIs (consider Cygwin on Windows).
Add a pick_first_matching_dep() function to make this slightly easier
and more structured.
Also add dummy backends in some cases, to deal with APIs not being
available.
Clarify the Windows dependency identifiers, as these are the most
confusing.
|
|
|
|
|
| |
POSIX requires glob(), so no need to check for it. Together with the
fact that we can emulate glob() on Windows, glob() is always available.
|
|
|
|
| |
Probably became unnecessary with the vf_dlopen removal.
|
|
|
|
| |
Seems like this can be slightly simplified.
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code accounting for the terrible AUDCLNT_E_BUFFER_SIZE_NOT_ALIGNED
semantics (which MSDN claims can happen "starting with Windows 7" - so
probably on Windows 10 too) duplicated the call for creating the
IAudioClient. That's not great, so get rid of it.
Let wasapi_thread_init() handle this. It has a retry loop anyway. This
redoes device lookup and format negotiation, but potential failures due
to race conditions (what if the driver decides to change behavior)
shouldn't be worse than before.
|
|
|
|
|
|
|
|
|
| |
Apparently, this messes up on wraparound (although it shouldn't). After
2^32 bytes an audio "blip" happens with AOs that use this ringbuffer.
Whatever, we can fix this by switching to a 64 bit counter. There's also
a good chance the ringbuffer will be dropped completely, so don't waste
more time on this.
|
|
|
|
| |
Mostly for debugging, I guess.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 3fb6380 was supposed to increase MAX_TEXTURE_HOOKS but instead
increased SHADER_MAX_HOOKS, since I forgot that they were separate (for
whatever reason).
To prevent this mistake from happening again, and to unify the location
in which user_shader-specific #defines are placed, get rid of the two
constants in opengl/video.c and move/reuse them from user_shaders.h
instead.
Also bump up MAX_SAVED_TEXTURES (now SHADER_MAX_SAVED) slightly as a
precaution against adding more passes to vo_opengl. I think we're
already flirting with the limit.
|
| |
|
|
|
|
|
| |
This was enabled for Libav already. The patches got merged into FFmpeg
now.
|
| |
|
|
|
|
|
|
| |
There is no technical need for this, but it's nicer if --list-options
appears to output them sorted (it only actually sorts the actual option
list, while actions are output in the order they are defined).
|
|
|
|
|
|
|
|
|
|
|
|
| |
This means you can use --sub-file-set=a,b,c to set a string list
separated by ',', while --sub-file=filename,with,commas.srt still works
(the original motivation for changing the --sub-file option this way).
You can also use it to append strings to string list options without the
need for escale, e.g.: --opengl-shaders-add-str=unescapesdfilename.glsl
(The normal -add for some reason expects a ',' separated list as
argument.)
|
|
|
|
|
|
|
| |
These are not "really" separate actions, but on the command line they're
obserable as such. So it would be a good idea to list them too.
Adds about 117 options (holy fuck).
|
|
|
|
| |
Is anyone still using them? Well, I'm removing them anyway.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is even better at preventing discoloration than tone mapping on the
XYZ image. Partly inspired by the HLG OOTF. Also simplifies the way we
tone map, and moves this logic to the pass_tone_map function where it
belongs.
This also fixes what could arguably be considered a bug in the HLG
implementation when using HLG for non-BT.2020 colorspaces, which is not
permitted by spec but thinkable in theory. Although in this case, I
guess it will be arbitrary whether people use the BT.2020-normalized
luma coefficients or change it to fit the colorspace, so I guess either
way could be considered "right", depending on what people end up doing.
Either way, in lieue of standard practice, we do what makes the most
sense (to me), and hopefully others will follow.
The downside is that we upload an extra vec3 uniform even if we don't
use it, but eliminating that would be ugly.
|
|
|
|
|
|
|
| |
For HLG, due to the usage of a reference OOTF configured for 1000 cd/m²,
the default sig_peak of =nom_peak was suboptimal. We can go down to
1000/100 (=10.0), since that's the true dynamic range of the output
signal after it passes through the OOTF.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This affects options like --vf or --display-tags. These used a "*"
suffix to match all options starting with a specific name, and handled
the rest in the option parser. Change this to remove the "*" special
case, and require every option parser to declare a list of allowed
suffixes via m_option_type.actions.
The new way is conceptually simpler, because we don't have to account
for the "*" in a bunch of places anymore, and instead everything is
centrally handled in the CLI part of the option parser, where it's
actually needed.
It automatically enables suffixes like -add for a bunch of other
stringlist options.
|
|
|
|
|
|
|
| |
You could do mpv_set_option(h, "no-fs", ""), which would behave like
"--no-fs" on the command line. At one point, this had to be emulated for
compatibility, and printed a deprecation warning. This was almost a year
ago, so remove it.
|
|
|
|
|
|
|
|
| |
While I'm not particularly attached to this, the history is pretty
simple, and all relevant authors have agreed.
2f004875: removed in 2c693a47, patch author was not asked.
1ef239a4: removed, author was not asked.
|
|
|
|
| |
We got permission from the original author.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This makes things like --show-profile=enc-v-h264 just work again.
Currently I don't see a reason why we should not always load the
encoding profiles. Although I guess this used to be different in the
past. (It probably won't take long until I revert this again - seems
like a fight you can't win for some reason.)
Fixes #4551.
|
|
|
|
| |
This should also make a difference with the Windows 7 Platform Update.
|