summaryrefslogtreecommitdiffstats
path: root/video/image_writer.c
Commit message (Collapse)AuthorAgeFilesLines
* video/image_writer: check for write errorsNRK2023-07-111-3/+2
| | | | | | make sure that fwrite is error checked. and if any data was still remaining on the buffer, it will be flushed - and errors checked - via the fclose() call below.
* video/image_writer: fix file leak in error pathNRK2023-07-111-0/+1
| | | | regression from de7f4fb1e
* video/image_writer: add avif screenshot supportcloud116652023-07-011-17/+293
| | | | | | | | | | Notes: - converts the (image) write() api to filenames, because using avio with FILE* is a pain. - adds more debug logs for screenshots. build: rename av1 dependency to avif_muxer wscript: unify lavf dependency with meson
* image_writer: respect jpeg-quality when using ffmpeg for writingsfan52023-06-291-1/+9
|
* options: transition options from OPT_FLAG to OPT_BOOLChristoph Heinrich2023-02-211-8/+7
| | | | | | c78482045444c488bb7948305d583a55d17cd236 introduced a bool option type as a replacement for the flag type, but didn't actually transition and remove the flag type because it would have been too much mundane work.
* video/image_writer: use effort=4 default for JXL screenshotsLeo Izen2023-02-171-1/+1
| | | | | | effort=4 has a significant increase in quality/bpp compared to effort=3 with a very minor increase in encoding time. It's worth the trade-off as a default setting for lossy encoding.
* video/image_writer: force sRGB for unsupported formatsNiklas Haas2023-02-131-8/+13
| | | | | | | | | After commit c98e7353, we blindly pass the screenshot colorspace to the image writer. But since we want to introduces the ability to save images in HDR and other exotic formats, we should strip this for unsupported formats. See-Also: #10988
* video/image_writer: add image_writer_flexible_cspNiklas Haas2023-02-131-0/+13
| | | | | | PNG only supports this since the introduction of cICP, so put a version check on the next API version bump after the cICP writing patch got merged.
* video/image_writer: change screenshot-tag-colorspace default to yesLeo Izen2023-02-091-1/+1
| | | | | | With significant improvements to the color tagging support in various screenshot formats, e.g. cICP in FFmpeg, and JPEG XL's generally robust color support, it's safe to default this to yes.
* video/image_writer: avoid stripping colorspace info when writing imageLeo Izen2023-01-311-0/+1
| | | | | | | | | | | | | Writing an image either with vo_image or with a screenshot will strip the colorspace info because it allocates a new mp_image that contains the same data as the old image after calling mp_image_params_guess_csp. However, mp_image_params_guess_csp cannot always guess the appropriate colorspace, so it picks a "sane default." Since this function also changes parameters so the space always makes sense, this extra info isn't harmful and allows screenshots and vo_image outs to be properly tagged with the correct colorspace. Fixes #10988.
* video/image_writer: tag colorspace in AVCodecContextLeo Izen2022-05-041-2/+4
| | | | | If screenshot-tag-colorspace=yes, then set the corresponding fields in AVCodecContext, not just in AVFrame.
* video/image_writer: fix high-depth JPEG XL screenshotsLeo Izen2022-04-291-1/+5
| | | | | | | Allow screenshot-high-bit-depth=yes to work with JPEG XL screenshots when screenshot-sw=no is set. They already work as expected when screenshot-sw=yes is set, but this allows the hardware screenshots to work this way too.
* build: add avcodec jpegxl dependency versionsLeo Izen2022-04-281-5/+3
| | | | | Add the libavcodec version check for AV_CODEC_ID_JPEGXL to the build system rather than to any file that references it.
* video/image_writer: add Jpeg XL screenshotsLeo Izen2022-04-261-0/+18
| | | | | | | Add Jpeg XL as a possible output format for screenshots, which should make it possible to take fast screenshots with much better quality than JPEG, or take lossless high-bit-depth screenshots with lower file sizes than PNG.
* image_writer: replace deprecated av_init_packet()sfan52022-01-101-10/+9
|
* build: address AVCodec, AVInputFormat, AVOutputFormat const warningssfan52021-05-011-3/+3
| | | | FFmpeg recently changed these to be const on their side.
* video: clean up some imgfmt related stuffwm42020-05-181-3/+11
| | | | | | | | | | | | | | | | 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 00653a3eb052). With this I've decided to keep mp_imgfmt_desc, just removing the weird parts, and keeping the saner parts.
* options: change option macros and all option declarationswm42020-03-181-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* screenshot, vo_image: use global swscale/zimg parameterswm42019-10-311-4/+13
| | | | | | | | | | 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.
* image_writer: add webp-compression optionsfan52019-09-141-0/+3
|
* image_writer: add WebP support (lossy or lossless)sfan52019-09-141-7/+39
|
* image_writer: move convert_image() to player/screenshot.csfan52019-09-141-3/+3
|
* vo_gpu: make screenshots use the GL rendererwm42018-02-111-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Replace remaining avcodec_close() callswm42017-07-161-3/+1
| | | | | | | | 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.
* image_writer, vo_image: change license to LGPLwm42017-06-181-10/+7
| | | | | | | | | | | | | | | | | | 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 (57f77bb41a9) 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).
* image_writer: make it work with libavcodec's jpg encoderwm42017-04-021-5/+38
| | | | | | | | | | | 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.
* screenshot: change details of --screenshot-format handlingwm42017-03-181-45/+41
| | | | | | | | | | | | | | | | 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.)
* image_writer: remove useless formatswm42017-03-181-4/+0
| | | | Nobody cares about those.
* image_writer: check a return valuewm42017-02-201-1/+3
| | | | | Doesn't matter, since it's the flush call, but be nice. In particular, don't upset coverity.
* Remove compatibility thingswm42016-12-071-6/+0
| | | | | | Possible with bumped FFmpeg/Libav. These are just the simple cases.
* vo_image: move to global optionswm42016-09-051-14/+10
| | | | | This is a bit "special", because the config tree wants unique m_sub_options pointers in the whole thing.
* mp_image: split colorimetry metadata into its own structNiklas Haas2016-07-031-2/+2
| | | | | | | | | | | | | | | | | | 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.
* image_writer: port to new encode APIwm42016-06-241-0/+12
|
* image_writer: take care of prediction_method deprecationwm42016-02-091-1/+3
| | | | | | | The field was recently deprecated, and you're supposed to set the private codec option instead. Not sure if this really works as intended.
* image_writer: fix writing flipped images as jpgwm42016-01-171-1/+1
| | | | | | next_scanline is usually an unsigned int. Fixes #2635 (again).
* mpv_talloc.h: rename from talloc.hDmitrij D. Czarkoff2016-01-111-1/+1
| | | | This change helps avoiding conflict with talloc.h from libtalloc.
* video: switch from using display aspect to sample aspectwm42015-12-191-2/+2
| | | | | | | | | | | | | | | | 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).
* Replace deprecated av_free_packet() callswm42015-10-281-1/+1
| | | | | | 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.
* image_writer: don't use jpeg baseline, and remove useless jpeg optionswm42015-08-021-6/+1
| | | | | | | | | 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.
* screenshot: don't write PNG colorspace tags by defaultwm42015-07-181-1/+1
| | | | | | Generates too much discussion and confusion. Fixes #2051.
* screenshots: add option to prevent 16 bit outputwm42015-04-291-13/+23
| | | | That's what it's usually about (again).
* screenshots: add option to disable JPEG 4:4:4 outputwm42015-04-291-2/+6
| | | | That's what it's usually about.
* image_writer: fix writing screenshotswm42015-04-221-1/+1
| | | | | It passed the unconverted image to the writer function. Broken since 2469cb5d.
* image_writer: factor image conversion into a separate functionwm42015-04-201-25/+31
| | | | Needed for a later commit.
* image_writer: minor cleanupwm42015-04-201-9/+9
| | | | Instead of using int like bool, use bool directly.
* Update license headersMarcin Kurczewski2015-04-131-4/+4
| | | | Signed-off-by: wm4 <wm4@nowhere>
* screenshots: drop some useless jpeg writer optionswm42015-04-091-11/+0
|
* screenshots: write jpg files with original subsamplingwm42015-04-091-1/+5
| | | | | 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.)
* screenshots: select best image format the encoder supportswm42015-04-061-24/+34
| | | | | | | | | | | | | | | | | | 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.
* Remove some FFmpeg/Libav compatibility hackswm42015-03-031-2/+0
| | | | | | All of these are now in the supported FFmpeg and Libav versions. The 3 remaining API checks are for FFmpeg-only things.
* Revert "Revert recent vo_opengl related commits"Niklas Haas2015-02-281-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | Omitted a simple, but devastasting check. Fixed the relevant commits now. This reverts commit 8d24e9d9b8ad1b5d82139980eca148dc0f4a1eab. 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");
* Revert recent vo_opengl related commitswm42015-02-281-8/+0
| | | | | | | | | | | | | | | 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: e141caa97dade07f4d7e0d6c208bcd3493e712ed 653b0dd5295453d9661f673b4ebd02c5ceacf645 729c8b3f641e633474be612e66388c131a1b5c92 fbacd5de31de964f7cd562304ab1c9b4a0d76015 Fixes #1636.
* screenshots: check for AVFrame csp supportNiklas Haas2015-02-281-0/+2
| | | | Apparently, libav stable is old enough to not have these fields.
* screenshots: add support for csp taggingNiklas Haas2015-02-281-0/+6
| | | | | | 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.
* image_writer: check for conversion errorswm42015-01-151-1/+5
| | | | | This can happen when e.g. a VO returns a screenshot in an unsupported format.
* screenshots: set AVFrame parameterswm42014-12-281-0/+3
| | | | | | | Currently, libavcodec is rather lenient, but it might get stricter in the future. Fixes #1398.
* video: remove swapped-endian image format aliaseswm42014-11-051-1/+1
| | | | | Like the previous commit, this removes names only, not actual support for these formats.
* Move compat/ and bstr/ directory contents somewhere elsewm42014-08-291-2/+0
| | | | | | | | | 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.
* video: introduce failure path for image allocationswm42014-06-171-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 t