aboutsummaryrefslogtreecommitdiffhomepage
path: root/video/out/opengl/video.c
Commit message (Collapse)AuthorAge
* vo_opengl: remove mp_imgfmt_desc and IMGFLAG_ usageGravatar wm42017-06-30
| | | | | These were weird due to their past, and often undefined or ill-defined. Time to get rid of them.
* vo_opengl: restructure format setupGravatar wm42017-06-30
| | | | | | | | | | | | Instead of setting up a weird swizzle (which is linked to how the internal renderer code works, rather than the generic format code), add per-component mapping to gl_imgfmt_desc. The renderer still computes the weird swizzle, but at least it's confined to itself. Also, it appears the hwdec backends don't need this anymore. It's really nice that the messy init_format() goes away too.
* options: change path list options, and document list optionsGravatar wm42017-06-30
| | | | | | | | | | | | | | | | | | | | | | | The changes to path list options is basically getting rid of the need to pass multiple paths to a single option. Instead, you can use the option multiple times. The old behavior can be used by using the -set suffix with the option. Change some options to path lists. For example --script is now append by default, and if you use --script-set, you need to use ":"/";" as separator instead of ",". --sub-paths/--audio-file-paths is a deprecated alias now, and will break if the user tries to pass multiple paths to it. I'm assuming that if these are used, most users will pass only 1 path anyway. --opengl-shaders has more compatibility handling, since it's probably rather common that users pass multiple options to it. Also document all that in the manpage. I'll probably regret this later, as it somewhat increases the complexity of the option parser, rather than increasing it.
* vo_opengl: unify user_shaders constantsGravatar Niklas Haas2017-06-28
| | | | | | | | | | | | | | | Commit 3fb6380 was supposed to increase MAX_TEXTURE_HOOKS but instead increased SHADER_MAX_HOOKS, since I forgot that they were separate (for whatever reason). To prevent this mistake from happening again, and to unify the location in which user_shader-specific #defines are placed, get rid of the two constants in opengl/video.c and move/reuse them from user_shaders.h instead. Also bump up MAX_SAVED_TEXTURES (now SHADER_MAX_SAVED) slightly as a precaution against adding more passes to vo_opengl. I think we're already flirting with the limit.
* vo_opengl: silence -Wmaybe-uninitialized false positiveGravatar Niklas Haas2017-06-24
| | | | | | | | | These can never be uninitialized because the enum cases are exhaustive and the fallback is in the correct order, but GCC is too dumb to understand this. Also explicitly initialize tex_type, because while GCC doesn't warn about it (for some reason), maybe it will in the future.
* vo_opengl: implement support for OOTFs and non-display referred contentGravatar Niklas Haas2017-06-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | This introduces (yet another..) mp_colorspace members, an enum `light` (for lack of a better name) which basically tells us whether we're dealing with scene-referred or display-referred light, but also a bit more metadata (in which way is the scene-referred light expected to be mapped to the display?). The addition of this parameter accomplishes two goals: 1. Allows us to actually support HLG more-or-less correctly[1] 2. Allows people playing back direct “camera” content (e.g. v-log or s-log2) to treat it as scene-referred instead of display-referred [1] Even better would be to use the display-referred OOTF instead of the idealized OOTF, but this would require either native HLG support in LittleCMS (unlikely) or more communication between lcms.c and video_shaders.c than I'm remotely comfortable with That being said, in principle we could switch our usage of the BT.1886 EOTF to the BT.709 OETF instead and treat BT.709 content as being scene-referred under application of the 709+1886 OOTF; which moves that particular conversion from the 3dlut to the shader code; but also allows a) users like UliZappe to turn it off and b) supporting the full HLG OOTF in the same framework. But I think I prefer things as they are right now.
* csputils: rename HDR curvesGravatar Niklas Haas2017-06-18
| | | | | | | | | | st2084 and std-b67 are really weird names for PQ and HLG, which is what everybody else (including e.g. the ITU-R) calls them. Follow their example. I decided against naming them bt2020-pq and bt2020-hlg because it's not necessary in this case. The standard name is only used for the other colorspaces etc. because those literally have no other names.
* video: refactor HDR implementationGravatar Niklas Haas2017-06-18
| | | | | | | | | | | | | | | List of changes: 1. Kill nom_peak, since it's a pointless non-field that stores nothing of value and is _always_ derived from ref_white anyway. 2. Kill ref_white/--target-brightness, because the only case it really existed for (PQ) actually doesn't need to be this general: According to ITU-R BT.2100, PQ *always* assumes a reference monitor with a white point of 100 cd/m². 3. Improve documentation and comments surrounding this stuff. 4. Clean up some of the code in general. Move stuff where it belongs.
* vo_opengl: fall back to ordered dither instead of blowing upGravatar wm42017-06-17
| | | | | | | | | | | | | In GLES 2 mode, we can do dither, but "fruit" dithering is still out of the question, because it does not support any high depth textures. (Actually we probably could use an 8 bit texture too for this, at least with small matrix sizes, but it's still too much of a pain to convert the data, so why bother.) This is actually a regression; before this, forcibly enabling dumb mode due to low GL caps actually happened to avoid this case. Fixes #4519.
* vo_opengl: change default tone mapping algorithmGravatar Niklas Haas2017-06-10
| | | | | d8a3b10f4 was supposed to change this (as reflected in the man page and commit message), I just forgot.
* vo_opengl: add new HDR tone mapping algorithmGravatar Niklas Haas2017-06-09
| | | | | | | | | | | | | | | | | I call it `mobius` because apparently the form f(x) = (cx+a)/(dx+b) is called a Möbius transform, which is the algorithm this is based on. In the extremes it becomes `reinhard` (param=0.0 and `clip` (param=1.0), smoothly transitioning between the two depending on the parameter. This is a useful tone mapping algorithm since the tunable mobius transform allows the user to decide the trade-off between color accuracy and detail preservation on a continuous scale. The default of 0.3 is already far more accurate than `reinhard` while also being reasonably good at preserving highlights, without suffering from the overall brightness drop and color distortion of `hable`. For these reasons, make this the new default. Also expand and improve the documentation for these tone mapping functions.
* vo_opengl: another attempt at removing the overlay correctlyGravatar wm42017-05-02
| | | | | | | | This reverts commit 142b2f23d4293, and replaces it with another try. The previous attempt removed the overlay on every rendering, because the normal rendering path actually unrefs the mp_image. Consequently, unmap_current_image() was completely inappropriate for removing the overlay.
* vo_opengl: make sure overlays are removed on gl_video_config()Gravatar wm42017-04-29
| | | | | This should make vo_opengl_cb uninit remove the frame, even if the renderer and OpenGL state remains active.
* vo_opengl: fix crash by coping temporal_dither_period for dumb mode tooGravatar wm42017-04-21
| | | | | Specifically, this field must never be 0 (and the option can naturally not be 0 in any way, unless it wasn't initialized correctly).
* vo_opengl: add option for caching shaders on diskGravatar wm42017-04-08
| | | | | | | | | | | | | Mostly because of ANGLE (sadly). The implementation became unpleasantly big, but at least it's relatively self-contained. I'm not sure to what degree shaders from different drivers are compatible as in whether a driver would randomly misbehave if it's fed a binary created by another driver. The useless binayFormat parameter won't help it, as they can probably easily clash. As usual, OpenGL is pretty shit here.
* vo_opengl: use 16 bit textures with angleGravatar wm42017-04-03
| | | | | | Regression due to 03fe506. It accidentally changed the default value if glGetTexLevelParameteriv() is not available, which is the case with ANGLE.
* vo_opengl: replace uniform variable image_size with input_sizeGravatar igv2017-03-25
| | | | | | input_size can be the size of a cropped image Signed-off-by: wm4 <wm4@nowhere>
* vo_opengl: add tex_offset uniform variable to user shadersGravatar igv2017-03-25
|
* vo_opengl: make size of a cropped source image available to user shadersGravatar igv2017-03-25
|
* vo_opengl: read framebuffer depth from actual FBO used for renderingGravatar wm42017-03-20
| | | | | | | | | | | | In some cases, such as when using the libmpv opengl-cb API, or with certain vo_opengl backends, the main framebuffer is never accessed. Instead, rendering is done to a FBO that acts as back buffer. This meant an incorrect/broken bit depth could be used for dithering. Change it to read the framebuffer depth lazily on the first render call. Also move the main FBO field out of the GL struct to MPGLContext, because the renderer's init function does not need to access it anymore.
* vo_opengl: move some init_gl code to utility functionsGravatar wm42017-03-20
|
* vo_opengl: properly respect dither option if dumb mode is usedGravatar wm42017-03-20
| | | | | | | When dumb mode is used (the "simple" rendering path), respect the dither options. Options should never be ignored (except in GLESv2 mode); either they should be respected in dumb mode, or they should disable dumb mode. In this case, the former applies.
* options: add M_OPT_FILE to some more file optionsGravatar Philip Sequeira2017-03-06
| | | | (Helps shell completion.)
* filter_kernels: Keep f.radius in terms of dest/filter coords.Gravatar Nicholas J. Kain2017-03-06
| | | | | | | | | | | | | The existing code modifies f.radius so that it is in terms of the filter sample radius (in the source coordinate space) and has some small errors because of this behavior. This commit changes f.radius so that it is always in terms of the filter function radius (in the destination coordinate space). The sample radius can always be derived by multiplying f.radius by filter_scale, which is the new, more descriptive name for the previous inv_scale.
* vo_opengl: move texture mapping of pixel formats to helper functionGravatar wm42017-02-17
| | | | | | | All supported pixel formats have a specific "mapping" of CPU data to textures. This function determines the number and the formats of these textures. Moving it to a helper will be useful for some hardware decode interop backends, since they all need similar things.
* vo_opengl: handle GL_LUMINANCE_ALPHA and integer textures differentlyGravatar wm42017-02-17
| | | | | | | | | | | | | | | GL_LUMINANCE_ALPHA is the only reason why per-plane swizzles exist. Remove per-plane swizzles (again), and regrettably handle them as special cases (again). Carry along the logical texture format (called gl_format in some parts of the code, including the new one). We also don't need a use_integer flag, since the new gl_format member implies whether it's an integer texture. (Yes, the there are separate logical GL formats for integer textures. This aspect of the OpenGL API is hysteric at best.) This should change nothing about actual rendering logic and GL API usage.
* vo_opengl: replace 2 memsetsGravatar wm42017-01-08
| | | | Cosmetic change.
* vo_opengl: partially fix rotation for 4:2:2 contentGravatar Niklas Haas2016-12-28
| | | | | | | | | | | | The chroma alignment renormalization code forgot to account for the fact that the chroma subsampling ratio has to be rotated. Unfortunately, doing it this way seems to have somewhat broken the chroma offset rotation logic for odd-sized subsampled image files. While this is a bug, it's much, much less noticeable, so it's not nearly as important as the bug this change fixes. Either way, a future patch needs to still revise this logic, ideally by redesigning the entire rotation mechanism.
* options: remove deprecated sub-option handling for --vo and --aoGravatar wm42016-11-25
| | | | | | | | Long planned. Leads to some sanity. There still are some rather gross things. Especially g_groups is ugly, and a hack that can hopefully be removed. (There is a plan for it, but whether it's implemented depends on how much energy is left.)
* vo_opengl: blend against background color for --alpha=blendGravatar Philip Sequeira2016-11-13
| | | | | Do it after color management, etc. so that it matches the color drawn in the margins.
* vo_opengl: fix --blend-subtitles handlingGravatar wm42016-11-07
| | | | | | | | | | | | | The intention was that if --blend-subtitles is enabled, the frame should always be re-rendered instead of using e.g. a cached scaled frame. The reason is that subtitles can change anyway, e.g. if you pause and change subtitle size and such. On the other hand, if the frame is marked as repeated, it should always use the cached copy. Actually "simplify" this and drop the cache only if playback is paused (which frame->still indicates indirectly). Also see PR #3773.
* vo_opengl: fix redrawing with hardware decodingGravatar wm42016-11-07
| | | | | | | | unmap_current_image() is called after rendering. This essentially invalidates the textures, so we can't assume that the image is still present. Also see PR #3773.
* filter_kernels: add ability to taper kernels/windowsGravatar Niklas Haas2016-11-01
| | | | | | | This allows us to define the tukey window (and other tapered windows). Also add a missing option definition for `wblur` while we're at it, to make testing out window-related stuff easier.
* vo_opengl: make frame reupload logic more robustGravatar wm42016-11-01
| | | | | | | | | | It's not that easy to decide whether a frame needs to be reuploaded/rerendered. Using unique frame IDs for input makes it slightly easier and more robust. This also removes the use of video PTS in the interpolation path. This should also avoid reuploading the video frame if it's just redrawn in paused mode, or when using OSD/subtitles in cover art mode.
* vo_opengl: partially re-enable glFlush() callsGravatar wm42016-10-21
| | | | | | | | | | | | It turns out the glFlush() call really helps in some cases, though only in audio timing mode (where we render, then wait for a while, then display the frame). Add a --opengl-early-flush=auto mode, which does exactly that. It's unclear whether this is fine on OSX (strange things going on there), but it should be. See #3670.
* vo_opengl: apply --opengl-early-flush in dumb mode tooGravatar wm42016-10-05
| | | | | | | | In "dumb mode" (where most features are disabled and which only performs some basic rendering) we explicitly copy a set of whitelisted options, and leave all the other options at their default values. Add the new --opengl-early-flush option to this whitelist. Also remove an option field accidentally added in the commit adding --opengl-early-flush.
* vo_opengl: disable glFlush() by default, and add an option to enable itGravatar wm42016-10-05
| | | | | | | | | | | It seems this can cause issues with certain platforms, so better to disable it by default. The original reason for this isn't overly justified, and display-sync mode should get rid of the need for it anyway. The new option is meant for testing, and will probably be removed if nobody comes up and reports that enabling the option actually improves anything.
* vo_opengl: minor simplificationGravatar wm42016-10-01
| | | | The extra gl_transform_trans() has no apparent use.
* vo_opengl: attempt to fix chroma offset under rotation and flippingGravatar wm42016-10-01
| | | | | | Other than being overly convoluted, this seems to make sense to me. Except that to get the "rot" transform I have to set flip=true, which makes no sense at all to me.
* vo_opengl: add debugging options for testing with padded texturesGravatar wm42016-10-01
|
* vo_opengl: partially fix dumb-mode cropping with rotationGravatar wm42016-09-30
| | | | | | | | | | | | Combining rotation and cropping didn't work. It was just completely broken. I'm still not sure if this is correct. Chroma positioning seems to be broken on rotation. There might also be a problem with non-mod-2 frame sizes. Still, strictly an improvement for both rotated and non-rotated rendering modes. Also, this could probably be written in a more elegant way.
* vo_opengl: allow hwdec interops to support multiple image formatsGravatar wm42016-09-30
|
* vo_opengl: apply 90° rotation to chroma texture sizeGravatar wm42016-09-22
| | | | | | | | | When we rotate the inmage by 90° or 270°, chroma width and height need to be swapped. Fixes #3568. But is the chroma sub location correct? Who the hell knows...
* options: slightly better option update mechanismGravatar wm42016-09-19
| | | | | | | | | | | | | | Extend the flag-based notification mechanism that was used via M_OPT_TERM. Make the vo_opengl update mechanism use this (which, btw., also fixes compilation with OpenGL renderers forcibly disabled). While this adds a 3rd mechanism and just seems to further the chaos, I'd rather have a very simple mechanism now, than actually furthering the mess by mixing old and new update mechanisms. In particular, we'll be able to remove quite some property implementations, and replace them with much simpler update handling. The new update mechanism can also more easily refactored once we have a final mechanism that handles everything in an uniform way.
* options: simplify M_OPT_EXITGravatar wm42016-09-17
| | | | | | | | | | | | | There were multiple values under M_OPT_EXIT (M_OPT_EXIT-n for n>=0). Somehow M_OPT_EXIT-n either meant error code n (with n==0 no error?), or the number of option valus consumed (0 or 1). The latter is MPlayer legacy, which left it to the option type parsers to determine whether an option took a value or not. All of this was changed in mpv, by requiring the user to use explicit syntax ("--opt=val" instead of "-opt val"). In any case, the n value wasn't even used (anymore), so rip this all out. Now M_OPT_EXIT-1 doesn't mean anything, and could be used by a new error code.
* vo_opengl: don't pass negative height to overlay_adjust()Gravatar wm42016-09-16
| | | | | | Negative height is used to signal a flipped framebuffer. There's absolutely no reason to pass this down to overlay_adjust(), and only requires implementers to deal with an additional special-case.
* vo_opengl: dynamically manage texture unitsGravatar wm42016-09-14
| | | | | | | | | | | | | | | | | | | | | A minor cleanup that makes the code simpler, and guarantees that we cleanup the GL state properly at any point. We do this by reusing the uniform caching, and assigning each sampler uniform its own texture unit by incrementing a counter. This has various subtle consequences for the GL driver, which hopefully don't matter. For example, it will bind fewer textures at a time, but also rebind them more often. For some reason we keep TEXUNIT_VIDEO_NUM, because it limits the number of hook passes that can be bound at the same time. OSD rendering is an exception: we do many passes with the same shader, and rebinding the texture each pass. For now, this is handled in an unclean way, and we make the shader cache reserve texture unit 0 for the OSD texture. At a later point, we should allocate that one dynamically too, and just pass the texture unit to the OSD rendering code. Right now I feel like vo_rpi.c (may it rot in hell) is in the way.
* vo_opengl: require explicit reset on shader cache after renderingGravatar wm42016-09-14
| | | | | | | | | The caller now has to call gl_sc_reset(), and _after_ rendering. This way we can unset OpenGL state that was setup for rendering. This affects the shader program, for example. The next commit uses this to automatically manage texture units via the shader cache. vo_rpi.c changes untested.
* vo_opengl: remove a redundant glActiveTexture() callGravatar wm42016-09-14
| | | | | This bound video textures to individual texture units - this is how it used to work long ago, but now is pointless, and maybe even dangerous.
* vo_opengl: fix typo in bt.601 auto-guessing logicGravatar Niklas Haas2016-09-13
| | | | | | | The wrong enum got copied here, so it was essentially using the transfer characteristics as the primaries (instead of the primaries), which accidentally worked fine most of the time (since the two usually coincided), but broke on weird/mistagged files.
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-01 00:44:51 +0000