Commit Graph

66 Commits

Author SHA1 Message Date
sfan5 39630dc8b6 build: address AVCodec, AVInputFormat, AVOutputFormat const warnings
FFmpeg recently changed these to be const on their side.
2021-05-01 22:07:31 +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 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 2c43d2b75a screenshot, vo_image: use global swscale/zimg parameters
Lots of dumb crap to do... something. Instead of adding yet another dumb
helper, just use the main" sws_utils API in both callers. (Which,
unfortunately, has been duplicated for glorious webp screenshots,
despite the fact that webp is crap.)

Good part: can enable zimg for screenshots (as far as needed).
Bad part: uses "default" swscale parameters instead of HQ now.
2019-10-31 15:44:09 +01:00
sfan5 ee0f4444f9 image_writer: add webp-compression option 2019-09-14 23:02:39 +02:00
sfan5 0f79444c6d image_writer: add WebP support (lossy or lossless) 2019-09-14 23:02:39 +02:00
sfan5 8925f10962 image_writer: move convert_image() to player/screenshot.c 2019-09-14 23:02:39 +02:00
wm4 9f595f3a80 vo_gpu: make screenshots use the GL renderer
Using the GL renderer for color conversion will make sure screenshots
will use the same conversion as normal video rendering. It can do this
for all types of screenshots.

The logic when to write 16 bit PNGs changes. To approximate the old
behavior, we decide by looking whether the source video format has more
than 8 bits per component. We apply this logic even for window
screenshots. Also, 16 bit PNGs now always include an unused alpha
channel. The reason is that FFmpeg has RGB48 and RGBA64 formats, but no
RGB064. RGB48 is 3 bytes and usually not supported by GPUs for
rendering, so we have to use RGBA64, which forces an alpha channel.

Will break for users who use --target-trc and similar options.

I considered creating a new gl_video context, but it could double GPU
memory use, so I didn't.

This uses FBOs instead of glGetTexImage(), because that increases the
chance it could work on GLES (e.g. ANGLE). Untested. No support for the
Vulkan and D3D11 backends yet.

Fixes #5498. Also fixes #5240, because the code for reading back is not
used with the new code path.
2018-02-11 17:45:51 -08:00
wm4 ddd068491c Replace remaining avcodec_close() calls
This API isn't deprecated (yet?), but it's still inferior and harder to
use than avcodec_free_context().

Leave the call only in 1 case in af_lavcac3enc.c, where we apparently
seriously close and reopen the encoder for whatever reason.
2017-07-16 12:51:48 +02:00
wm4 078b275514 image_writer, vo_image: change license to LGPL
image_writer.c has code originating from vf_screenshot.c, vo_jpeg.c, and
potentially others. vo_image.c is based on a bunch of those VOs as well,
and the intention was to replace them with a single codebase.

vo_tga.c was written by someone who was not or not could be contacted,
but it doesn't matter anyway, as no code from that initial patch was
used.

