summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* vo_opengl: make gl_sc_enable_extension() permanent/idempotentwm42016-05-191-2/+12
| | | | | | | | No reason not to, and makes the following commit slightly simpler. In fact, this makes the shaders more correct too. Normally, "#extension" must come before any normal shader text, including the "precision" directive. Not sure why this worked before. (Probably didn't.)
* vo_opengl: d3d11egl: enable direct nv12 sampling on ES 3.xwm42016-05-191-3/+3
| | | | | | ANGLE was missing texture() overloads in the shader compiler for GL_TEXTURE_EXTERNAL_OES textures. Support has been added upstream, so we can use it now.
* vo_opengl: remove unused fieldwm42016-05-181-2/+1
|
* vo_opengl: fix/simplify reinitialization on dynamic reconfigurationwm42016-05-181-20/+9
| | | | | | | | | | | | | With the new hooks mechanism, user shaders and such are actually loaded before rendering starts, instead of being loaded during rendering. This is used to cache them (instead of e.g. reparsing them every frame). The cached state wasn't cleared correctly in some situations. Namely, resizing didn't correctly enable/disable prescale hooks. Reorganize how these reinitializations are handled. Get rid of reinit_rendering(), whose meaning was pretty unclear. Call the required functions to reset or recreate state directly wherever they are needed.
* d3d: simplify DLL loadingwm42016-05-174-49/+34
| | | | | | | | | | | | | | | For some reason, the d3d9/dxva2/d3d11 DLLs are still optional. But we don't need to try so hard to keep exact references. In fact, there's no reason to unload them at all. So load them once in a central place. For simplicity, the d3d9/d3d11 backends both load all DLLs. (They will error out only if the required DLLs could not be loaded.) In theory, we could just call LoadLibrary multiple times (without calling FreeLibrary), but I'm slightly worried that this could be detected as a "bug", or that the reference count could even have a low static limit that could be hit soon.
* video: merge dxva2 source fileswm42016-05-173-121/+62
| | | | | | | video/dxva2.c exported only 2 functions, both used only by video/decode/dxva2.c. The same was already done for d3d11.
* vo_opengl: hwdec: remove build-dependency on dxva2wm42016-05-172-4/+2
| | | | | | | | | | | | | wscript builds hwdec_dxva2gldx.c if gl-dxinterop is enabled, while video/dxva2.c depends on d3d-hwaccel. If d3d-hwaccel is disabled, then hwdec_dxva2gldx.c will fail to link, because it uses d3d9_surface_in_mp_image(), defined in dxva2.c. Fix this by removing the use of this function. It has barely any value at this point anyway. Just use the libavcodec documented way to get the surface directly. Fixes #3150.
* vo_opengl: move UT_buffer to switch handlingwm42016-05-171-5/+5
| | | | No reason to make it a special case.
* vo_opengl: make number of cached shaders/uniform dynamicwm42016-05-171-12/+24
| | | | | | | | | | Use dynamic memory allocation, as the static allocation is starting to get annoying. Currently, SC_MAX_ENTRIES is essentially still a static upper limit on the number of shaders. But in future we could try a more clever cache replacement strategy, which does not keep stale entries forever if the maximum happens not to be reached.
* vo_opengl: move cached uniforms to a separate structwm42016-05-171-10/+15
|
* vo_opengl: increase shader limitsNiklas Haas2016-05-171-2/+2
| | | | | | | | | | | | | The new uniforms introduced by 362015c have exceeded the uniform limit when using high-radius tscale. In addition, the SC limit of 32 entries might be pushing it with user shaders. Just make these value a bigger to delay the onset of this same failure mode. Maybe in the future it should be reworked to grow dynamically? Either way, we *can* always predict a static upper bound on the number of uniforms and shader cache entries, it's just that we forgot to do so. Fixes #3151
* vo_opengl: skip tonemapping if the output trc is HDRNiklas Haas2016-05-161-1/+3
| | | | | | | | | | | | | This makes it so that users with actual HDR displays can just set their config to target-trc=st2084 and get native HDR output. This will look a bit silly for SDR content (everything will be really bright), but for lack of a better tone mapping situation (including reverse tone mapping) this is the easiest thing to do for now. Ideally the brightness metadata should be part of the colorspace struct or something (with mpv always adapting where necessary), but it depends on the TRC and not the primaries so it's a bit more complicated than that.
* vo_opengl: copy over HDR parameters to dumb_modeNiklas Haas2016-05-161-0/+3
| | | | | | Since dumb mode is affected by tone mapping (which I'll call a feature, not a bug), we need to copy over the configuration - in particular, the defaults. (To prevent a render failure)
* vo_opengl: fall back to gamma2.2 by default for HDR contentNiklas Haas2016-05-161-2/+7
| | | | | | | | | | | Since HDR content is now auto-detected as such, we should probably do something smarter in the "no configuration" case, such as outputting gamma 2.2 instead. This decision will affect the majority of users of stock configurations who just play back appropriately tagged HDR files, so having a good default behavior is important. "Output the HDR content as-is" is definitely not likely to give the user a good result.
* csputils: add AVCOL_TRC_SMPTEST2084 supportNiklas Haas2016-05-161-6/+12
| | | | | | | This now lets us auto-detect appropriately tagged HDR content using FFmpeg's new TRC entries (when available). Hidden behind an #if because Libav stable doesn't have it yet.
* vo_opengl: remove unnecessary castswm42016-05-161-11/+11
|
* vo_opengl: remove another unneeded allocationwm42016-05-161-3/+1
|
* vo_opengl: remove possibly undefined behaviorwm42016-05-161-1/+3
|
* vo_opengl: free to-be-added hook on hook array overflowwm42016-05-161-0/+3
| | | | | | Seems sensible. Untested.
* vo_opengl: never clear file cachewm42016-05-161-12/+4
| | | | | | | | | Make it dynamic and never remove entries from it. For now, this is better than possibly creating dangling pointers all over the place in the gl_user_shader struct. Untested.
* vo_opengl: use proper include statementwm42016-05-161-1/+2
|
* vo_opengl: remove unnecessary allocationwm42016-05-161-3/+1
|
* vo_opengl: remove unused global variablewm42016-05-161-1/+1
| | | | ?
* vo_opengl: fix bicubic_fast in ES modewm42016-05-161-1/+1
| | | | | | GLES shaders disallow implicit conversion from int to float. This has been broken for quite a while.
* vo_opengl: implement more HDR tonemapping algorithmsNiklas Haas2016-05-164-4/+64
| | | | | | | | | | | | | | | | | | | | | This is now a configurable option, with tunable parameters. I got inspiration for these algorithms off wikipedia. "simple" seems to work pretty well, but not well enough to make it a reasonable default. Some other notable candidates: - Local functions (e.g. based on local contrast or gradient) - Clamp with soft knee (linear up to a point) - Mapping in CIE L*Ch. Map L smoothly, clamp C and h. - Color appearance models These will have to be implemented some other time. Note that the parameter "peak_src" to pass_tone_map should, in principle, be auto-detected from the SEI information of the source file where available. This will also have to be implemented in a later commit.
* vo_opengl: avoid redundant double-gamma conversionNiklas Haas2016-05-161-3/+3
| | | | | | | | | | | | Due to the way color management in mpv worked historically, the subtitle blending function was written to preserve the linearity of the input. (In the past, the 3DLUT function required linear inputs) Since the 3DLUT was refactored to accept the video color directly, the re-linearization after blending is now virtually always redundant. (Notably, it's also redundant when CMS is turned off, so this way of writing the code stopped making sense a long time ago. It is a remnant from before the pass_colormanage function was as flexible as it is now)
* vo_opengl: implement HDR (SMPTE ST2084)Niklas Haas2016-05-165-3/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | Currently, this relies on the user manually entering their display brightness (since we have no way to detect this at runtime or from ICC metadata). The default value of 250 was picked by looking at ~10 reviews on tftcentral.co.uk and realizing they all come with around 250 cd/m^2 out of the box. (In addition, ITU-R Rec. BT.2022 supports this) Since there is no metadata in FFmpeg to indicate usage of this TRC, the only way to actually play HDR content currently is to set ``--vf=format=gamma=st2084``. (It could be guessed based on SEI, but this is not implemented yet) Incidentally, since SEI is ignored, it's currently assumed that all content is scaled to 10,000 cd/m^2 (and hard-clipped where out of range). I don't see this assumption changing much, though. As an unfortunate consequence of the fact that we don't know the display brightness, mixed with the fact that LittleCMS' parametric tone curves are not flexible enough to support PQ, we have to build the 3DLUT against gamma 2.2 if it's used. This might be a good thing, though, consdering the PQ source space is probably not fantastic for interpolation either way. Partially addresses #2572.
* vo_opengl: use enums for choice options internallyNiklas Haas2016-05-162-28/+56
| | | | | | This is much more readable than hard-coding magic IDs all over the file, and removes the need for all the explanatory comments that were a direct result of this.
* vo_opengl: abstract hook texture access behind macroNiklas Haas2016-05-157-135/+124
| | | | | | | | | | | | | | | | | | | | | | | | This macro takes care of rotation, swizzling, integer conversion and normalization automatically. I found the performance impact to be nonexistant for superxbr and debanding, although rotation *did* have an impact due to the extra matrix multiplication. (So it gets skipped where possible) All of the internal hooks have been rewritten to use this new mechanism, and the prescaler hooks have finally been separated from each other. This also means the prescale FBO kludge is no longer required. This fixes image corruption for image formats like 0bgr, and also fixes prescaling under rotation. (As well as other user hooks that have orientation-dependent access) The "raw" attributes (tex, tex_pos, pixel_size) are still un-rotated, in case something needs them, but ideally the hooks should be rewritten to use the new API as much as possible. The hooked texture has been renamed from just NAME to NAME_raw to make script authors notice the change (and also deemphasize direct texture access). This is also a step towards getting rid of the use_integer pass.
* vo_opengl: make the screen blue on shader errorsNiklas Haas2016-05-153-0/+31
| | | | | This helps visually signify that somthing went wrong, and prevents confusing shader compilation errors with other types of bugs.
* vo_opengl: use RPN expressions for user hook sizesNiklas Haas2016-05-153-9/+193
| | | | | | | | | This replaces the previous TRANSFORM by WIDTH, HEIGHT and OFFSET where WIDTH and HEIGHT are RPN expressions. This allows for more fine-grained control over the output size, and also makes sure that overwriting existing textures works more cleanly. (Also add some more useful bstr functions)
* vo_opengl: support external user hooksNiklas Haas2016-05-156-33/+265
| | | | | | | | | | | This allows users to add their own near-arbitrary hooks to the vo_opengl processing pipeline, greatly enhancing the flexibility of user shaders. This enables, among other things, user shaders such as CrossBilateral, SuperRes, LumaSharpen and many more. To make parsing the user shaders easier, shaders are now loaded as bstrs, and the hooks are set up during video reconfig instead of on every single frame.
* vo_opengl: add optional hook pointsNiklas Haas2016-05-153-90/+140
| | | | | | | | | | | | | | These are "sequence points" where the image could be rendered out to an FBO, hooked, and re-loaded if any such hook exists. This is perfect for things like the current user shaders system, as well as optional effects like unsharp masking. Note that since we have to pick *some* FBO to store the optionally hooked texture, we just store it in an array indexed by an increasing counter. Since we only ever store as many as MAX_TEXTURE_HOOKS + all internal hook points entries, this is guaranteed to be enough space. This commit also removes some of the now unused FBOs.
* vo_opengl: add hooks and rework pass_read_videoNiklas Haas2016-05-152-232/+448
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
* vo_opengl: minor change to scaler_resizes_onlyNiklas Haas2016-05-151-3/+6
| | | | | | Instead of rounding down, we round to the nearest float. This reduces the maximum possible error introduced by this rounding operation. Also clarify the comment.
* vaapi: avoid forward declaration of variablewm42016-05-151-9/+7
| | | | Why is everything so horrible.
* vo_opengl: remove some pointless compatibilitywm42016-05-142-4/+3
| | | | | | Remove non-texture_rg compatibility from LUT sampling. OpenGL without texture_rg support will always trigger dumb-mode, and dumb-mode does not use LUTs. It used not to, and that was when this made sense.
* vo_opengl: partially fix 0bgr format supportwm42016-05-131-2/+6
| | | | | | | | | | | | | | | | | | | Fixes broken colors with --vf=format=0bgr (but only if deband is disabled). 0bgr means the first byte is padding, while the following three bytes are bgr. From the vo_opengl perspective, it has 4 physical components with 3 logical components. copy_img_tex() simply copied 3 components from the physical representation, which means the last component (r) was sliced off. Fix this by not using p->color_swizzle for packed formats, and instead let packed formats set the per-plane swizzle in texplane.swizzle. The latter applies the swizzle as part of operation in copy_img_tex(), which essentially moves physical to logical representations. Unfortunately, debanding (and thus with opengl-hq defaults) is still broken.
* vo_opengl: drop duplicate LUMINANCE_ALPHA handlingwm42016-05-131-10/+3
| | | | | | This was supposed to handle the absence of GL_ARB_texture_rg. But it's already handled elsewhere. (init_format() sets texplane.swizzle accordingly.)
* vo_opengl: minor simplificationwm42016-05-131-8/+8
| | | | | | | | Make the find_plane_format function take a bit count. This also makes the function's comment true for the first time the function and its comment exist. (It was commented as taking bits, but always took bytes.)
* vo_opengl: restrict ES2 FBO formatswm42016-05-131-4/+4
| | | | | | | | | Only a few very low bit depth internal formats can be rendered to in pure ES2 (GL_RGB565 is the "best" one). Seems like the only potentially reasonable renderable formats in ES2 could be provided via GL_OES_rgb8_rgba8, or half-floats, so don't bother with this at all.
* vo_opengl: angle: log extension stringwm42016-05-131-0/+4
|
* vo_opengl: slightly better FBO format checkwm42016-05-121-9/+17
| | | | | | | | | | | Now that we know in advance whether an implementation should support a specific format, we have more flexibility when determining which format to use. In particular, we can drop the roundabout ES logic. I'm not sure if actually trying to create the FBO for probing still has any value. But it might, so leave it for now.
* vo_opengl: disable scalers on ES2wm42016-05-121-4/+6
| | | | | | | | Even if everything else is available, the need for first class arrays breaks it. In theory we could fix this since we don't strictly need them, but I guess it's not worth bothering. Also give the misnamed have_mix variable a slightly better name.
* vo_opengl: add detection for the ES texture_rg extensionwm42016-05-121-0/+6
|
* vo_opengl: reorganize texture format handlingwm42016-05-129-311/+443
| | | | | | | | | | | | | This merges all knowledge about texture format into a central table. Most of the work done here is actually identifying which formats exactly are supported by OpenGL(ES) under which circumstances, and keeping this information in the format table in a somewhat declarative way. (Although only to the extend needed by mpv.) In particular, ES and float formats are a horrible mess. Again this is a big refactor that might cause regression on "obscure" configurations.
* vo_opengl: correctly disable interpolation if tscale can't be usedwm42016-05-121-0/+2
| | | | It'll fail with an assertion in the interpolation code otherwise.
* vo_opengl: angle: dump translated shaderswm42016-05-124-0/+25
| | | | Helpful for debugging and such.
* vo_opengl: don't use dumb-mode with 10 bit integer texture hackwm42016-05-111-2/+3
| | | | | Recent regression. Caused it to use dumb-mode with integer textures, which on ANGLE leads to nearest scaling.
* vo_opengl: fix NULL deref on certain init failureswm42016-05-111-2/+4
|
* video: add --hwdec=auto-copy modewm42016-05-117-5/+19
| | | | | | | | This uses the normal autoprobing rules like "auto", but rejects anything that isn't flagged as copying data back to system memory. The chunk in command.c was dead code, so remove it instead of updating it.
* vo_opengl: d3d11egl: support full range YUVwm42016-05-111-3/+3
| | | | | | | | | MSDN documents this as "Introduced in Windows 8.1.". I assume on Windows 7 this field will simply be ignored. Too bad for Windows 7 users. Also, I'm not using D3D11_VIDEO_PROCESSOR_NOMINAL_RANGE_16_235 and D3D11_VIDEO_PROCESSOR_NOMINAL_RANGE_0_255, because these are apparently completely missing from the MinGW headers. (Such a damn pain.)
* vo_opengl: d3d11egl: don't require EGL_EXT_device_querywm42016-05-111-23/+46
| | | | | | | Older ANGLE builds don't export this. This change is really only for convenience, and I might revert it at some later point.
* build: merge d3d11va and dxva2 hwaccel checkswm42016-05-113-7/+3
| | | | | | We don't have any reason to disable either. Both are loaded dynamically at runtime anyway. There is also no reason why dxva2 would disappear from libavcodec any time soon.
* vo_opengl: angle: dynamically load ANGLEwm42016-05-115-0/+132
| | | | | | | | | | | | ANGLE is _really_ annoying to build. (Requires special toolchain and a recent MSVC version.) This results in various issues with people having trouble to build mpv against ANGLE (apparently linking it against a prebuilt binary doesn't count, or using binaries from potentially untrusted sources is not wanted). Dynamically loading ANGLE is going to be a huge convenience. This commit implements this, with special focus on keeping it source compatible to a normal build with ANGLE linked at build-time.
* vo_opengl: fix passing along swizzle from hwdec interopwm42016-05-102-0/+4
| | | | | | | | | | In theory this was needed for the previous commit (but wasn't in practice, since for hwdec the LUMINANCE_ALPHA mangling is not applied anymore, and ANGLE uses RG textures in absence of GL_ARB_texture_rg for whatever crazy reasons). In practice this caused funky colors on OSX with the uyvy422 format, which is also fixed in this commit.
* vo_opengl: d3d11egl: native NV12 sampling supportwm42016-05-104-20/+251
| | | | | | | | | | | | | | | | | This uses EGL_ANGLE_stream_producer_d3d_texture_nv12 and related extensions to map the D3D textures coming from the hardware decoder directly in GL. In theory this would be trivial to achieve, but unfortunately ANGLE does not have a mechanism to "import" D3D textures as GL textures. Instead, an awkward mechanism via EGL_KHR_stream was implemented, which involves at least 5 extensions and a lot of glue code. (Even worse than VAAPI EGL interop, and very far from the simplicity you get on OSX.) The ANGLE mechanism so far supports only the NV12 texture format, which means 10 bit won't work. It also does not work in ES3 mode yet. For these reasons, the "old" ID3D11VideoProcessor code is kept and u