Commit Graph

63 Commits

Author SHA1 Message Date
Philip Langdale 77e7f5de2c sws_utils: update to handle deprecation of `avcodec_enum_to_chroma_pos`
This has been replaced by `av_chroma_location_enum_to_pos`.
2022-12-01 10:45:47 -08:00
wm4 083adf97e1 sws_utils: work around libswscale corrupting memory yet again
If the alignment is less than 16, certain libswscale code paths will
silently corrupt memory outside of the target buffer. This actually
affected the libmpv software rendering API (that was fun to debug).
Rather than passing this problem to the next API user, try to avoid it
within libmpv.

It's unclear which alignment libswscale requires for safe operation. I'm
picking 32 (one more than the observed safe value in the case I
experienced), because libavfilter mostly uses this value.

The way to work this around is slow: just make a full copy of the entire
input or output image. Possibly this could be optimized by using the
slice API, but that would be more effort, and would likely expose
further libswscale bugs. Hope that this is a rarely needed path.

The next commit will update the alignment requirement documentation
bits.
2020-09-17 15:24:27 +02:00
wm4 b961efb0af sws_utils: do not mutate src/dst parameters
Probably did not cause any practical problems, but it sure seems
unclean. sws_utils users might also rely on these fields being exactly
the same as the actual input/output. It's better to avoid this.
2020-07-08 22:45:12 +02:00
wm4 eb27baf5ec video: remove useless mp_imgfmt_desc.avformat field
Had 1 user; easily replaced.
2020-05-20 18:38:19 +02:00
wm4 caee8748da video: clean up some imgfmt related stuff
Remove the vaguely defined plane_bits and component_bits fields from
struct mp_imgfmt_desc. Add weird replacements for existing uses. Remove
the bytes[] field, replace uses with bpp[].

Fix some potential alignment issues in existing code. As a compromise,
split mp_image_pixel_ptr() into 2 functions, because I think it's a bad
idea to implicitly round, but for some callers being slightly less
strict is convenient.

This shouldn't really change anything. In fact, it's a 100% useless
change. I'm just cleaning up what I started almost 8 years ago (see
commit 00653a3eb0). With this I've decided to keep mp_imgfmt_desc,
just removing the weird parts, and keeping the saner parts.
2020-05-18 01:54:59 +02:00
wm4 d61ced37ae sws_utils: allow setting zimg options directly
One could wonder, why not just use the zimg wrapper directly?
2020-05-09 18:02:57 +02:00
wm4 8909bf3317 sws_utils: remove unused brightness etc. controls
Used to be used by vo_x11, and some other situations where software
conversion was employed. Haven't seen anyone complain about how software
brightness controls went away (originating from mplayer), so whatever,
it won't be needed again.
2020-04-24 14:31:11 +02:00
wm4 c99d95ac17 vf_format: add gross mechanism for forcing scaler for testing
This sucks, but is helpful for testing.

