aboutsummaryrefslogtreecommitdiffhomepage
path: root/video/image_writer.c
Commit message (Collapse)AuthorAge
* image_writer: make it work with libavcodec's jpg encoderGravatar wm42017-04-02
| | | | | | | | | | | 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 handlingGravatar wm42017-03-18
| | | | | | | | | | | | | | | | 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 formatsGravatar wm42017-03-18
| | | | Nobody cares about those.
* image_writer: check a return valueGravatar wm42017-02-20
| | | | | Doesn't matter, since it's the flush call, but be nice. In particular, don't upset coverity.
* Remove compatibility thingsGravatar wm42016-12-07
| | | | | | Possible with bumped FFmpeg/Libav. These are just the simple cases.
* vo_image: move to global optionsGravatar wm42016-09-05
| | | | | 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 structGravatar Niklas Haas2016-07-03
| | | | | | | | | | | | | | | | | | 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 APIGravatar wm42016-06-24
|
* image_writer: take care of prediction_method deprecationGravatar wm42016-02-09
| | | | | | | 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 jpgGravatar wm42016-01-17
| | | | | | next_scanline is usually an unsigned int. Fixes #2635 (again).
* mpv_talloc.h: rename from talloc.hGravatar Dmitrij D. Czarkoff2016-01-11
| | | | This change helps avoiding conflict with talloc.h from libtalloc.
* video: switch from using display aspect to sample aspectGravatar wm42015-12-19
| | | | | | | | | | | | | | | | 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() callsGravatar wm42015-10-28
| | | | | | 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 optionsGravatar wm42015-08-02
| | | | | | | | | 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 defaultGravatar wm42015-07-18
| | | | | | Generates too much discussion and confusion. Fixes #2051.
* screenshots: add option to prevent 16 bit outputGravatar wm42015-04-29
| | | | That's what it's usually about (again).
* screenshots: add option to disable JPEG 4:4:4 outputGravatar wm42015-04-29
| | | | That's what it's usually about.
* image_writer: fix writing screenshotsGravatar wm42015-04-22
| | | | | It passed the unconverted image to the writer function. Broken since 2469cb5d.
* image_writer: factor image conversion into a separate functionGravatar wm42015-04-20
| | | | Needed for a later commit.
* image_writer: minor cleanupGravatar wm42015-04-20
| | | | Instead of using int like bool, use bool directly.
* Update license headersGravatar Marcin Kurczewski2015-04-13
| | | | Signed-off-by: wm4 <wm4@nowhere>
* screenshots: drop some useless jpeg writer optionsGravatar wm42015-04-09
|
* screenshots: write jpg files with original subsamplingGravatar wm42015-04-09
| | | | | 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 supportsGravatar wm42015-04-06
| | | | | | | | | | | | | | | | | | 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 hacksGravatar wm42015-03-03
| | | | | | 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"Gravatar Niklas Haas2015-02-28
| | | | | | | | | | | | | | | | | | | | | | | | 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 commitsGravatar wm42015-02-28
| | | | | | | | | | | | | | | 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 supportGravatar Niklas Haas2015-02-28
| | | | Apparently, libav stable is old enough to not have these fields.
* screenshots: add support for csp taggingGravatar Niklas Haas2015-02-28
| | | | | | 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 errorsGravatar wm42015-01-15
| | | | | This can happen when e.g. a VO returns a screenshot in an unsupported format.
* screenshots: set AVFrame parametersGravatar wm42014-12-28
| | | | | | | Currently, libavcodec is rather lenient, but it might get stricter in the future. Fixes #1398.
* video: remove swapped-endian image format aliasesGravatar wm42014-11-05
| | | | | Like the previous commit, this removes names only, not actual support for these formats.
* Move compat/ and bstr/ directory contents somewhere elseGravatar wm42014-08-29
| | | | | | | | | 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 allocationsGravatar wm42014-06-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* video: synchronize mpv rgb pixel format names with ffmpeg namesGravatar wm42014-06-14
| | | | | | | | | | | 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.
* Add more constGravatar wm42014-06-11
| | | | | | | 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.
* video: remove redundant mp_image display_w/_h membersGravatar wm42014-04-29
| | | | | | | | | | | | | | | | | 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.
* image_writer: use new AVFrame APIGravatar wm42014-03-16
|
* video/fmt-conversion.c: remove unknown pixel format messagesGravatar wm42013-12-21
| | | | | | | | | | | 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.
* image_writer: mp_msg conversionsGravatar wm42013-12-21
| | | | Adds an awkward mp_log argument for error messages.
* Move options/config related files from mpvcore/ to options/Gravatar wm42013-12-17
| | | | | | | | | Since m_option.h and options.h are extremely often included, a lot of files have to be changed. Moving path.c/h to options/ is a bit questionable, but since this is mainly about access to config files (which are also handled in options/), it's probably ok.
* configure: uniform the defines to #define HAVE_xxx (0|1)Gravatar Stefano Pigozzi2013-11-03
| | | | | | | | | | | | | | | | | | | | | The configure followed 5 different convetions of defines because the next guy always wanted to introduce a new better way to uniform it[1]. For an hypothetic feature 'hurr' you could have had: * #define HAVE_HURR 1 / #undef HAVE_DURR * #define HAVE_HURR / #undef HAVE_DURR * #define CONFIG_HURR 1 / #undef CONFIG_DURR * #define HAVE_HURR 1 / #define HAVE_DURR 0 * #define CONFIG_HURR 1 / #define CONFIG_DURR 0 All is now uniform and uses: * #define HAVE_HURR 1 * #define HAVE_DURR 0 We like definining to 0 as opposed to `undef` bcause it can help spot typos and is very helpful when doing big reorganizations in the code. [1]: http://xkcd.com/927/ related
* core: move contents to mpvcore (2/2)Gravatar Stefano Pigozzi2013-08-06
| | | | Followup commit. Fixes all the files references.
* sws_utils: make hq swscale flags available with mp_sws_hq_flagsGravatar wm42013-07-18
| | | | No need to duplicate this on the call-site.
* image_writer: Add PNG filter option (default "mixed")Gravatar Martin Herkt2013-06-15
| | | | | | The use of filters prior to PNG compression can greatly improve compression ratio, with "mixed" (ImageMagick calls it "adaptive") typically achieving the best results.
* Prefix CODEC_ID_ with AV_Gravatar wm42013-03-13
| | | | | | | | | The old names have been deprecated a while ago, but were needed for supporting older ffmpeg/libav versions. The deprecated identifiers have been removed from recent Libav and FFmpeg git. This change breaks compatibility with Libav 0.8.x and equivalent FFmpeg releases.
* image_writer: switch to avcodec_encode_video2()Gravatar wm42013-03-13
| | | | | | | | avcodec_encode_video() was deprecated, and was finally removed from Libav and FFmpeg git. This change breaks compatibility with Libav 0.8.x. Thank the Libav developers, not me.
* m_option: don't define OPT_BASE_STRUCT by defaultGravatar wm42013-03-01
| | | | | | | | | | | OPT_BASE_STRUCT defines which struct the OPT_ macros (like OPT_INT etc.) reference implicitly, since these macros take struct member names but no struct type. Normally, only cfg-mplayer.h should need this, and other places shouldn't be bothered with having to #undef it. (Some files, like demux_lavf.c, still store their options in MPOpts. In the long term, this should be removed, and handled like e.g. with VO suboptions instead.)
* cleanup: replace OPT_FLAG_ON and OPT_MAKE_FLAGS with OPT_FLAGGravatar wm42013-02-09
| | | | | | | | | | OPT_MAKE_FLAGS() used to emit two options (one with "no" prefixed), but that has been long removed by special casing flag options in the option parser. OPT_FLAG_ON() used to imply that there's no "no-" prefixed option, but this hasn't been the case for a while either. (Conceptually, it has been replaced by OPT_FLAG_STORE().) Remove OPT_FLAG_OFF, which was unused.
* video: decouple internal pixel formats from FourCCsGravatar wm42013-01-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | mplayer's video chain traditionally used FourCCs for pixel formats. For example, it used IMGFMT_YV12 for 4:2:0 YUV, which was defined to the string 'YV12' interpreted as unsigned int. Additionally, it used to encode information into the numeric values of some formats. The RGB formats had their bit depth and endian encoded into the least significant byte. Extended planar formats (420P10 etc.) had chroma shift, endian, and component bit depth encoded. (This has been removed in recent commits.) Replace the FourCC mess with a simple enum. Remove all the redundant formats like YV12/I420/IYUV. Replace some image format names by something more intuitive, most importantly IMGFMT_YV12 -> IMGFMT_420P. Add img_fourcc.h, which contains the old IDs for code that actually uses FourCCs. Change the way demuxers, that output raw video, identify the video format: they set either MP_FOURCC_RAWVIDEO or MP_FOURCC_IMGFMT to request the rawvideo decoder, and sh_video->imgfmt specifies the pixel format. Like the previous hack, this is supposed to avoid the need for a complete codecs.cfg entry per format, or other lookup tables. (Note that the RGB raw video FourCCs mostly rely on ffmpeg's mappings for NUT raw video, but this is still considered better than adding a raw video decoder - even if trivial, it would be full of annoying lookup tables.) The TV code has not been tested. Some corrective changes regarding endian and other image format flags creep in.
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-01 20:52:57 +0000