summaryrefslogtreecommitdiffstats
path: root/video/mp_image.c
Commit message (Collapse)AuthorAgeFilesLines
* mp_image: reject 0-sized imageswm42015-03-231-2/+1
| | | | | | 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 existswm42015-03-201-4/+4
| | | | | | | | | | | | 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 functionswm42015-03-201-1/+47
| | | | | | | | | 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 thingswm42015-03-201-33/+16
| | | | (But I'd really prefer removing our own refcounting mechanism fully.)
* Remove some FFmpeg/Libav compatibility hackswm42015-03-031-5/+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-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | 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-10/+1
| | | | | | | | | | | | | | | 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 typowm42015-02-281-1/+1
| | | | Pointed out in #1636.
* csputils: add missing gamma supportNiklas Haas2015-02-281-1/+10
| | | | | | | | | | | 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 handledwm42015-01-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 supportwm42015-01-241-0/+3
| | | | | | | | | | | 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 differentlywm42015-01-221-0/+1
| | | | | | | | 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 ratiowm42015-01-131-1/+1
| | | | | | | | | | 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 attributesJames Ross-Gowan2015-01-071-0/+2
| | | | | This adds a couple of missing fields to mp_image_copy_attributes so things like rotation metadata work.
* mp_image: check for malloc failurewm42014-12-131-0/+2
| | | | | Or rather, the only reason av_buffer_create() can fail is a malloc failure.
* video: remove things forgotten in previous commitwm42014-12-031-10/+0
| | | | Oops.
* mp_image: slightly better image params verbose infowm42014-11-121-1/+6
|
* video: move formatting of image parameters to separate functionwm42014-11-121-0/+21
|
* mp_image: check memory allocationwm42014-11-081-0/+4
|
* video: refuse to allocate image data for hwaccel formatswm42014-11-051-1/+1
| | | | Makes no sense.
* video: fix some vo_direct3d crashes due to FFmpeg nonsensewm42014-09-211-1/+2
| | | | | | | | | | | | 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 supportwm42014-08-301-1/+5
| | | | | | | | | | | | | | | | | | | | | 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 primariesNiklas Haas2014-06-221-4/+5
| | | | | | | 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 inputNiklas Haas2014-06-221-1/+4
| | | | | | | | | 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 systemNiklas Haas2014-06-221-1/+3
| | | | Signed-off-by: wm4 <wm4@nowhere>
* video: Add support for non-BT.709 primariesNiklas Haas2014-06-221-0/+29
| | | | | | | 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 functionNiklas Haas2014-06-221-0/+1
| | | | 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_equalwm42014-06-171-2/+2
| | | | | 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.
* video: remove redundant functionwm42014-06-171-6/+0
| | | | mp_image_params_from_image() is now trivial and can be removed.
* video: check image parameterswm42014-06-171-4/+31
| | | | | | | | | Make sure every video filter has valid parameters for input and output. (This also ensures we don't take possibly invalid decoder output, or feed invalid decodr/filter output to VOs.) Also, the updated image size check now (almost) works like the corresponding check in FFmpeg.
* video: introduce failure path for image allocationswm42014-06-171-9/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: fix screenshots with anamorphic videowm42014-05-021-2/+2
| | | | | | | (Again.) This was caused by mp_image_set_params() not properly copying d_w/d_h, because mp_image_set_size() resets them.
* video: remove redundant mp_image display_w/_h memberswm42014-04-291-14/+4
| | | | | | | | | | | | | | | | | 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.
* mp_image: add rotation parameterwm42014-04-211-1/+2
|
* video: make mp_image use mp_image_params directlywm42014-04-211-41/+22
| | | | | Minor cleanup, so that we can stuff more information into mp_image_params later.
* video: remove use of deprecated AVFrame fields on Libavwm42014-04-151-4/+0
| | | | | | qscale export has been completely removed from Libav 10, and FFmpeg has an alternative API, so this code does nothing and only causes deprecation warnings on Libav.
* mp_image: add missing field to mp_image_params_equals()wm42014-03-281-0/+1
| | | | | | This is pretty obscure, so it didn't matter much. It still breaks switching output levels at runtime, because the video output is not reinitialized with the new params.
* video: change image format from unsigned int to int in some placeswm42014-03-171-2/+2
| | | | | | Image formats used to be FourCCs, so unsigned int was better. But now it's annoying and the only difference is that unsigned int is more to type than int.
* vd_lavc: remove compatibility crapwm42014-03-161-4/+0
| | | | | | | All this code was needed for compatibility with very old libavcodec versions only (such as Libav 9). Includes some now-possible simplifications too.
* mp_image: reject too large image sizeswm42014-01-291-0/+4
| | | | | | | | | | | Larger sizes can introduce overflows, depending on the image format. In the worst case, something larger than 16000x16000 with 8 bytes per pixel will overflow 31 bits. Maybe there should be a proper failure path instead of a hard crash, but not yet. I imagine anything that sets a higher image size than a known working size should be forced to call a function to check the size (much like in ffmpeg/libavutil).
* mp_image: deal with FFmpeg PSEUDOPAL braindeathwm42013-12-011-3/+3
| | | | | | | | | | We got a crash in libavutil when encoding with Y8 (GRAY8). The reason was that libavutil was copying an Y8 image allocated by us, and expected a palette. This is because GRAY8 is a PSEUDOPAL format. It's not clear what PSEUDOPAL means, and it makes literally no sense at all. However, it does expect a palette allocated for some formats that are not paletted, and libavutil crashed when trying to access the non-existent palette.
* build: make pthreads mandatorywm42013-11-281-6/+1
| | | | | | | | | | | pthreads should be available anywhere. Even if not, for environment without threads a pthread wrapper could be provided that can't actually start threads, thus disabling features that require threads. Make pthreads mandatory in order to simplify build dependencies and to reduce ifdeffery. (Admittedly, there wasn't much complexity, but maybe we will use pthreads more in the future, and then it'd become a real bother.)
* mp_image: add helper for copying image attributeswm42013-11-031-0/+22
| | | | | This enw function is similar to mp_image_set_params(), but doesn't force setting "hard" parameters like image size and format.
* talloc: change talloc destructor signaturewm42013-10-131-4/+2
| | | | | | | | | | | | | 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.)
* gl_video: handle non-mod-2 4:2:0 YUV video correctlywm42013-08-061-0/+4
| | | | | | | | | | | | | | | | Allocate textures big enough to include the bottom/right borders (so the chroma texture sizes are rounded up instead of down). Make the texture large enough to include the additional luma border. Conceptually, we pretend that the video frame is fully aligned, and then crop away the unwanted borders. Filtering (even just bilinear) will access the borders anyway, so it's possible that we might need to switch to "harder" cropping instead, but at least pixels not close to the border should be displayed correctly now. Add a comment to mp_image.c about this luma border. These semantics are kind of subtle, and the image allocation code handle this in a subtle way too, so it's better to document this explicitly. The libavutil image allocation code does similar things.
* mp_image: make reference counting thread-safewm42013-07-281-3/+27
| | | | | | | | | | This hasn't been done yet, because pthreads is still an optional dependency, so this is a bit annoying. Now doing it anyway, because maybe we will need this capability in the future. We keep it as simple as possible. We (probably) don't need anything more sophisticated, and keeping it simple avoids introducing weird bugs. So, no atomic instructions, no fine grained locks, no cleverness.
* mp_image: pass through colorspace info to libavfilterwm42013-07-281-0/+8
| | | | | | | | | | | | | This change affects vf_lavfi. Until recently, libavfilter was not colorspace aware at all. This changed with the addition of colorspace fields to AVFrame. libavfilter's vf_scale picks them up (as of recent ffmpeg git). Since this support is still kind of wonky and not part of the normal format negotiation, this won't set the correct output colorspace, though. Not adding a separate test for HAVE_AVFRAME_COLORSPACE. This is slightly unclean, but on the other hand adding an explicit test seems like a waste of effort.
* video: support setting libswscale chroma positionwm42013-07-251-1/+3
|
* mp_image: create AVBuffers for all planes when converting to AVFramewm42013-07-241-1/+9
| | | | | | | | | | | | | | | | It appears the API requires you to cover all plane data with AVBuffers (that is, one AVBuffer per plane in the most general case), because certain code can make certain assumptions about this. (Insert rant about how this is barely useful and increases complexity and potential bugs.) I don't know any cases where the current code actually fails, but we want to follow the API, so do it anyway. Note that we don't really know whether or not planes are from a single memory allocation, so we have to assume the most general case and create an AVBuffer for each plane. We simply assume that the data is padded to the full stride in the last image line. All these extra dummy references are stupid, but the code might become much simpler once we only support libavcodec versions with refcounting and can use AVFrame directly.
* img_format: add a mask for color classwm42013-07-181-2/+1
| | | | | | | Using the term "color class" to avoid confusion with the other colorspace related concepts. Also get rid of MP_IMGFLAG_FMT_MASK, since it was unused.
* mp_image: one utility function to set image parameterswm42013-07-181-0/+11
|
* sws_utils: refactor swscale wrapper codewm42013-07-181-13/+9
| | | | | | | | | | This splits the monolithic mp_image_swscale() function into a bunch of functions and a context struct. This means it's possible to set arbitrary parameters (e.g. even obscure ones without getting in the way), and you don't have to create the context on every call. This code is preparation for removing duplicated libswscale API usage from other parts of the code.
* video: redo how colorspaces are handledwm42013-07-161-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of handling colorspaces with VFCTRLs/VOCTRLs, make them part of the normal video format negotiation. The colorspace is passed down like other video params with config/reconfig calls. Forcing colorspaces (via the --colormatrix options and properties) is handled differently too: if it's changed, completely reinit the video chain. This is slower and requires a precise seek to the same position to perform an update, but it's simpler and less bug-prone. Considering switching the colorspace at runtime by user-interaction is a rather obscure feature, this is a good change. The colorspace VFCTRLs and VOCTRLs are still kept. The VOs rely on it, and would have to be changed to get rid of them. We'll do that later, and convert them incrementally instead of in one go. Note that controlling the output range now always works on VO level. Basically, this means you can't get vf_scale to output full-range YUV for whatever reason. If that is really wanted, it should be a vf_scale option. the previous behavior didn't make too much sense anyway. This commit fixes a few bugs (such as playing RGB video and converting that to YUV with vf_scale - a recent commit broke this and forced the VO to display YUV as RGB if possible), and might introduce some new ones.
* mp_image: explicitly forbid using RGB colorspace with YUV formatswm42013-07-151-0/+9
| | | | This probably has more potential for breakage than it would be of use.
* mp_image: refactor colorspace guessing/fallbackwm42013-07-151-9/+44
| | | | This actually handles XYZ too.
*