| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
avcodec_profile_name() was added only a week ago or so.
|
|
|
|
| |
This was broken during refactoring commit e2d90b38 before pushing it.
|
|
|
|
| |
Should be useful.
|
|
|
|
|
|
|
|
|
|
| |
AVComponentDescriptor.offset was introduced relatively recently. On
older releases, you have to use AVComponentDescriptor.offset_plus1,
which is now deprecated.
Instead of adding ifdeffery, assume AV_PIX_FMT_NV21 is the only format
for which this applies (and will remain the only case), which is
probably true enough.
|
|
|
|
|
|
| |
Should take care of the planned FFmpeg AV_PIX_FMT_P010 addition. (This
will eventually be needed when doing HEVC Main 10 decoding with DXVA2
copyback.)
|
| |
|
|
|
|
|
|
|
|
|
|
| |
A format could declare that some or all LSBs in a component are padding
bits by setting a non-0 AVComponentDescriptor.shift value. This means we
would interpret it incorrectly, because until now we always assumed all
regular formats have the padding in the MSBs.
Not a single format that does this actually exists, though. But a NV12
variant will be added later in FFmpeg.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 3909e4cd ended up losing the ability to tune the gaussian window,
which this commit trivially reintroduces.
The constant scaling factor (present in the code copied from glumpy)
also goes against filter_kernels.c conventions, which is that f(0.0) = 1
(and the invoking code takes care of normalization), and has been
removed.
The values of this new gaussian function corresponds to different
functions when compared against the old version. To translate the old
values p1 to the new values p2 requires solving 2^(e/p1) = e^(2/p2) or
p2 = p1 * 2/(e * ln(2)) ≈ p1 * 1.0615
In other words, to get the old default in the new function requires
setting scale-param1 to 1.0615. (The new function is *slightly* sharper
by default)
(Though most users should probably not notice the change)
|
|
|
|
|
|
|
|
|
|
|
| |
To get a uniform license for this file, relicense the mpv parts to BSD
as well.
But leave the door open for a later change to LGPL. (All non-Glumpy code
was written within mpv, and all mpv authors have agreed to LGPL
relicensing.)
Closes #2688.
|
|
|
|
| |
All code was written by myself.
|
|
|
|
|
| |
This is a mistake coming from commit 6ef06aa1: it accidentally changed
the license from GPL/LGPL dual to GPL only.
|
|
|
|
|
|
|
|
|
| |
This file claims to be based on the "MPlayer VA-API patch", but this is
untrue. Only some glue code was copied from hwdec_vaglx.c, and this glue
code was never in MPlayer or the MPlayer VA-API patch in any form, and
instead part of the mpv-original way we do hardware decoding OpenGL
interop. The EGL interop method didn't exist at the time the MPlayer
VA-API patch was created either.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit replaces code based on AGG, taken from this source file:
http://vector-agg.cvs.sourceforge.net/viewvc/vector-agg/agg-2.5/include/agg_image_filters.h
The intention is that filter_kernels.c can be relicensed to LGPL or BSD.
Because the AGG author died, full replacement is the only way to achieve
it.
This affects only some filter functions. These are exclusively
mathematical functions for computing filter coefficients. (Other parts
in filter_kernel.c were originally written by me, with heavy additions
and refactoring done by other mpv contributors.) While the code is
mostly just well-known mathematical formulas written down in C form,
AGG copyright could perhaps be claimed anyway.
To remove the AGG code, I replaced it with the filter functions from:
https://github.com/glumpy/glumpy/blob/master/glumpy/library/build-spatial-filters.py
These functions conveniently compute exactly the same thing in mpv,
Glumpy, AGG (and about anything that will filter images using the same
mathematical principles).
First I ported the Python code in the file to C. Then I replaced all
functions in filter_kernels.c with this code that could be replaced.
Then I investigated whether the remaining functions were based on AGG
code and took appropriate action:
hanning(), hamming(), quadric(), bicubic(), kaiser(), blackman(),
spline16(), spline36(), gaussian(), sinc() were taken straight from
Glumpy.
For sinc(), re-add the "fabs(x) < 1e-8" check, which was added in commit
586dc557 for unknown reasons.
gaussian() loses its filter parameter for some reason. (Well, who cares,
not my problem.)
The really awkward thing is that the text for hanning() and hamming()
does not change. In theory these functions are now based on Glumpy code,
but it seems like this can be neither proven nor denied. (The same
happened in some other cases with at least a few lines of code.)
sphinx() was added in commit 586dc557, and looks suspiciously like
sinc() as well. Replace the first 3 lines of the body with the ported
function (of which 2 lines do not change; the first uses code only in
mpv, and the second is just "return 1.0;"). The 4th line is only similar
on an abstract level (and that because of the mathematical relation
between these functions). Although the original sinc() was probably used
as template for it, with the other lines replaced, I don't think you
could make the claim that it falls under AGG copyright.
jinc() was added in commit 26baf5b9, but the code for it might be based
on sinc(). Rewrite it based on the "new" sinc(). Some of the same
remarks as with sphinx() apply.
cubic_bc() was ported from Glumpy's Mitchell(). (As far as I'm aware,
with the default parameters it's called "the" Mitchell-Netravali filter,
but in mpv this function is used to generate a whole group of filters.)
spline64() was added in commit a8b67c66, and was probably derived from
spline36(). Re-derive it from the "new" spline36().
triangle() could be considered derived from the original bilinear().
This is this in the original commit:
static double bilinear(kernel *k, double x)
{
return 1.0 - x;
}
This _might_ be based on AGG's image_filter_bilinear:
struct image_filter_bilinear
{
static double radius() { return 1.0; }
static double calc_weight(double x)
{
return 1.0 - x;
}
};
Considering that the "framework" was written by me, and the only part
from AGG taken is "return 1.0 - x;", and this part is trivial and was
later thoroughly replaced, this is probably not under the AGG copyright.
I'm hoping this doesn't introduce regressions. But the main focus is not
being productive anyway, and I didn't rigorously check unintended
changes in functionality.
|
|
|
|
|
| |
Since the MMAL video renderer component supports exactly what we need,
it's pretty simple.
|
|
|
|
|
|
|
|
|
|
|
| |
Apparently, the firmware will ignore pixel_x/pixel_y if the numeric
value of them gets too high (even if they indicate square pixel aspect
ratio). Even worse, the destination rectangle is ignored completely,
and the video frame is simply stretched to the screen. I suspect this
is an overflow or weird sanity check within the firmware.
Work it around by limiting the fields to 16000, which is an arbitrary
but apparently working limit.
|
|
|
|
|
|
|
|
|
| |
GLSL in GLES 2.0 did not have line continuation in its preprocessor.
This broke shader compilation. It also broke subtitle rendering in
vo_rpi, which reuses some of the OpenGL code.
Line continuation was finally added in GLES 3.0, which is perhaps the
reason why ANGLE accepted it.
|
|
|
|
| |
Fixes #2661
|
| |
|
| |
|
|
|
|
| |
Meh. Fixes #2639.
|
|
|
|
|
|
|
|
|
| |
Untested, but should be fine. Broken by commit 0a0bb905.
Also fix the include statement in context_rpi.c, which caused another
compilation failure. Also untested. (Because I'm lazy.)
Fixes #2638.
|
|
|
|
| |
See #2637.
|
|
|
|
|
|
| |
Commit f24ba544 wasn't an equivalent change.
(This shit needs some sort of automated tests.)
|
|
|
|
| |
Should fix #2635 (untested).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This removes the need to define IMGFMT_GBRAP, which fixes compilation
with the current Libav release.
This also makes it automatically pick up a GBRP format with the same bit
width. (Unfortunately, it seems libswscale does not support conversion
to AV_PIX_FMT_GBRAP16, so our code falls back to 8 bit, removing
precision for video covered by subtitles in cases this code is used.)
Also, when the source video is e.g. 10 bit YUV, upsample to 16 bit.
Whether this is good or bad, it fixes behavior with alpha. Although I'm
not sure if the alpha range is really correct ([0,2^16-1] vs.
[0,255*256]). Keep in mind that libswscale doesn't even agree with the
way we do it.
|
|
|
|
|
| |
GLSL below version 1.30 does not support mix() with a boolean
interpolation value. Use ?: instead. Untested, but probably works.
|
|
|
|
|
|
|
|
|
|
|
| |
This actually treats destination alpha correctly, and gives much better
results than before. I don't know if this is perfectly correct yet,
though. Slight difference with vo_opengl behavior suggests it might not
be.
Note that this does not affect VOs with true alpha support. vo_opengl
does not use this code at all, and does the alpha calculations in OpenGL
instead.
|
|
|
|
|
|
|
|
|
|
|
|
| |
gcc 4.8 does not support C11 thread local storage. This is a bit
annoying, so add a hack to use the gcc specific __thread extension if
C11 TLS is not available.
(This is used for the extremely silly mpv-internal way hwdec modules
access some platform specific handles. Disabling it simply made
hwdec_vaegl.c always fail initialization.)
Fixes #2631.
|
|
|
|
|
|
|
|
|
|
|
| |
Add a "blend-tiles" choice to the "alpha" sub-option. This is pretty
simplistic and uses the GL raster position to derive the tiles. A weird
consequence is that using --vo=opengl and --vo=opengl-hq gives different
scaling behavior (screenspace pixel size vs. source video pixel size
16x16 tiles), but it seems we don't have easy access to the original
texture coordinates. Using the rasterpos is probably simpler.
Make this option the default.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is for the sake of command.c and the "deinterlace" option/property.
Instead of forcing certain "better" defaults when inserting yadif,
change the actual "yadif" defaults.
I pondered not changing vf_yadif, and instead adding a trivial "yadif-
auto" wrapper filter, which would merely have different defaults. But
thinking about it, it doesn't make any sense for "deinterlace" to have
different defaults from vf_yadif, with vf_yadif having the "worse"
defaults. If someone wants the old behavior, the old behavior can be
forced in a backward and forward compatible way by setting the
suboptions.
Fixes #2539 (kind of).
|
|
|
|
|
|
|
| |
long is 64 bits on x86_64 on Linux, which means the check for the corner
case of computing the depth mask is wrong.
Also, X11 compositors seem to expect premultiplied alpha.
|
| |
|
|
|
|
|
|
|
| |
Broken by commit 0a0bb905. The changes to this filter were accidentally
simply not tested, and it was obviously broken in a bunch of ways.
Fixes #2616.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MPlayer traditionally always used the display aspect ratio, e.g. 16:9,
while FFmpeg uses the sample (aka pixel) aspect ratio.
Both have a bunch of advantages and disadvantages. Actually, it seems
using sample aspect ratio is generally nicer. The main reason for the
change is making mpv closer to how FFmpeg works in order to make life
easier. It's also nice that everything uses integer fractions instead
of floats now (except --video-aspect option/property).
Note that there is at least 1 user-visible change: vf_dsize now does
not set the display size, only the display aspect ratio. This is
because the image_params d_w/d_h fields did not just set the display
aspect, but also the size (except in encoding mode).
|
| |
|
| |
|
|
|
|
| |
Too many problems.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since alpha isn't pulled through the colormatrix (maybe it should?), we
reject alpha formats with odd sizes, such as yuva444p10.
But the awful tex_mul path in vo_opengl does this anyway (at some points
even explicitly), which means there will be a subtle difference in
handling of 16 bit yuv alpha formats. Make it consistent and always
apply the range adjustment to the alpha component. This also means odd
sizes like 10 bit are supported now.
This assumes alpha uses the same "shifted" range as the yuv color
channels for depths larger than 8 bit. I'm not sure whether this is
actually the case.
|
|
|
|
|
| |
Which is apparently what is expected here. (I'm pretty sure X11
compositors want stright alpha, so 2 code paths are needed.)
|
| |
|
|
|
|
|
|
|
|
| |
Now common.c only contains the code for the function loader, while
context.c contains the backend loader/dispatcher.
Not calling it "backend.c", because the central struct is called
MPGLContext.
|
|
|
|
|
|
|
|
|
|
| |
This is used for dithering, although I'm not aware of anyone who got
higher than 8 bit depth support to work on Linux.
Also put this into egl_helpers.c. Since EGL is pseudo-portable at best I
have no hope that the EGL context creation code in all the backends can
be fully shared. But some self-contained functionality can definitely be
shared.
|
|
|
|
|
|
|
|
|
|
|
| |
Store the determined framebuffer depth in struct GL instead of
MPGLContext. This means gl_video_set_output_depth() can be removed, and
also justifies adding new fields describing framebuffer/backend
properties to struct GL instead of having to add more functions just to
shovel the information around.
Keep in mind that mpgl_load_functions() will wipe struct GL, so the
new fields must be set before calling it.
|
|
|
|
|
| |
With --vo=opengl:alpha=yes, the Cocoa backend will now render alpha
video without background.
|
|
|
|
|
|
|
| |
Although the source file is named w32.c, the backend name was "win"
until recently. It was accidentally changed to "w32"; fix it.
Fixes #2608 (the manual is correct).
|
|
|
|
|
|
|
|
|
|
| |
This actually alows to playback alternating videos with mpv.
Tested with actual file found in wild remuxed to mkv and changed props
with following command:
mkvpropedit /tmp/o.mkv --edit track:1 -s stereo-mode=13
Signed-off-by: Paul B Mahol <onemda@gmail.com>
|
|
|
|
|
|
| |
Do actually such files exist?
Signed-off-by: Paul B Mahol <onemda@gmail.com>
|
|
|
|
| |
Signed-off-by: Paul B Mahol <onemda@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
| |
When a Direct3D 9Ex device fails to reset, it gets put into the lost
state, so set the lost_device flag and don't attempt to present until
the device moves out of that state. Failure to recreate the size-
dependent objects should set lost_device as well, since we shouldn't try
to present in that state.
Also, it looks like I was too eager to remove code that sets priv
members to NULL and I accidentally removed some that was needed.
|
|
|
|
|
|
| |
Direct3D doesn't like 0-sized swapchain dimensions, even when those
dimensions are automatically set. Manually set them to a size that isn't
zero instead.
|
|
|
|
|
|
|
|
|
| |
Why not.
Also, instead of disabling hue/saturation for RGB, just don't apply
them. (They don't make sense for conversion matrixes other than YUV, but
I can't be bothered to keep the fine-grained disabling of UI controls
either.)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
WGL_NV_DX_interop is widely supported by Nvidia and AMD drivers. It
allows a texture to be shared between Direct3D and WGL, so that
rendering can be done with WGL and presentation can be done with
Direct3D. This should allow us to work around some persistent WGL
issues, such as dropped frames with some driver/OS combos, drivers that
buffer frames to increase performance at the cost of latency, and the
inability to disable exclusive fullscreen mode when using WGL to render
to a fullscreen window.
The addition of a DX_interop backend might also enable some cool
Direct3D-specific enhancements in the future, such as using the
GetPresentStatistics API to get accurate frame presentation timestamps.
Note that due to a driver bug, this backend is currently broken on
Intel. It will appear to work as long as the window is not resized too
often, but after a few changes of size it will be unable to share the
newly created renderbuffer with GL. See:
https://software.intel.com/en-us/forums/graphics-driver-bug-reporting/topic/562051
|
|
|
|
| |
The XYZ colorspace on XYZ pixfmt is enforced in some sanitation routine.
|
|
|
|
|
|
|
|
|
|
| |
With default setting, the matrix for fruit dithering requires 12 bits
precision (values from 0/4096 to 4095/4096). But 16-bit float
provides only 10 bits. In addition, when `dither-size-fruit=8` is
set, 16 bits are required from the texture format.
Fix this by attempting to use 16 bit integer texture first. This is
still not precise, but should be better than using a half float.
|
|
|
|
|
|
| |
They're not necessarily restricted to YUV aka YCbCr.
vo_direct3d.c and demux_disc.c (DVD specific code) changes untested.
|
|
|
|
|
| |
This just seems unnecessary. Refactor it a bit. There should be no
functional changes.
|
|
|
|
|
|
|
| |
This has no reason |