Commit Graph

78 Commits

Author SHA1 Message Date
wm4 d67aa6da6b vf_eq: remove this filter
Both the video equalizer command/option glue, which drives this filter,
as well as the filter itself are slightly GPL contaminated. So it goes.

After this commit, "--vf=eq" will actually use libavfilter's vf_eq (if
FFmpeg was compiled in GPL mode), but it has different options and will
not listen to the equalizer VOCTRLs.
2017-08-22 15:58:49 +02:00
Ricardo Constantino 371000108a
TOOLS/lua/autodeint: update to lavfi-bridge
Also use lavfi setfield instead of removed field-dominance.
Remove missing remainder of field-dominance in docs.
2017-08-21 18:12:10 +01:00
wm4 028faacff5 video: add metadata handling for spherical video
This adds handling of spherical video metadata: retrieving it from
demux_lavf and demux_mkv, passing it through filters, and adjusting it
with vf_format. This does not include support for rendering this type of
video.

We don't expect we need/want to support the other projection types like
cube maps, so we don't include that for now. They can be added later as
needed.

Also raise the maximum sizes of stringified image params, since they
can get really long.
2017-08-21 14:56:07 +02:00
wm4 4bc29c1730 options: kill --field-dominance
GPL-only author, no chance of relicensing.
2017-07-21 20:00:09 +02:00
Niklas Haas 2e45b8fa1a vo_opengl: implement sony s-log2 trc
Apparently this is virtually identical to Panasonic's V-Log, but using
the constants from S-Log1 and an extra scaling coefficient to make the
S-Log1 curve less limited. Whatever floats their NIH boat, I guess.

Source: https://pro.sony.com/bbsccms/assets/files/micro/dmpc/training/S-Log2_Technical_PaperV1_0.pdf
2017-06-18 20:54:44 +02:00
Niklas Haas 326e02e955 vo_opengl: implement sony s-log1 trc
Source: https://pro.sony.com/bbsccms/assets/files/mkt/cinema/solutions/slog_manual.pdf

Not 100% confident in the implementation since the values from the spec
seem to be very subtly off (~1%), but it should be close enough for
practical purposes.
2017-06-18 20:54:44 +02:00
Niklas Haas 1f3000b03c vo_opengl: implement support for OOTFs and non-display referred content
This introduces (yet another..) mp_colorspace members, an enum `light`
(for lack of a better name) which basically tells us whether we're
dealing with scene-referred or display-referred light, but also a bit
more metadata (in which way is the scene-referred light expected to be
mapped to the display?).

The addition of this parameter accomplishes two goals:

1. Allows us to actually support HLG more-or-less correctly[1]
2. Allows people playing back direct “camera” content (e.g. v-log or
   s-log2) to treat it as scene-referred instead of display-referred

[1] Even better would be to use the display-referred OOTF instead of the
idealized OOTF, but this would require either native HLG support in
LittleCMS (unlikely) or more communication between lcms.c and
video_shaders.c than I'm remotely comfortable with

That being said, in principle we could switch our usage of the BT.1886
EOTF to the BT.709 OETF instead and treat BT.709 content as being
scene-referred under application of the 709+1886 OOTF; which moves that
particular conversion from the 3dlut to the shader code; but also allows
a) users like UliZappe to turn it off and b) supporting the full HLG
OOTF in the same framework. But I think I prefer things as they are
right now.
2017-06-18 20:54:44 +02:00
Niklas Haas fe1227883a csputils: rename HDR curves
st2084 and std-b67 are really weird names for PQ and HLG, which is what
everybody else (including e.g. the ITU-R) calls them. Follow their
example.

I decided against naming them bt2020-pq and bt2020-hlg because it's not
necessary in this case. The standard name is only used for the other
colorspaces etc. because those literally have no other names.
2017-06-18 20:54:44 +02:00
Niklas Haas c335e84230 video: refactor HDR implementation
List of changes:

1. Kill nom_peak, since it's a pointless non-field that stores nothing
   of value and is _always_ derived from ref_white anyway.

2. Kill ref_white/--target-brightness, because the only case it really
   existed for (PQ) actually doesn't need to be this general: According
   to ITU-R BT.2100, PQ *always* assumes a reference monitor with a
   white point of 100 cd/m².

