aboutsummaryrefslogtreecommitdiffhomepage
path: root/video/mp_image.c
Commit message (Collapse)AuthorAge
* mp_image: allow passing NULL to mp_image_new_custom_ref()Gravatar wm42016-04-25
| | | | | | | A minor simplification. Most callers don't need this, and there's no good reason why the caller should provide an "initializer" like this. (This function calls mp_image_new_dummy_ref(), which has no reason for an initializer either.)
* mp_image: make mp_image_copy_fields_* privateGravatar wm42016-04-15
| | | | | Future code should always use mp_image_{to,from}_av_frame(). Everything else is way too messy and fragile.
* mp_image: add mp_image_to_av_frame()Gravatar wm42016-04-15
| | | | | What mp_image_to_av_frame_and_unref() should have been. (The _unref variant is still useful though.)
* mp_image: simplify mp_image_steal_data()Gravatar wm42016-04-15
| | | | Why was this so complex.
* mp_image: pass through AVHWFramesContextGravatar wm42016-04-15
| | | | In both directions.
* mp_image: introduce a hw_subfmt fieldGravatar wm42016-04-07
| | | | | | | | | | | For hwaccel formats, mp_image will merely point to a hardware surface handle. In these cases, the mp_image_params.imgfmt field describes the format insufficiently, because it mostly only describes the type of the hardware format, not its underlying format. Introduce hw_subfmt to describe the underlying format. It makes sense to use it with most hwaccels, though for now it will be used with the following commit only.
* mp_image: force display size to at least 1x1Gravatar wm42016-02-12
| | | | | | | | Don't allow rounding to let it underflow to 0. 0 width or height is simply not allowed and could cause problems otherwhere. Indirectly fixes CID 1350057, which complains about not checking the resulting output size values before using it in divisions.
* mp_image: copy dts as part of mp_image attributes tooGravatar wm42016-01-28
| | | | | Fixes DTS handling with certain container formats broken in commit b53cb8de (when using vaapi-copy or dxva2-copy).
* 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).
* video: replace vf_format outputlevels option with global optionGravatar wm42015-09-29
| | | | | | | | | | | 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.
* video: refactor GPU memcpy usageGravatar wm42015-09-25
| | | | | | | | | | | | | | | | | Make the GPU memcpy from the dxva2 code generally useful to other parts of the player. We need to check at configure time whether SSE intrinsics work at all. (At least in this form, they won't work on clang, for example. It also won't work on non-x86.) Introduce a mp_image_copy_gpu(), and make the dxva2 code use it. Do some awkward stuff to share the existing code used by mp_image_copy(). I'm hoping that FFmpeg will sooner or later provide a function like this, so we can remove most of this again. (There is a patch, bit it's stuck in limbo since forever.) All this is used by the following commit.
* mp_image: fix vf_vdpaupp referencesGravatar wm42015-07-08
| | | | | | | | | | Some code called by vf_vdpaupp.c calls mp_image_new_custom_ref(), but out of convenience doesn't reset the buffers. Make this behavior ok. (The assert() was there to catch usage errors, but the same error could already happen before the refcount changes were made, so the check is not overly helpful.) Fixes #2115.
* video: replace our own refcounting with libavutil'sGravatar wm42015-07-05
| | | | | | | | | | | | | | | | | | | | | | mpv had refcounted frames before libav*, so we were not using libavutil's facilities. Change this and drop our own code. Since AVFrames are not actually refcounted, and only the image data they reference, the semantics change a bit. This affects mainly mp_image_pool, which was operating on whole images instead of buffers. While we could work on AVBufferRefs instead (and use AVBufferPool), this doesn't work for use with hardware decoding, which doesn't map cleanly to FFmpeg's reference counting. But it worked out. One weird consequence is that we still need our custom image data allocation function (for normal image data), because AVFrame's uses multiple buffers. There also seems to be a timing-dependent problem with vaapi (the pool appears to be "leaking" surfaces). I don't know if this is a new problem, or whether the code changes just happened to cause it more often. Raising the number of reserved surfaces seemed to fix it, but since it appears to be timing dependent, and I couldn't find anything wrong with the code, I'm just going to assume it's not a new bug.
* mp_image: make image writeable before overwriting paletteGravatar wm42015-07-05
| | | | This is an obscure but theoretically possible bug.
* mp_image: remove some unused interlacing flagsGravatar wm42015-04-23
| | | | | | MP_IMGFIELD_TOP/MP_IMGFIELD_BOTTOM were completely unused, and MP_IMGFIELD_ORDERED was always set (even though vf_vdpaupp.c strangely checked for the latter).
* Update license headersGravatar Marcin Kurczewski2015-04-13
| | | | Signed-off-by: wm4 <wm4@nowhere>
* mp_image: remove redundant flags fieldGravatar wm42015-04-10
| | | | | | | Because gcc (and clang) is a goddamn PITA and unnecessarily warns if the universal initializer for structs is used (like mp_image x = {}) and the first member of the struct is also a struct, move the w/h fields to the top.
* mp_image: remove redundant chroma_x/y_shift fieldsGravatar wm42015-04-10
|
* mp_image: remove redundant plane_w/h fieldsGravatar wm42015-04-10
| | | | Seems relatively painful in this case, but they are morally wrong.
* mp_image: fix buildGravatar wm42015-04-09
|
* video: move colorspace overrides to vf_format, simplifyGravatar wm42015-03-31
| | | | | | | | | | | | | | | | | | | Remove the colorspace-related top-level options, add them to vf_format. They are rather obscure and not needed often, so it's better to get them out of the way. In particular, this gets rid of the semi-complicated logic in command.c (most of which was needed for OSD display and the direct feedback from the VO). It removes the duplicated color-related name mappings. This removes the ability to write the colormatrix and related properties. Since filters can be changed at runtime, there's no loss of functionality, except that you can't cycle automatically through the color constants anymore (but who needs to do this). This also changes the type of the mp_csp_names and related variables, so they can directly be used with OPT_CHOICE. This probably ended up a bit awkward, for the sake of not adding a new option type which would have used the previous format.
* mp_image: reject 0-sized imagesGravatar wm42015-03-23
| | | | | | Like FFmpeg/Libav do. It seems not all code can actually deal with this situation, so it's better to shift the special-cases to code which needs it (possibly OSD code; screenshots of 0x0 windows would just fail).
* mp_image: do not assume trailing stride padding existsGravatar wm42015-03-20
| | | | | | | | | | | | Normally, the size of an mage plane is assumed to be stride*height. But in theory, if stride is larger than width*bpp, the last line might not be padded, simply because it's not necessary. FFmpeg's or mpv's image allocators always guarantee that this padding exists (it wastes some insignificant memory for avoiding such subtle issues), but some other libraries might not. I suspect one such case might be Xv via vo_xv (see #1698), although my X server appears to provide full padding. In any case, it can't harm.
* video: uninline memcpy_pic functionsGravatar wm42015-03-20
| | | | | | | | | There's literally no reason why these functions have to be inline (they might be performance critical, but then the function call overhead isn't going to matter at all). Uninline them and move them to mp_image.c. Drop the header file and fix all uses of it.
* mp_image: remove unneeded thingsGravatar wm42015-03-20
| | | | (But I'd really prefer removing our own refcounting mechanism fully.)
* 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.
* video: fix typoGravatar wm42015-02-28
| | | | Pointed out in #1636.
* csputils: add missing gamma supportGravatar Niklas Haas2015-02-28
| | | | | | | | | | | We have MP_CSP_TRC defined, but it wasn't being used by practically anything. This commit adds missing conversion logic, adds it to mp_image, and moves the auto-guessing logic to where it should be, in mp_image_params_guess_csp (and out of vo_opengl). Note that this also fixes a minor bug: csp_prim was not being copied between mp_image structs if the format was not YUV in both cases, but this is wrong - the primaries are always relevant.
* vo_opengl: change the way unaligned chroma size is handledGravatar wm42015-01-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This deals with subsampled YUV video that has odd sizes, for example a 5x5 image with 4:2:0 subsampling. It would be easy to handle if we actually passed separate texture coordinates for each plane to the shader, but as of now the luma coordinates are implicitly rescaled to chroma one. If luma and chroma sizes don't match up, and this is not handled, you'd get a chroma shift by 1 pixel. The existing hack worked, but broke separable scaling. This was exposed by a recent commit which switched to GL_NEAREST sampling for FBOs. The rendering was accidentally scaled by 1 pixel, because the FBO size used the original video size, while textures_sizes[0] was set to the padded texture size (i.e. one pixel larger). It could be fixed by setting the padded texture size only on the first shader. But somehow that is annoying, so do something else. Don't pad textures anymore, and rescale the chroma coordinates in the shader instead. Seems like this somehow doesn't work with rectangle textures (and introduces a chroma shift), but since it's only used when doing VDA hardware decoding, and the bug occurs only with unaligned video sizes, I don't care much. Fixes #1523.
* vo: simplify VOs by adding generic screenshot supportGravatar wm42015-01-24
| | | | | | | | | | | At the time screenshot support was added, images weren't refcounted yet, so screenshots required specialized implementations in the VOs. But now we can handle these things much simpler. Also see commit 5bb24980. If there are VOs in the future which can't do this (e.g. they need to write to the image passed to vo_driver->draw_image), this still could be disabled on a per-VO basis etc., so we lose no potential performance advantages.
* video: handle hwdec screenshots differentlyGravatar wm42015-01-22
| | | | | | | | Instead of converting the hw surface to an image in the VO, provide a generic way to convet hw surfaces, and use this in the screenshot code. It's all relatively straightforward, except vdpau is being terrible. It needs a huge chunk of new code, because copying back is not simple.
* mp_image: reject invalid display aspect ratioGravatar wm42015-01-13
| | | | | | | | | | Having any of these set to 0 makes no sense. I think some code might still be using 0/0 aspect ratio to signal unset aspect ratio, but I didn't find it. If there is still code like this, it should be fixed instead. Fixes #1467.
* mp_image: copy missing attributesGravatar James Ross-Gowan2015-01-07
| | | | | This adds a couple of missing fields to mp_image_copy_attributes so things like rotation metadata work.
* mp_image: check for malloc failureGravatar wm42014-12-13
| | | | | Or rather, the only reason av_buffer_create() can fail is a malloc failure.
* video: remove things forgotten in previous commitGravatar wm42014-12-03
| | | | Oops.
* mp_image: slightly better image params verbose infoGravatar wm42014-11-12
|
* video: move formatting of image parameters to separate functionGravatar wm42014-11-12
|
* mp_image: check memory allocationGravatar wm42014-11-08
|
* video: refuse to allocate image data for hwaccel formatsGravatar wm42014-11-05
| | | | Makes no sense.
* video: fix some vo_direct3d crashes due to FFmpeg nonsenseGravatar wm42014-09-21
| | | | | | | | | | | | For incomprehensible reasons, AV_PIX_FMT_GRAY8 (and some others) have a palette. This literally makes no sense and this issue has bitten us before, but it is how it is. This also caused a crash with vo_direct3d: this mapped a texture as IMGFMT_Y8 (i.e. AV_PIX_FMT_GRAY8), and when copying this, it tried to copy the non-existent palette. Fixes #1113.
* video: initial Matroska 3D supportGravatar wm42014-08-30
| | | | | | | | | | | | | | | | | | | | | This inserts an automatic conversion filter if a Matroska file is marked as 3D (StereoMode element). The basic idea is similar to video rotation and colorspace handling: the 3D mode is added as a property to the video params. Depending on this property, a video filter can be inserted. As of this commit, extending mp_image_params is actually completely unnecessary - but the idea is that it will make it easier to integrate with VOs supporting stereo 3D mogrification. Although vo_opengl does support some stereo rendering, it didn't support the mode my sample file used, so I'll leave that part for later. Not that most mappings from Matroska mode to vf_stereo3d mode are probably wrong, and some are missing. Assuming that Matroska modes, and vf_stereo3d in modes, and out modes are all the same might be an oversimplification - we'll see. See issue #1045.
* video: Include better heuristics for guessing primariesGravatar Niklas Haas2014-06-22
| | | | | | | These consult the vertical resolution, matching against 576 for PAL and 480/486 for NTSC. The documentation has also been updated. Signed-off-by: wm4 <wm4@nowhere>
* video: Better support for XYZ inputGravatar Niklas Haas2014-06-22
| | | | | | | | | With this change, XYZ input is directly converted to the output colorspace wherever possible, and to the colorspace specified by the tags and/or --primaries option, otherwise. This commit also restructures some of the CMS code in gl_video.c to hopefully make it clearer which decision is being done where and why.
* video: Support BT.2020 constant luminance systemGravatar Niklas Haas2014-06-22
| | | | Signed-off-by: wm4 <wm4@nowhere>
* video: Add support for non-BT.709 primariesGravatar Niklas Haas2014-06-22
| | | | | | | This add support for reading primary information from lavc, categorized into BT.601-525, BT.601-625, BT.709 and BT.2020; and passes it on to the vo. In vo_opengl, we always generate the 3dlut against the wider BT.2020 and transform our source into this colorspace in the shader.
* video: Add BT.2020-NCL colorspace and transfer functionGravatar Niklas Haas2014-06-22
| | | | Source: http://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.2020-0-201208-I!!PDF-E.pdf
* video: correct spelling: mp_image_params_equals -> mp_image_params_equalGravatar wm42014-06-17
| | | | | 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.
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-17 01:15:11 +0000