One rather old patch (57f77bb41a) reordered by libjpeg patch API calls,
and the author of the patch was not contacted. But at least with the
smoothing_factor override removed, this pretty much exactly corresponds
to the official libjpeg API example (and might even reflect a change to
those - didn't dig deeper). This removes the -jpeg-smooth option. While
we're at it, remove all the other dropped jpeg options from the manpage
(which was forgotten in past changes).
2017-06-18 15:45:24 +02:00
wm4 6100a7d75f image_writer: make it work with libavcodec's jpg encoder
Now taking a screenshot actually works, if libjpeg is disabled at
compile time.

In particular, the AV_PIX_FMT_YUVJ formats (with the "J") cause us
problems. They have been deprecated years ago, but the libavcodec jpg
encoder won't accept anything else. This is made worse by the fact that
mpv doesn't have J formats internally - it always uses the color levels
metadata to decide the range instead.
2017-04-02 17:21:42 +02:00
wm4 46e3dc27af screenshot: change details of --screenshot-format handling
This is just a pointless refactor with the only goal of making
image_writer_opts.format a number.

The pointless part of it is that instead of using some sort of arbitrary
ID (in place of a file extension string), we use a AV_CODEC_ID_. There
was also some idea of falling back to the libavcodec MJPEG encoder if
mpv was not linked against libjpeg, but this fails. libavcodec insist on
having AV_PIX_FMT_YUVJ420P, which we pretend does not exist, and which
we always map to AV_PIX_FMT_YUV420P (without the J indicating full
range), so encoder init fails. This is pretty dumb, but whatever. The
not-caring factor is raised by the fact that we don't know that we
should convert to full range, because encoders have no proper way to
signal this. (Be reminded that AV_PIX_FMT_YUVJ420P is deprecated.)
2017-03-18 15:03:05 +01:00
wm4 8e75297c26 image_writer: remove useless formats
Nobody cares about those.
2017-03-18 14:24:53 +01:00
wm4 8c701587c8 image_writer: check a return value
Doesn't matter, since it's the flush call, but be nice. In particular,
don't upset coverity.
2017-02-20 14:05:14 +01:00
wm4 3eceac2eab Remove compatibility things
Possible with bumped FFmpeg/Libav.

These are just the simple cases.
2016-12-07 19:53:11 +01:00
wm4 9e6b9d8a98 vo_image: move to global options
This is a bit "special", because the config tree wants unique
m_sub_options pointers in the whole thing.
2016-09-05 21:04:55 +02: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 393bb2a565 image_writer: port to new encode API 2016-06-24 18:20:36 +02:00
wm4 3d09bd77dd image_writer: take care of prediction_method deprecation
The field was recently deprecated, and you're supposed to set the
private codec option instead.

Not sure if this really works as intended.
2016-02-09 13:24:04 +01:00
wm4 7b4ccb3e9f image_writer: fix writing flipped images as jpg
next_scanline is usually an unsigned int.

Fixes #2635 (again).
2016-01-17 22:26:38 +01:00
Dmitrij D. Czarkoff ea442fa047 mpv_talloc.h: rename from talloc.h
This change helps avoiding conflict with talloc.h from libtalloc.
2016-01-11 21:05:55 +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 3c081dfd93 Replace deprecated av_free_packet() calls
av_free_packet() got finally deprecated. Use av_packet_unref() instead,
which has almost the same semantics, has existed for a while, and is
available in all FFmpeg and Libav versions we support.
2015-10-28 23:48:56 +01:00
wm4 aa0157d9b8 image_writer: don't use jpeg baseline, and remove useless jpeg options
The jpeg-optimize and jpeg-baseline options were undocumented, and
they're also pretty useless. There's no reason to ever change them.

Also, don't write jpeg baseline images. This just makes compression
worse for the sake of rather questionable compatibility with ancient
decoders.
2015-08-02 01:10:18 +02:00
wm4 050c529e9a screenshot: don't write PNG colorspace tags by default
Generates too much discussion and confusion.

Fixes #2051.
2015-07-18 18:33:54 +02:00
wm4 d51dee093f screenshots: add option to prevent 16 bit output
That's what it's usually about (again).
2015-04-29 21:05:04 +02:00
wm4 f07c9b16f9 screenshots: add option to disable JPEG 4:4:4 output
That's what it's usually about.
2015-04-29 21:01:08 +02:00
wm4 777273c064 image_writer: fix writing screenshots
It passed the unconverted image to the writer function. Broken since
2469cb5d.
2015-04-22 16:28:31 +02:00
wm4 2469cb5d1f image_writer: factor image conversion into a separate function
Needed for a later commit.
2015-04-20 23:04:34 +02:00
wm4 07678423fb image_writer: minor cleanup
Instead of using int like bool, use bool directly.
2015-04-20 23:03:32 +02:00
Marcin Kurczewski f43017bfe9 Update license headers
Signed-off-by: wm4 <wm4@nowhere>
2015-04-13 12:10:01 +02:00
wm4 d737939f1f screenshots: drop some useless jpeg writer options 2015-04-09 21:05:26 +02:00
wm4 8d3c826ad8 screenshots: write jpg files with original subsampling
A screenshot from a 4:2:0 video will use 4:2:0, RGB will use 4:4:4, and
so on. (The image data still goes through RGB conversion always.)
2015-04-09 21:01:34 +02:00
wm4 7d116a979b screenshots: select best image format the encoder supports
This matters for png screenshots. We used to hardcode rgb24, but
libavformat's png encoder can do much more. Use the image format list
provided by the encoder, and select the best format from it (according
to the source format).

As a consequence, rgb48 (i.e. 16 bit per component) will be selected if
the source format is e.g. 10 bit yuv. This happens in accordance to
FFmpeg's avcodec_find_best_pix_fmt_of_list() function, which assumes
that 16 bit rgb should be preferred for 10 bit yuv.

This also causes it to print this message in this case:

[ffmpeg] swscaler: full chroma interpolation for destination format 'rgb48be' not yet implemented

I'm not 100% sure whether this is a problem.
2015-04-06 20:34:50 +02:00
wm4 c31e5da734 Remove some FFmpeg/Libav compatibility hacks
All of these are now in the supported FFmpeg and Libav versions.

The 3 remaining API checks are for FFmpeg-only things.
2015-03-03 12:28:46 +01:00
Niklas Haas a76cc1dafc
Revert "Revert recent vo_opengl related commits"
Omitted a simple, but devastasting check. Fixed the relevant commits
now.

This reverts commit 8d24e9d9b8.

diff --git a/video/out/gl_video.c b/video/out/gl_video.c
index 9c8a643..f1ea03e 100644
--- a/video/out/gl_video.c
+++ b/video/out/gl_video.c
@@ -1034,9 +1034,9 @@ static void compile_shaders(struct gl_video *p)
     shader_def_opt(&header_conv, "USE_CONV_GAMMA", use_conv_gamma);
     shader_def_opt(&header_conv, "USE_CONST_LUMA", use_const_luma);
     shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_BT1886",
-                   gamma_fun == MP_CSP_TRC_BT_1886);
+                   use_linear_light && gamma_fun == MP_CSP_TRC_BT_1886);
     shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_SRGB",