3. Improve documentation and comments surrounding this stuff.
4. Clean up some of the code in general. Move stuff where it belongs.
2017-06-18 20:48:23 +02:00
wm4 c680cfd18a vf_dlopen: remove this filter
It was an attempt to move some MPlayer filters (which were removed from
mpv) to external, loadable filters. That worked well, but then the
MPlayer filters were ported to libavfilter (independently), so they're
available again. Also there is a more widely supported and more advanced
loadable filter system supported by mpv: vapoursynth.

In conclusion, vf_dlopen is not useful anymore, confusing, and requires
quite a bit of code (and probably wouldn't survive the rewrite of the
mpv video filter chain, which has to come at some point). It has some
implicit dependencies on internal conventions, like possibly the format
names dropped in the previous commit.

We also deprecated it last release. Drop it.
2017-06-18 13:55:40 +02:00
wm4 cc69650e76 af, vf: improvements to libavfilter bridge
Add the "lavfi-" prefix (details see manpage additons).

Tag the filter name as "(lavfi)" in the verbose filter list output.
2017-05-31 17:42:55 +02:00
wm4 31611fc46b video: support positional arguments for automatic lavfi option bridge
Now e.g. --vf=pad=1000:1000 works.

All in all pretty ugly and hacky. Just look away.
2017-04-03 18:12:42 +02:00
wm4 d4c1ddd6b1 video: add automatic libavfilter bridge to option parsing
Now you can for example do "--vf=hue=h=60" - there is no "hue" filter in
mpv, so libavfilter's will be used.

This has certain caveats (see manpage).

The point of this is providing a relatively smooth transition path to
removing our own filter stuff.
2017-04-02 18:47:36 +02:00
wm4 3a9e661e92 video: deprecate almost all video filters
The plan is to nuke the custom filter chain completely. It's not clear
what will happen to the still needed builtin filters (mostly hardware
deinterlacing and vf_vapoursynth). Most likely we'll replace them with
different filter chain concept (whose main purpose will be providing
builtin things and bridging to libavfilter).

The undocumented "warn" options are there to disable deprecation
warnings when the player inserts filter automatically.

The same will be done to audio filters, at a later point.
2017-04-02 18:00:16 +02:00
wm4 a94013f585 command: change and simplify filter toggle syntax
"@name:!" becomes simply "@name". This is actually slightly more complex
to parse, but makes for a much simpler syntax and will be less weird to
the user. Suggested by haasn.

The old syntax is now rejected with an error.

Also add some more explicit error checks, instead of e.g. allowing empty
filter names and erroring only when it's not found.
2017-03-26 13:13:34 +02:00
wm4 7d424b4ce4 command: add better runtime filter toggling method
Basically, see the example in input.rst.

This is better than the "old" vf-toggle method, because it doesn't
require the user to duplicate the filter string in mpv.conf and
input.conf.

Some aspects of this changes are untested, so enjoy your alpha testing.
2017-03-25 17:07:40 +01:00
wm4 7eb32240c9 manpage: adjust description of libva deinterlacer ref direction mess
Relevant:

https://cgit.freedesktop.org/mesa/mesa/commit/?id=0798fddb5000f2b1edffc693ec65236a680ce61f

Eventually I'll just remove this option. But it's probably good to leave
it for while, possibly for letting Mesa VA driver users test and confirm
this.
2017-03-07 09:10:37 +01:00
wm4 75fc2bee1e vf_vavpp: add advanced deint bug compatibility for Intel vaapi drivers
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.
2017-02-28 00:57:51 +01:00
wm4 07b6969ba4 vf_vdpaurb: remove this filter
Was deprecated, superseded by --hwdec=vdpau-copy.
2016-11-22 15:54:44 +01:00
wm4 5da510b5fc vf_vdpaurb: deprecate this filter 2016-10-20 16:45:48 +02:00
wm4 358932a109 vf_d3d11vpp: add video processor selection
Unfortunately completely useless. I still don't know how to force a
video processor to use a specific algorithm, if it's even possible.
2016-07-15 19:48:58 +02:00
Jakub Wilk da9590d368 man: fix typos 2016-07-09 16:27:42 +02:00
Niklas Haas f3b6966d14 vo_opengl: implement the Panasonic V-Log function
User request and not that hard. Closes #3157.

Note that FFmpeg doesn't support this and there's no signalling in HEVC
etc., so the only way users can access it is by using vf_format
manually.

