| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This merges all of the scaler-related options into a single
configuration struct, and also cleans up the way they're passed through
the code. (For example, the scaler index is no longer threaded through
pass_sample, just the scaler configuration itself, and there's no longer
duplication of the params etc.)
In addition, this commit makes scale-down more principled, and turns it
into a scaler in its own right - so there's no longer an ugly separation
between scale and scale-down in the code.
Finally, the radius stuff has been made more proper - filters always
have a radius now (there's no more radius -1), and get a new .resizable
attribute instead for when it's tunable.
User-visible changes:
1. scale-down has been renamed dscale and now has its own set of config
options (dscale-param1, dscale-radius) etc., instead of reusing
scale-param1 (which was arguably a bug).
2. The default radius is no longer fixed at 3, but instead uses that
filter's preferred radius by default. (Scalers with a default radius
other than 3 include sinc, gaussian, box and triangle)
3. scale-radius etc. now goes down to 0.5, rather than 1.0. 0.5 is the
smallest radius that theoretically makes sense, and indeed it's used
by at least one filter (nearest).
Apart from that, it should just be internal changes only.
Note that this sets up for the refactor discussed in #1720, which would
be to merge scaler and window configurations (include parameters etc.)
into a single, simplified string. In the code, this would now basically
just mean getting rid of all the OPT_FLOATRANGE etc. lines related to
scalers and replacing them by a single function that parses a string and
updates the struct scaler_config as appropriate.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes the core much more elegant, reusable, reconfigurable and also
allows us to more easily add aliases for specific configurations.
Furthermore, this lets us apply a generic blur factor / window function
to arbitrary filters, so we can finally "mix and match" in order to
fine-tune windowing functions.
A few notes are in order:
1. The current system for configuring scalers is ugly and rapidly
getting unwieldy. I modified the man page to make it a bit more
bearable, but long-term we have to do something about it; especially
since..
2. There's currently no way to affect the blur factor or parameters of
the window functions themselves. For example, I can't actually
fine-tune the kaiser window's param1, since there's simply no way to
do so in the current API - even though filter_kernels.c supports it
just fine!
3. This removes some lesser used filters (especially those which are
purely window functions to begin with). If anybody asks, you can get
eg. the old behavior of scale=hanning by using
scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is
just as terrible as that sounds - which is why nobody should have
been using them in the first place).
4. This changes the semantics of the "triangle" scaler slightly - it now
has an arbitrary radius. This can possibly produce weird results for
people who were previously using scale-down=triangle, especially if
in combination with scale-radius (for the usual upscaling). The
correct fix for this is to use scale-down=bilinear_slow instead,
which is an alias for triangle at radius 1.
In regards to the last point, in future I want to make it so that
filters have a filter-specific "preferred radius" (for the ones that
are arbitrarily tunable), once the configuration system for filters has
been redesigned (in particular in a way that will let us separate scale
and scale-down cleanly). That way, "triangle" can simply have the
preferred radius of 1 by default, while still being tunable. (Rather
than the default radius being hard-coded to 3 always)
|
| |
|
|
| |
Terribly obscure, and vf_format can do this for all VOs.
|
| |
|
|
|
|
|
|
| |
Rarely used and essentially useless. The only VO for which this was
implemented correctly and for which this did anything was vo_xv, but you
shouldn't use vo_xv anyway (plus it support BT.601 only, plus a vendor
specific extension for BT.709, whose presence this function essentially
reported - use xvinfo instead).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This requires FFmpeg git master for accelerated hardware decoding.
Keep in mind that FFmpeg must be compiled with --enable-mmal. Libav
will also work.
Most things work. Screenshots don't work with accelerated/opaque
decoding (except using full window screenshot mode). Subtitles are
very slow - even simple but huge overlays can cause frame drops.
This always uses fullscreen mode. It uses dispmanx and mmal directly,
and there are no window managers or anything on this level.
vo_opengl also kind of works, but is pretty useless and slow. It can't
use opaque hardware decoding (copy back can be used by forcing the
option --vd=lavc:h264_mmal). Keep in mind that the dispmanx backend
is preferred over the X11 ones in case you're trying on X11; but X11
is even more useless on RPI.
This doesn't correctly reject extended h264 profiles and thus doesn't
fallback to software decoding. The hw supports only up to the high
profile, and will e.g. return garbage for Hi10P video.
This sets a precedent of enabling hw decoding by default, but only
if RPI support is compiled (which most hopefully it will be disabled
on desktop Linux platforms). While it's more or less required to use
hw decoding on the weak RPI, it causes more problems than it solves
on real platforms (Linux has the Intel GPU problem, OSX still has
some cases with broken decoding.) So I can live with this compromise
of having different defaults depending on the platform.
Raspberry Pi 2 is required. This wasn't tested on the original RPI,
though at least decoding itself seems to work (but full playback was
not tested).
|
| |
|
|
|
|
|
|
| |
Currently, the code just skipped CMS completely. This commit treats them
as sRGB by default, instead.
This also refactors much of the color management code to make it more
generalized and re-usable.
|
| |
|
|
| |
Minor reusability factor
|
| |
|
|
|
| |
This moves common re-definitions to a custom function and also shortens the
names to make stuff less verbose in general.
|
| |
|
|
|
| |
This makes the VO more responsive to equalizer changes (eg. brightness)
when interpolation is used.
|
| |
|
|
|
|
|
| |
This is a minor precaution, because in some cases the number of shader
programs can already hit 10. (chroma merging + separated cscale/scale +
+ sub blending (interpolated) + sub blending (non-interpolated)
+ output (interpolated) + output (non-interpolated) + OSD)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This has a number of user-visible changes:
1. A new flag blend-subtitles (default on for opengl-hq) to control this
behavior.
2. The OSD itself will not be color managed or affected by
gamma controls. To get subtitle CMS/gamma, blend-subtitles must be
used.
3. When enabled, this will make subtitles be cleanly interpolated by
:interpolation, and also dithered etc. (just like the normal output).
Signed-off-by: wm4 <wm4@nowhere>
|
| |
|
|
|
|
|
| |
Bilinear scaling is not a suitable default for something named "hq"; the
whole reason this was done in the past was because cscale used to be
obscenely slow. This is no longer the case, with cscale being nearly
free.
|
| | |
|
| |
|
|
| |
We don't need alternative function names in the GL loader anymore.
|
| |
|
|
|
|
|
|
|
| |
With the previous commit, we have no need anymore to check a part of an
extension string (for ignoring a prefix). So check the extension string
properly, instead of just using the broken old strstr() method, which
could accidentally ignore prefixes or suffixes. Do this by extending
the check to whether the extension name is properly delimited by spaces
or string start/end.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of somehow looking for the substring "_swap_control" and trying
to several arbitrary function names, do it cleanly. The old approach has
the problem that it's not very exact, and may even load a pointer to a
function which doesn't exist. (Some GL implementations like Mesa return
function pointers even the functions which don't exist, and calling them
crashes.)
I couldn't find any evidence that glXSwapInterval, wglSwapIntervalSGI,
or wglSwapInterval actually exist, so don't include them. They were
carried over from MPlayer times.
To make diagnostics easier, print a warning in verbose mode if the
function could not be loaded.
|
| |
|
|
|
|
|
|
| |
Drop support for GL_EXT_framebuffer_object. It has 2 problems: semantics
might be slightly different from the "proper" GL_ARB_framebuffer_object
extension (but is likely completely untested), and also our extension
loader is too dumb to load the same group of function pointers
represented by different extensions only once.
|
| |
|
|
|
| |
If compositor sends configure event before back_buffer is allocated, it
will cause null dereference.
|
| |
|
|
|
|
|
|
|
| |
When not receiving frame callbacks, we should not draw anything to avoid
blocking the OpenGL renderer. We do this by extending gl context api, by
introducing new optional function 'is_active', that indicates whether
OpenGL renderers should draw or not.
This fixes issue #249.
|
| |
|
|
|
| |
This allows compositor to optimize rendering, as it will know mpv is not
transparent.
|
| |
|
|
|
|
|
|
| |
Define frame callback logic in wayland_common.c
As this should be used by opengl renderer as well.
Preferably drawing should be skipped entierly when no frame callbacks
are received. However, for now only swap buffers is skipped.
|
| |
|
|
|
| |
This seems to have been a mistranslation from the original code, which
multiplied the gamma by 2.6 (*not* the color itself).
|
| |
|
|
|
| |
The way-too-big API call for clearing the screen can be easily shared
between two completely different codepaths.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Unlike other VOs, this rendered OSD even while no VO was created
(because the renderer lives as long as the API user wants). Change this,
and refactor the code so that the OSD object is accessible only while
the VO is created.
(There is a short time where the OSD can still be accessed even after VO
destruction - this is not a race condition, though it's inelegant and
unfortunately unavoidable.)
|
| |
|
|
|
| |
Also reindent the few lines that call into the actual renderer to remove
the "draw_osd" goto.
|
| |
|
|
| |
It was ignored.
|
| |
|
|
|
|
| |
gl_video_set_options() didn't update it, so the default value set on
initialization was used. Fix by always setting the clear color before
the clear command; it's slightly easier to follow too.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
There's literally no reason why these functions have to be inline (they
might be performance critical, but then the function call overhead isn't
going to matter at all).
Uninline them and move them to mp_image.c. Drop the header file and fix
all uses of it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There was a somewhat obscure optimization in the OSD and subtitle
rendering path: if only the position of the sub-images changed, and not
the actual image data, uploading of the image data could be skipped. In
theory, this could speed up things like scrolling subtitles.
But it turns out that even in the rare cases subtitles have such scrolls
or axis-aligned movement, modern libass rarely signals this kind of
change. Possibly this is because of sub-pixel handling and such, which
break this.
As such, it's a worthless optimization and just introduces additional
complexity and subtle bugs (especially in cases libass does the
opposite: incorrectly signaling a position change only, which happened
before). Remove this optimization, and rename bitmap_pos_id to
change_id.
|
| |
|
|
|
|
|
| |
We now update uniforms every time, so we should try to reduce the number
of uniforms to avoid performance penalties. (Originally, some caching
was planned, but it looks like it would be too complicated to implement
compared to the expected gains.)
|
| | |
|
| |
|
|
|
|
| |
OPT_REPLACED can't specify option values or multiple options. Change to
OPT_REMOVED. Also, target-prim doesn't have an srgb option. BT.709 uses
sRGB primaries, so use it instead.
|
| |
|
|
|
|
| |
Trade one bug for another, I don't even care anymore.
Fixes #1691.
|
| | |
|
| |
|
|
|
|
|
|
| |
The default scaling was a slight bit too low, which could cause buffer
underruns in some cases.
This should improve the result when using tscale filters other than
oversample. The oversample case should be unaffected.
|
| |
|
|
|
|
| |
This adds extra debugging output for buffer underruns, to help track
down possible queueing issues. It also inverts the numberic output for
tscale=oversample to make more sense, without changing the logic.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This moves the color management code out of pass_render_main (which is
now dedicated solely to up/downscaling and hence renamed pass_scale_main)
and into a new function, which gets called from pass_draw_to_screen
instead.
This makes more sense from a logical standpoint, and also means that we
interpolate in linear RGB, before color management - rather than after
it, which is significantly better for color accuracy and probably also
interpolation quality.
|
| |
|
|
| |
There are conflicting definitons of Ginseng.
|
| |
|
|
|
| |
This is interesting mainly because it's essentially equivalent to the
old smoothmotion algorithm. As such, it is now the default for tscale.
|
| |
|
|
|
|
| |
This is like nearest neighbour, but the edges between pixels are
linearly interpolating if needed, as if they had been (naively)
oversampled.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This replaces the old smoothmotion code by a more flexible tscale
option, which essentially allows any scaler to be used for interpolating
frames. (The actual "smoothmotion" scaler which behaves identical to the
old code does not currently exist, but it will be re-added in a later commit)
The only odd thing is that larger filters require a larger queue size
offset, which is currently set dynamically as it introduces some issues
when pausing or framestepping. Filters with a lower radius are not
affected as much, so this is identical to the old smoothmotion if the
smoothmotion interpolator is used.
|
| |
|
|
|
|
| |
Also the size is now a simple #define that can easily be changed later.
This is done for smoothmotion, which might want to blend more than 4
frames at once, depending on the setting.
|
| |
|
|
| |
Not needed anymore; see previous commit.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since the gl_rework merge, this started to print some OpenGL errors when
using vdpau hardware decoding with vo_opengl smoothmotion. This happens
because some hwdec unmap_image call were not paired with a map_image
call. Unlike the old vo_opengl, the new code does not do this out of
convenience (it would be a pain to track this exactly). It was triggered
by smoothmotion, because not every rendered frame has actually a new
input video frame (i.e. no map_image call, but it called unmap_image
anyway).
Solve this by handling unmapping differently in the vdpau code. The next
commit will remove the unmap_image callback completely.
Fixes #1687.
|
| |
|
|
|
| |
This essentially makes it so that every gamma function that crops up
somewhere has a corresponding clamp in front of it.
|
| |
|
|
| |
Fixes #1686
|
Niklas Haas
wm4
Jari Vetoniemi
James Ross-Gowan
Stefano Pigozzi