-                   gamma_fun == MP_CSP_TRC_SRGB);
+                   use_linear_light && gamma_fun == MP_CSP_TRC_SRGB);
     shader_def_opt(&header_conv, "USE_SIGMOID", use_sigmoid);
     if (p->opts.alpha_mode > 0 && p->has_alpha && p->plane_count > 3)
         shader_def(&header_conv, "USE_ALPHA_PLANE", "3");
2015-02-28 20:23:47 +01:00
wm4 8d24e9d9b8 Revert recent vo_opengl related commits
Breaks vo_opengl by default. I'm hot able to fix this myself, because I
have no clue about the overcomplicated color management logic. Also,
whilethis is apparently caused by commit fbacd5, the following commits
all depend on it, so revert them too.

This reverts the following commits:
 e141caa97d
 653b0dd529
 729c8b3f64
 fbacd5de31

Fixes #1636.
2015-02-28 19:29:03 +01:00
Niklas Haas 653b0dd529
screenshots: check for AVFrame csp support
Apparently, libav stable is old enough to not have these fields.
2015-02-28 01:39:31 +01:00
Niklas Haas 729c8b3f64
screenshots: add support for csp tagging
This relies on upstream support in lavc, and will hence basically not
work at all. The intent is to get support for writing this information
into ffmpeg's PNG encoders etc.
2015-02-28 01:08:32 +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 9270dda50a screenshots: set AVFrame parameters
Currently, libavcodec is rather lenient, but it might get stricter in
the future.

Fixes #1398.
2014-12-28 14:06:56 +01:00
wm4 a7686e86ff video: remove swapped-endian image format aliases
Like the previous commit, this removes names only, not actual support
for these formats.
2014-11-05 01:52:20 +01:00
wm4 68ff8a0484 Move compat/ and bstr/ directory contents somewhere else
bstr.c doesn't really deserve its own directory, and compat had just
a few files, most of which may as well be in osdep. There isn't really
any justification for these extra directories, so get rid of them.