Obviously, it would be much nicer if there were a way to specify _all_
scaler options per filter (if the user wanted), instead of always using
the global options. But this is "too hard" for now. For testing, it is
extremely convenient to select the scaler backend, so add this option,
but make clear that it could go away. We'd delete it once there is a
better mechanism for this.
2020-04-13 15:56:27 +02:00
wm4 26f4f18c06 options: change option macros and all option declarations
Change all OPT_* macros such that they don't define the entire m_option
initializer, and instead expand only to a part of it, which sets certain
fields. This requires changing almost every option declaration, because
they all use these macros. A declaration now always starts with

   {"name", ...

followed by designated initializers only (possibly wrapped in macros).
The OPT_* macros now initialize the .offset and .type fields only,
sometimes also .priv and others.

I think this change makes the option macros less tricky. The old code
had to stuff everything into macro arguments (and attempted to allow
setting arbitrary fields by letting the user pass designated
initializers in the vararg parts). Some of this was made messy due to
C99 and C11 not allowing 0-sized varargs with ',' removal. It's also
possible that this change is pointless, other than cosmetic preferences.

Not too happy about some things. For example, the OPT_CHOICE()
indentation I applied looks a bit ugly.

Much of this change was done with regex search&replace, but some places
required manual editing. In particular, code in "obscure" areas (which I
didn't include in compilation) might be broken now.

In wayland_common.c the author of some option declarations confused the
flags parameter with the default value (though the default value was
also properly set below). I fixed this with this change.
2020-03-18 19:52:01 +01:00
wm4 7d11eda72e Remove remains of Libav compatibility
Libav seems rather dead: no release for 2 years, no new git commits in
master for almost a year (with one exception ~6 months ago). From what I
can tell, some developers resigned themselves to the horrifying idea to
post patches to ffmpeg-devel instead, while the rest of the developers
went on to greener pastures.

Libav was a better project than FFmpeg. Unfortunately, FFmpeg won,
because it managed to keep the name and website. Libav was pushed more
and more into obscurity: while there was initially a big push for Libav,
FFmpeg just remained "in place" and visible for most people. FFmpeg was
slowly draining all manpower and energy from Libav. A big part of this
was that FFmpeg stole code from Libav (regular merges of the entire
Libav git tree), making it some sort of Frankenstein mirror of Libav,
think decaying zombie with additional legs ("features") nailed to it.
"Stealing" surely is the wrong word; I'm just aping the language that
some of the FFmpeg members used to use. All that is in the past now, I'm
probably the only person left who is annoyed by this, and with this
commit I'm putting this decade long problem finally to an end. I just
thought I'd express my annoyance about this fucking shitshow one last
time.

The most intrusive change in this commit is the resample filter, which
originally used libavresample. Since the FFmpeg developer refused to
enable libavresample by default for drama reasons, and the API was
slightly different, so the filter used some big preprocessor mess to
make it compatible to libswresample. All that falls away now. The
simplification to the build system is also significant.
2020-02-16 15:14:55 +01:00
wm4 c3f93f5fdd sws_utils: use zimg by default if available
This seems stable enough to use. Change the default, and remove it from
the sw-fast profile.
2020-02-12 18:06:53 +01:00
wm4 a19571679f sws_utils: remove some unnecessary sws bug work around
Seems like this was needed in 2012. The comment indicates the bug was
fixed in ffmpeg git, so it's long gone.
2019-11-03 22:48:49 +01:00
wm4 e58e650a97 video: mess with the filte chain to enable zimg IMGFMT_RGB30 output
This was too hardcoded to libswscale. In particular, IMGFMT_RGB30 output
is only possible with the zimg wrapper, so the context needs to be taken
into account (since this depends on the --sws-allow-zimg option
dynamically). This is still slightly risky, because zimg currently will
still fall back to swscale in some cases, such as when it refuses to
initialize the particular color conversion that is requested.
f_autoconvert.c could actually handle this better, but I'm tool fucking
lazy right now, and nobody cares anyway, so go away, OK?
2019-11-02 17:50:32 +01:00
wm4 a7230dfed0 sws_utils, zimg: destroy vo_x11 and vo_drm performance
Raise swscale and zimg default parameters. This restores screenshot
quality settings (maybe) unset in the commit before. Also expose some
more libswscale and zimg options.

Since these options are also used for VOs like x11 and drm, this will
make x11/drm/etc. much slower. For compensation, provide a profile that
sets the old option values: sw-fast. I'm also enabling zimg here, just
as an experiment.

The core problem is that we have a single set of command line options
which control the settings used for most swscale/zimg uses. This was
done in the previous commit. It cannot differentiate between the VOs,
which need to be realtime and may accept/require lower quality options,
and things like screenshots or vo_image, which can be slower, but should
not sacrifice quality by default.

Should this have two sets of options or something similar to do the
right thing depending on the code which calls libswscale? Maybe. Or
should I just ignore the problem, make it someone else's problem (users
who want to use software conversion VOs), provide a sub-optimal
solution, and call it a day? Definitely, sounds good, pushing to master,
goodbye.
2019-10-31 16:51:12 +01:00
wm4 835586513d sws_utils: shuffle around some shit
Purpose uncertain. I guess it's slightly better, maybe.

The move of the sws/zimg options from VO opts (vo_opt_list) to the
top-level option list is tricky. VO opts have some helper code in vo.c,
that sends VOCTRL_SET_PANSCAN to the VO on every VO opts change. That's
because updating certain VO options used to be this way (and not just
the panscan option). This isn't needed anymore for sws/zimg options, so
explicitly move them away.
2019-10-31 15:26:03 +01:00
wm4 8a4e9d5c18 sws_utils: improve zimg fallback messages
This could log:

  [swscale] falling back to swscale

And that's a WTF, even if you're aware of the fucky way zimg was hacked
into the filter chain.
2019-10-21 01:38:25 +02:00
wm4 62bd8da490 sws_utils: provide function to check whether a format pair is supported
Normally, input and output are orthogonal. But zimg may gain image
formats not supported by FFmpeg, which means the conversion will only
work if zimg is used at all. This on the other hand, depends on whether
the other format is also supported by zimg. (For example, a later commit
adds RGB30 output to zimg. libswscale does not support this format. But
if you have P010 as input, which the zimg wrapper does not support at
all, the conversion won't work.)

This makes such a function needed; so add it.
2019-10-20 19:41:18 +02:00
wm4 3568aed164 sws_utils: make libswscale fallback a warning
Surely a user passing --sws-allow-zimg wants to know if zimg is actually
used.
2019-10-20 16:16:28 +02:00
wm4 51e141f7ba sws_utils: hack in zimg redirection support
Awful shit. I probably wouldn't accept this code from someone else, just
so you know.

The idea is that a sws_utils user can automatically use zimg without
large code changes. Basically, laziness. Since zimg support is still
very new, and I don't want that anything breaks just because zimg was
enabled at build time, an option needs to be set to enable it. (I have
especially especially obscure stuff in mind, which is all what
libswscale is used in mpv.)

This _still_ doesn't cause zimg to be used anywhere, because the
sws_utils user has to opt-in by setting allow_zimg. This is because some
users depend on certain libswscale features.
2019-10-20 02:17:31 +02:00
wm4 ca67928d7a sws_utils: don't force callers to provide option struct
mp_sws_set_from_cmdline() has the only purpose to respect the --sws-
command line options. Instead of forcing callers to get the option
struct containing these, let callers pass mpv_global, and get it from
the option core code directly. This avoids minor annoyances later on.
2018-01-18 00:59:07 -08:00
wm4 d652d479f1 video: avoid some unnecessary vf.h includes 2018-01-18 00:59:07 -08:00
wm4 bfa9b62858 build: add preliminary LGPL mode
See "Copyright" file for caveats.

This changes the remaining "almost LGPL" files to LGPL, because we think
that the conditions the author set for these was finally fulfilled.
2017-09-21 13:56:27 +02:00
wm4 03cf150ff3 video: redo video equalizer option handling
I really wouldn't care much about this, but some parts of the core code
are under HAVE_GPL, so there's some need to get rid of it. Simply turn
the video equalizer from its current fine-grained handling with vf/vo
fallbacks into global options. This makes updating them much simpler.

This removes any possibility of applying video equalizers in filters,
which affects vf_scale, and the previously removed vf_eq. Not a big
loss, since the preferred VOs have this builtin.

Remove video equalizer handling from vo_direct3d, vo_sdl, vo_vaapi, and
vo_xv. I'm not going to waste my time on these legacy VOs.

vo.eq_opts_cache exists _only_ to send a VOCTRL_SET_EQUALIZER, which
exists _only_ to trigger a redraw. This seems silly, but for now I feel
like this is less of a pain. The rest of the equalizer using code is
self-updating.

See commit 96b906a51d for how some video equalizer code was GPL only.
Some command line option names and ranges can probably be traced back to
a GPL only committer, but we don't consider these copyrightable.
2017-08-22 17:01:35 +02:00
wm4 aee81828e2 sws_utils: switch back to GPL
Actually contains some code fragments by Michael Niedermayer (command
line stuff, video equalizer), thus it can be LGPL only once the formal
requirement of mpv's core being LGPL is fulfilled.
2017-07-01 12:51:18 +02:00
wm4 b14fac9afa build: replace some FFmpeg API checks with version checks
The FFmpeg versions we support all have the APIs we were checking for.
Only Libav missed them. Simplify this by explicitly checking for FFmpeg
in the code, instead of trying to detect the presence of the API.
2017-01-24 08:11:42 +01:00
Niklas Haas d81fb97f45 mp_image: split colorimetry metadata into its own struct
This has two reasons:

1. I tend to add new fields to this metadata, and every time I've done
so I've consistently forgotten to update all of the dozens of places in
which this colorimetry metadata might end up getting used. While most
usages don't really care about most of the metadata, sometimes the
intend was simply to “copy” the colorimetry metadata from one struct to
another. With this being inside a substruct, those lines of code can now
simply read a.color = b.color without having to care about added or
removed fields.

2. It makes the type definitions nicer for upcoming refactors.

In going through all of the usages, I also expanded a few where I felt
that omitting the “young” fields was a bug.
2016-07-03 19:42:52 +02:00
wm4 8a9b64329c Relicense some non-MPlayer source files to LGPL 2.1 or later
This covers source files which were added in mplayer2 and mpv times
only, and where all code is covered by LGPL relicensing agreements.

There are probably more files to which this applies, but I'm being
conservative here.

A file named ao_sdl.c exists in MPlayer too, but the mpv one is a
complete rewrite, and was added some time after the original ao_sdl.c
was removed. The same applies to vo_sdl.c, for which the SDL2 API is
radically different in addition (MPlayer supports SDL 1.2 only).

common.c contains only code written by me. But common.h is a strange
case: although it originally was named mp_common.h and exists in MPlayer
too, by now it contains only definitions written by uau and me. The
exceptions are the CONTROL_ defines - thus not changing the license of
common.h yet.

codec_tags.c contained once large tables generated from MPlayer's
codecs.conf, but all of these tables were removed.

From demux_playlist.c I'm removing a code fragment from someone who was
not asked; this probably could be done later (see commit 15dccc37).

misc.c is a bit complicated to reason about (it was split off mplayer.c
and thus contains random functions out of this file), but actually all
functions have been added post-MPlayer. Except get_relative_time(),
which was written by uau, but looks similar to 3 different versions of
something similar in each of the Unix/win32/OSX timer source files. I'm
not sure what that means in regards to copyright, so I've just moved it
into another still-GPL source file for now.

screenshot.c once had some minor parts of MPlayer's vf_screenshot.c, but
they're all gone.
2016-01-19 18:36:06 +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
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
Niklas Haas 08d3ef3d9e
sws_utils: re-use avcolorspace for sws colorspaces
This lets us avoid having to maintain two separate copies of the
colorspace mapping functions.
2015-05-04 01:34:25 +02:00
Marcin Kurczewski f43017bfe9 Update license headers
Signed-off-by: wm4 <wm4@nowhere>
2015-04-13 12:10:01 +02:00
wm4 08199a64d2 vf_scale: libswscale is being stupid
This time (there are a lot of times), libswscale randomly ignores
brightness/saturation/contrast settings.

Looking at MPlayer code, it appears the return value of
sws_setColorspaceDetails() signals if changing these settings is
supported at all.

(Nevermind that supporting this feature has almost 0 value, and
obviously eats maintenance time.)
2015-03-01 22:32:38 +01:00
wm4 be5994a781 video: work around libswscale for PNG pixel formats
The intention is that we can test vo_opengl with high bit depth PNGs
better. This throws libswscale completely out of the loop, which before
was needed in order to convert from big endian to little endian.

Also apply a minimal cleanup to fmt-conversion.c (unrelated).
2015-02-06 23:22:16 +01:00
wm4 c118d8f6cc image_writer: check for conversion errors
This can happen when e.g. a VO returns a screenshot in an unsupported
format.
2015-01-15 20:10:08 +01:00
wm4 a28e2a7432 video: correct spelling: mp_image_params_equals -> mp_image_params_equal
The type is struct mp_image_params, so the "params" should have a "s".
"equals" shouldn't, because it's plural for 2 params. Important.
2014-06-17 23:30:27 +02:00
wm4 efa6b09b65 video: remove redundant function
mp_image_params_from_image() is now trivial and can be removed.
2014-06-17 23:26:53 +02:00
wm4 fd5207f56d options: remove global variables for swscale options; rename them
Additionally to removing the global variables, this makes the options
more uniform. --ssf-... becomes --sws-..., and --sws becomes --sws-
scaler. For --sws-scaler, use choices instead of magic integer values.
2014-06-11 00:39:13 +02:00
wm4 a20aa15969 sws_utils: remove custom GBRP conversion
We needed this because the OSD rendering path used GBRP for RGB
rendering, and not all swscale versions supported this conversion. But
recently we've dropped support for very old ffmpeg/libav versions, so
this isn't needed anymore.
2014-04-10 00:07:25 +02:00
wm4 38342436cd sws_utils: mp_msg conversions
This requires the caller to provide a mp_log in order to see error
messages. Unfortunately we don't do this in most places, but I guess we
have to live with it.
2013-12-21 20:50:10 +01:00
wm4 2c08bf1bd7 Reduce recursive config.h inclusions in headers
In my opinion, config.h inclusions should be kept to a minimum. MPlayer
code really liked including config.h everywhere, though, even in often
used header files. Try to reduce this.
2013-12-18 17:12:21 +01:00
wm4 0112143fda Split mpvcore/ into common/, misc/, bstr/ 2013-12-17 02:39:45 +01:00
wm4 597b8a3550 Take care of some libavutil deprecations, drop support for FFmpeg 1.0
PIX_FMT_* -> AV_PIX_FMT_* (except some pixdesc constants)
enum PixelFormat -> enum AVPixelFormat
Losen some version checks in certain newer pixel formats.
av_pix_fmt_descriptors -> av_pix_fmt_desc_get

This removes support for FFmpeg 1.0.x, which is even older than
Libav 9.x. Support for it probably was already broken, and its
libswresample was rejected by our build system anyway because it's
broken.

Mostly untested; it does compile with Libav 9.9.
2013-11-29 17:39:57 +01:00
wm4 e0b6fdeb8d Fix some more -Wshadow warnings
These aren't printed with newer gcc or clang versions for some reason.

All of them seem to be about local variables shadowing global functions.
2013-11-01 17:35:38 +01:00
wm4 1eda9554d4 sws_utils: work around libswscale crash with --contrast=-100 2013-10-16 21:39:51 +02:00
wm4 c613d802bc talloc: change talloc destructor signature
Change talloc destructor so that they can never signal failure, and
don't return a status code. This makes our talloc copy even more
incompatible to upstream talloc, but on the other hand this is
preparation for getting rid of talloc entirely.

(The talloc replacement in the next commit won't allow the talloc_free
equivalent to fail, and the destructor return value would be useless.
But I don't want to change any mpv code either; the idea is that the
talloc replacement commit can be reverted for some time in order to
test whether the talloc replacement introduced a regression.)
2013-10-13 01:16:30 +02:00
wm4 00d41cc5b0 vf_scale: factor out libswscale equalizer control
Will be used by vo_x11.
2013-09-30 00:45:58 +02:00
wm4 47e92b2f88 video: handle video output levels with mp_image_params
Until now, video output levels (obscure feature, like using TV screens
that require RGB output in limited range, similar to YUY) still required
handling of VOCTRL_SET_YUV_COLORSPACE. Simplify this, and use the new
mp_image_params code. This gets rid of some code. VOCTRL_SET_YUV_COLORSPACE
is not needed at all anymore in VOs that use the reconfig callback. The
result of VOCTRL_GET_YUV_COLORSPACE is now used only used for the
colormatrix related properties (basically, for display on OSD).  For
other VOs, VOCTRL_SET_YUV_COLORSPACE will be sent only once after config
instead of twice.
2013-08-24 19:40:18 +02:00
wm4 c7da4ba744 img_convert: add function to scale RGBA OSD images 2013-08-12 00:51:31 +02:00
Stefano Pigozzi 406241005e core: move contents to mpvcore (2/2)
Followup commit. Fixes all the files references.
2013-08-06 22:52:31 +02:00
wm4 9cc5630fd5 video: support setting libswscale chroma position 2013-07-25 23:03:20 +02:00