Mind: This encoding uses full range values, not TV range.
2016-06-28 19:48:29 +02:00
Niklas Haas 740fdc139f manpage: add missing documentation for vf_format:gamma=dci-p3 2016-06-28 19:48:29 +02:00
Niklas Haas 247ec0cb84 csputils: add Panasonic V-Gamut primaries
This is actually not entirely trivial since it involves negative Yxy
coordinates, so the CMM has to be capable of full floating point
operation. Fortunately, LittleCMS is, so we can just blindly implement
it.
2016-06-28 19:48:29 +02:00
Niklas Haas 9278ce98f7 vo_opengl: implement ARIB STD-B68 (HLG) HDR TRC
This HDR function is unique in that it's still display-referred, it just
allows for values above the reference peak (super-highlights). The
official standard doesn't actually document this very well, but the
nominal peak turns out to be exactly 12.0 - so we normalize to this
value internally in mpv. (This lets us preserve the property that the
textures are encoded in the range [0,1], preventing clipping and making
the best use of an integer texture's range)

This was grouped together with SMPTE ST2084 when checking libavutil
compatibility since they were added in the same release window, in a
similar timeframe.
2016-06-28 19:48:29 +02:00
Niklas Haas 45c3e0f0d0 vo_opengl: refactor HDR mechanism
Instead of doing HDR tone mapping on an ad-hoc basis inside
pass_colormanage, the reference peak of an image is now part of the
image params (alongside colorspace, gamma, etc.) and tone mapping is
done whenever peak_src != peak_dst.

To get sensible behavior when mixing HDR and SDR content and displays,
target-brightness is a generic filler for "the assumed brightness of SDR
content".

This gets rid of the weird display_scaled hack, sets the framework
for multiple HDR functions with difference reference peaks, and allows
us to (in a future commit) autodetect the right source peak from
the HDR metadata.

(Apart from metadata, the source peak can also be controlled via
vf_format. For HDR content this adjusts the overall image brightness,
for SDR content it's like simulating a different exposure)
2016-05-30 20:17:33 +02:00
wm4 49f73eaf7b vf_d3d11vpp: add a D3D11 video processor filter
Main use: deinterlacing.

I'm not sure how to select the deinterlacing mode at all. You can
enumate the available video processors, but at least on Intel, all of
them either signal support for all deinterlacers, or none (the latter is
apparently used for IVTC). I haven't found anything that actually tells
the processor _which_ algorithm to use.

Another strange detail is how to select top/bottom fields and field
dominance. At least I'm getting quite similar results to vavpp on Linux,
so I'm content with it for now.

Future plans include removing the D3D11 video processor use from the
ANGLE interop code.
2016-05-28 19:28:08 +02:00
Niklas Haas f81f486c68 vo_opengl: implement HDR (SMPTE ST2084)
Currently, this relies on the user manually entering their display
brightness (since we have no way to detect this at runtime or from ICC
metadata). The default value of 250 was picked by looking at ~10 reviews
on tftcentral.co.uk and realizing they all come with around 250 cd/m^2
out of the box. (In addition, ITU-R Rec. BT.2022 supports this)

Since there is no metadata in FFmpeg to indicate usage of this TRC, the
only way to actually play HDR content currently is to set
``--vf=format=gamma=st2084``. (It could be guessed based on SEI, but
this is not implemented yet)

Incidentally, since SEI is ignored, it's currently assumed that all
content is scaled to 10,000 cd/m^2 (and hard-clipped where out of
range). I don't see this assumption changing much, though.

As an unfortunate consequence of the fact that we don't know the display
brightness, mixed with the fact that LittleCMS' parametric tone curves
are not flexible enough to support PQ, we have to build the 3DLUT
against gamma 2.2 if it's used. This might be a good thing, though,
consdering the PQ source space is probably not fantastic for
interpolation either way.

Partially addresses #2572.
2016-05-16 02:45:39 +02:00
Niklas Haas 7c5188c27e DOCS: update documentation related to color management
Some of this documentation was left woefully inaccurate as color
management in mpv evolved. This commit updates all of the wording and
adds notes and comments where appropriate.
2016-05-06 18:09:17 +02:00
Niklas Haas eff2e575f1 manpage: fix indenting issue in vf_format 2016-02-11 00:14:12 +01:00
wm4 7fa06e46c4 vf_yadif: change defaults
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).
2015-12-21 22:05:40 +01:00
wm4 0a0bb9059f video: switch from using display aspect to sample aspect
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).
2015-12-19 20:45:36 +01:00
Martin Herkt fc9eef3b81
man: fix grammar issues 2015-12-19 09:26:41 +01:00
Kevin Mitchell 4f103b2093 manpage: deinterlace is now the lowercase d
there were a few places that that used an upper case D
and one that still actually said Shift+D
2015-11-23 15:18:52 -08:00
wm4 ee63c9c210 video: replace vf_format outputlevels option with global option
The vf_format suboption is replaced with --video-output-levels (a global
option and property). In particular, the parameter is removed from
mp_image_params. The mechanism is moved to the "video equalizer", which
also handles common video output customization like brightness and
contrast controls.