The compat/libav.h was empty - just delete it. We changed our approach
to API compatibility, and will likely not need it anymore.
2014-08-29 12:31:52 +02:00
wm4 72aac9ae8a video: introduce failure path for image allocations
Until now, failure to allocate image data resulted in a crash (i.e.
abort() was called). This was intentional, because it's pretty silly to
degrade playback, and in almost all situations, the OOM will probably
kill you anyway. (And then there's the standard Linux overcommit
behavior, which also will kill you at some point.)

But I changed my opinion, so here we go. This change does not affect
_all_ memory allocations, just image data. Now in most failure cases,
the output will just be skipped. For video filters, this coincidentally
means that failure is treated as EOF (because the playback core assumes
EOF if nothing comes out of the video filter chain). In other
situations, output might be in some way degraded, like skipping frames,
not scaling OSD, and such.

Functions whose return values changed semantics:

  mp_image_alloc
  mp_image_new_copy
  mp_image_new_ref
  mp_image_make_writeable
  mp_image_setrefp
  mp_image_to_av_frame_and_unref
  mp_image_from_av_frame
  mp_image_new_external_ref
  mp_image_new_custom_ref
  mp_image_pool_make_writeable
  mp_image_pool_get
  mp_image_pool_new_copy
  mp_vdpau_mixed_frame_create
  vf_alloc_out_image
  vf_make_out_image_writeable
  glGetWindowScreenshot
2014-06-17 22:43:43 +02:00
wm4 a9538e17ad video: synchronize mpv rgb pixel format names with ffmpeg names
This affects packed RGB formats up to 16 bits per pixel. The old mplayer
names used LSB-to-MSB order, while FFmpeg (and some other libraries) use
MSB-to-LSB.

Nothing should change with this commit, i.e. no bit order or endian bugs
should be added or fixed. In some cases, the name stays the same, even
though the byte order changes, e.g. RGB8->BGR8 and BGR8->RGB8, and this
affects the user-visible names too; this might cause confusion.
2014-06-14 10:03:04 +02:00
wm4 99f5fef0ea Add more const
While I'm not very fond of "const", it's important for declarations
(it decides whether a symbol is emitted in a read-only or read/write
section). Fix all these cases, so we have writeable global data only
when we really need.
2014-06-11 00:39:14 +02:00
wm4 f6f8dc7782 video: remove redundant mp_image display_w/_h members
Commit 5e4e248 added a mp_image_params field to mp_image, and moved many
parameters to that struct. display_w/h was left redundant with
mp_image_params.d_w/d_h. These fields were supposed to be always in
sync, but it seems some code forgot to do this correctly, such as
vf_fix_img_params() or mp_image_copy_attributes(). This led to the
problem in github issue #756, because display_w/_h could become
incorrect.

It turns out that most code didn't use the old fields anyway. Just
remove them. Note that mp_image_params.d_w/d_h are supposed to be always
valid, so the additional checks for 0 shouldn't be needed. Remove these
checks as well.

Fixes #756.
2014-04-29 13:31:59 +02:00
wm4 62ab6a91bd image_writer: use new AVFrame API 2014-03-16 13:19:29 +01:00
wm4 64278128d8 video/fmt-conversion.c: remove unknown pixel format messages
This removes the messages printed on unknown pixel format messages.
Passing a mp_log to them would be too messy. Actually, this is a good
change, because in the past we often had trouble with these messages
printed too often (causing terminal spam etc.), and printing warnings or
error messages on the caller sides is much cleaner.

vd_lavc.c had a change earlier to print an error message if a decoder
outputs an unsupported pixel format.
2013-12-21 20:50:11 +01:00
wm4 5beedf1967 image_writer: mp_msg conversions
Adds an awkward mp_log argument for error messages.
2013-12-21 20:50:10 +01:00