The new code is slightly cleaner, and the top-level option is slightly
more user-friendly than as vf_format sub-option.
2015-09-29 21:12:26 +02:00
wm4 fea1e09a9c manpage: add a note about libavfilter 2015-09-11 23:48:47 +02:00
wm4 7020908691 video/filter: remove some vf_lavfi wrappers
I see no point in keeping these around. Keeping wrappers for some select
libavfilter filters just because MPlayer had these filters is not a good
reason.

Ultimately, all real filtering work should go to libavfilter, and users
should get used to using vf_lavfi directly. We might even not require
the awful double-nested syntax for using libavfilter one day.

vf_rotate, vf_yadif, vf_stereo3d are kept because mpv uses them
internally. (They all extend the lavfi filters or change their
defaults.) vf_mirror is kept for symmetry with vf_flip. vf_gradfun and
vf_pullup are probably semi-popular, so I'll remove them not yet - only
after some more discussion.
2015-09-11 23:47:00 +02:00
Philip Langdale 4b0b9b515b vf_vdpaurb: Add a new filter for reading back vdpau decoded frames
Normally, vdpau decoded frames are passed directly to a suitable
vo (vo_vdpau or vo_opengl) without ever touching system memory. This
is efficient for output purposes, but prevents any of the regular
filters from being used with such frames.

This new filter implements a read-back step to pull the frames back
into system memory where they can be acted on by other filters.
Eventually the frames will be sent to the vo as if they were normal
software-decoded frames.

Note that a vdpau compatible vo must still be used to ensure that
the decoder is properly initialised.

Signed-off-by: wm4 <wm4@nowhere>
2015-07-11 10:44:34 +02:00
wm4 ef7278b4fd vf_vdpaupp: don't attempt to deinterlace progressive frames 2015-07-08 15:14:38 +02:00
wm4 4781f9e69a vf_vavpp: don't attempt to deinterlace progressive frames 2015-07-08 14:48:11 +02:00
wm4 0ebf5979d1 command: make deinterlace property use interlaced-only yadif mode 2015-07-07 15:19:40 +02:00
wm4 25755f5fe7 vf_yadif: expose interlaced frame mode
Also remove the enabled suboption, which did nothing. (It was probably
broken at some point.)
2015-07-07 15:18:56 +02:00
Daniel Bergmann 8b479d2f66 DOCS/man: fix some grammar errors
Signed-off-by: wm4 <wm4@nowhere>
2015-06-29 19:03:51 +02:00
rrooij a87b18aa5a DOCS/manpage: fix typos
Fix some errors in the man pages by spell checking them. Most of them
were typos.

Signed-off-by: wm4 <wm4@nowhere>
2015-06-17 20:13:34 +02:00
wm4 3fc3357d54 vf_dlopen: declare as deprecated
Mostly to see whether someone uses it, and if a better solution can be
worked out. (It's simple enough to be supported forever.)
2015-05-25 21:13:54 +02:00
wm4 e57a44c341 manpage: fix syntax
I guess this wasn't meant to be literal syntax, but it implies "," is
used as sub-option separator.
2015-05-19 21:38:19 +02:00
wm4 0c70f94c53 manpage: update colormatrix property description 2015-04-27 17:51:06 +02:00
wm4 f4292ebf52 vf_screenshot: remove this filter
It's entirely useless, especially now that vo.c handles screenshots in a
generic way, and requires no special VO support. There are some
potential weird use-cases, but actually I've never seen it being used.
2015-04-16 22:16:04 +02:00
Niklas Haas 717e7a5baa vf_format: add gamma override option 2015-04-04 15:48:38 +02:00