summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* vf_d3d11vpp: add a D3D11 video processor filterwm42016-05-284-0/+500
| | | | | | | | | | | | | | | | | Main use: deinterlacing. I'm not sure how to select the deinterlacing mode at all. You can enumate the available video processors, but at least on Intel, all of them either signal support for all deinterlacers, or none (the latter is apparently used for IVTC). I haven't found anything that actually tells the processor _which_ algorithm to use. Another strange detail is how to select top/bottom fields and field dominance. At least I'm getting quite similar results to vavpp on Linux, so I'm content with it for now. Future plans include removing the D3D11 video processor use from the ANGLE interop code.
* vo_opengl: angle: enable DirectCompositionJames Ross-Gowan2016-05-291-10/+22
| | | | | | This avoids a copy of the video image and lowers vsync jitter. Since there are now two options to add to the window_attribs list, it has been made dynamic.
* vf_vdpaupp: use refqueue helperwm42016-05-274-111/+83
| | | | | | | | | | | This makes vf_vdpaupp use the deinterlacer helper code already used by vf_vavpp. I nice side-effect is that this also removes some traces of code originating from vo_vdpau.c, so we can switch it to LGPL. Extend the refqueue helper with a deint setting. If not set, mp_refqueue_should_deint() always returns false, which slightly simplifies vf_vdpaupp. It's of no consequence to vf_vavpp (other than it has to set it to get expected behavior).
* vo_opengl: skip junk before first user shader passNiklas Haas2016-05-271-0/+8
| | | | | | | | | | A lot of real-world shaders start off with comments explaining the usage or license, generating lots of "empty" passes. This simply change allows us to skip them, which silences the warning spam and prevents us from having to store and copy around these empty passes. It also adds a more useful failure check: Attempting to use a user shader that doesn't define any passes at all.
* vo_opengl: enable color management on GLESJames Ross-Gowan2016-05-272-3/+8
| | | | | | This requires the GL_EXT_texture_norm16 extension and works in ANGLE. A default precision had to be set for sampler3Ds, otherwise the shaders would fail to compile.
* vo_opengl: fix superxbr shader compilation on ESwm42016-05-261-11/+11
| | | | | ES shaders do not allow implicit conversion from int to float, which is the most annoying ES anti-feature ever.
* vo_opengl: always autoselect ANGLE as backend if availablewm42016-05-261-1/+0
| | | | | | | | | | | | | | | | | | | | | | Remove the opengl-hq option default that caused it not to autoselect ANGLE (unlike --vo=opengl). Details see commit d5df90a2. Back then the intention was to use ANGLE by default, since it integrates much nicer with the Windows compositor (instead of native OpenGL, which tends to cause crazy glitches). On the other hand, many opengl-hq capabilities are not available with older ANGLE builds, so it didn't make any sense to autoselect ANGLE for it. With the GL_EXT_texture_norm16 extension recently added to ANGLE, it has essentially reached feature parity to desktop GL for the subset we are using. (Even the integer texture hack for high bit depth input could be dropped now.) It (probably) still does not support nnedi3, due to the weird way the NN coefficients are imported. Also, it uses half-floats instead of 16 bit fixed-point textures for technical reasons, which implies about 5 bits of precision loss. If anyone actually manages to distinguish the two dithering texture formats in a double-blind test, I will fix it.
* vf_vavpp: make refqueue logic field-basedwm42016-05-253-86/+143
| | | | | | | Abstracts the annoying framerate-doubling behavior. Same deal as with refqueue introduction: the code size blows up, but at least it can be reused for other filters.
* vf_vavpp: minor simplificationwm42016-05-251-4/+6
|
* vf_vavpp: simplify update_pipeline() usagewm42016-05-251-13/+18
| | | | | | | | | | | | | Calling this right at start of filter_ext() also fixes a small regression from previous commit. The change in reference surfaces due to the first update_pipeline() with deinterlacing enabled changed behavior of mp_refqueue_next() and mp_refqueue_has_output(). Since update_pipeline() was called between those, the frame output logic got inconsistent, and the first deinterlaced frame was duplicated from the previous non-deinterlaced frame. Also reset the number of ref-frames when switching back to non-deint mode.
* vf_vavpp: use future instead of past PTS to determine field durationwm42016-05-251-7/+7
| | | | | | | | | | | | If the deinterlacer separates fields, the framerate must be doubled. Since we have no stable and reliably framerate anywhere, we've been calculating it by taking the time halfway to the next frame. vf_vavpp actually used the past frame to calculate the frame duration, which is sort of ok, but will skip the 2nd field in a stream (since the first frame has no past PTS). This is annoying for testing, so use the future frame PTS instead, which means the last field of the stream will be dropped instead.
* vf_vavpp: move frame handling to separate filewm42016-05-253-57/+205
| | | | | | | | | | | | | | Move the handling of the future/past frames and the associated dataflow rules to a separate source file. While this on its own seems rather questionable and just inflates the code, I intend to reuse it for other filters. The logic is annoying enough that it shouldn't be duplicated a bunch of times. (I considered other ways of sharing this logic, such as an uber- deinterlace filter, which would access the hardware deinterlacer via a different API. Although that sounds like kind of the right approach, this would have other problems, so let's not, at least for now.)
* hwdec_d3d11egl: call ID3D11DeviceContext::Flushwm42016-05-241-5/+13
| | | | | | | | | This must be called if a texture shared between D3D devices is updated. Often enough, the shared devices will be the same device, but ANGLE forces using shared surfaces. I suppose there is no guarantee the driver will do the expected thing. Internally, the driver could for example not insert the required barriers before the shared texture is used.
* vo_xv: Handle incorrect size returned by Xv(Shm)CreateImagedequis2016-05-241-0/+9
| | | | | | | | | | | | | Fixes #320 (which is closed as 'not our problem' but eh) Relevant xorg bug: https://bugs.freedesktop.org/show_bug.cgi?id=70931 For me this happened when (accidentally) trying to play a 8460x2812 jpg file with mpv. Like the referenced bug, xvinfo reports "maximum XvImage size: 8192 x 8192". So the returned XvImage is 8192x2812 and memory corruption happens. Only after handling this BadShmSeg X11 errors are shown.
* vo_opengl: fix other minor namespace issueswm42016-05-235-12/+12
| | | | See previous commit.
* vo_opengl: rename glUploadTex, drop unused parameterwm42016-05-234-16/+13
| | | | | | | | Rename it to get out of OpenGL's namespace. The gl_ prefix is used by other mpv functions, but no OpenGL ones. The "slice" parameter was never actually used, and all callers passed 0 for it.
* vo_opengl: unify PBO and normal OSD texture upload pathwm42016-05-233-69/+47
| | | | | | | | | | | | | The main change is actually that e first copy to a "staging" memory frame, and then upload this at once. The old non-PBO code called glTexsubImage2D for each OSD sub-bitmap. The new non-PBO code path is a bit faster now if there are many small sub-bitmaps (on Linux/nVidia). It's also a bit simpler, so this is a win. (Although I don't particularly appreciate the mixed normal/PBO texture code.)
* vo_opengl: make ES float texture format checks stricterwm42016-05-234-12/+3
| | | | | | | | | | | | | | | Some of these checks became pointless after dropping ES 2.0 support for extended filtering. GL_EXT_texture_rg is part of core in ES 3.0, and we already check for this version, so testing for the extension is redundant. GL_OES_texture_half_float_linear is also always available, at least as far as our needs go. The functionality we need from GL_EXT_color_buffer_half_float is always available in ES 3.2, and we explicitly check for ES 3.2, so reject this extension if the ES version is new enough.
* vo_opengl: make PBOs work on GLES 3.xwm42016-05-234-10/+24
| | | | | | | | | | | | | For some reason, GLES has no glMapBuffer, only glMapBufferRange. GLES 2 has no buffer mapping at all, and GL 2.1 does not always have glMapBufferRange. On those PBOs remain unsupported (there's no reason to care about GL 2.1 without the extension). This doesn't actually work on ANGLE, and I have no idea why. (There are artifacts on OSD, as if parts of the OSD data weren't copied.) It works on desktop OpenGL and at least 1 other ES 3 implementation. Don't enable it on ANGLE, I guess.
* vo_opengl: remove unused glDrawBufferwm42016-05-232-2/+0
|
* vo_opengl: support framebuffer invalidationwm42016-05-234-0/+26
| | | | | | | | | | Not sure how much can be gained with this, as we can't use it properly yet. For now, this is used only before rendering, which probably does overwhelmingly nothing. In the future, this should be used after temporary passes, which could possibly reduce memory usage and even memory bandwidth usage, depending on the drivers.
* vo_opengl: slightly improve logging of loaded extensionswm42016-05-231-2/+2
| | | | | Only log when actual extensions are loaded, never log anything about builtins.
* w32_common: make VOCTRL_SET_UNFS_WINDOW_SIZE resize the window around its centermaniak13492016-05-221-0/+4
| | | | | | | | | | Before that position of the window top-left corner was remaining the same when the window was scaled. Right now VOCTRL_SET_UNFS_WINDOW_SIZE is called only by window-scale. This change will not affect resizes made by the user (dragging window edge). Fixes #3164.
* w32_common: center window on original window center on resize to fit screenmaniak13492016-05-221-3/+6
| | | | | | | | | | Center the window on the original window center instead of the screen center when the window has been resized due to requested window size exceeding the size of the screen. If user moved the window, he probably did it for the reason and he probably don't want it to get back to the center of the screen when he is resizing it (with window-scale for example).
* w32_common: update stored client area size on window resizemaniak13492016-05-221-0/+10
| | | | | | | | Properly update stored client area size when the window is resized in reinit_window_state due to window size exceeding the size of the screen. This was causing wrong behavior with window-scale - when window size was becoming too big the window was resized but the video was not.
* vo_opengl: remove non-working rgb/rgba FBO formatswm42016-05-201-3/+1
| | | | | | | | | | | Following commit 84ccebd9, the internal helpers don't allow GL_RGB and GL_RGBA as internal formats for FBO attachments anymore. While OpenGL itself is perfectly fine with it, I don't see much of a reason to bother, and mixing sized and unsized internal formats is confusing anyway. Just remove these formats.
* vf_crop: support opaque hardware decoding formatswm42016-05-191-8/+23
| | | | | | | | | | | | Cropping usually happens by adjusting the plane start pointers and the image size. The former is obviously not possible for opaque hwaccel formats, but the latter must work. Since the code already takes care of aligning the top/left crop origin to chroma alignment, simply set the crop origin to 0/0 in the hwaccel case. Also add a message if such an adjustment happens. Supporting this isn't worth much; the main usefulness is with debugging.
* vo_opengl: require at least ES 3.0 for float textureswm42016-05-191-1/+1
| | | | | | | | | | | | ES 2.0 has this weird rule that not the internalformat parameter determines the internal format, but the combination of all texture parameters. GL_OES_texture_half_float thus does not specify e.g. a GL_RGBA16F format, but requires passing GL_RGBA as format and GL_HALF_FLOAT_OES as type. We won't bother with this, since ES 2.0 is a lost cause anyway. This also removes the OpenGL error when the code is trying to create a f16 FBO for testing whether FBOs work.
* vo_opengl: change error state handling and fix hwdec crashes on errorswm42016-05-191-20/+34
| | | | | | | | | | | | | | | | gl_video_upload_image() can fail in the hardware decoding case. In this case rendering continued "normally", which meant that pass_get_img_tex() would kill the process with an assertion failure. Fix this by allowing gl_video_upload_image() to fail, and exit rendering early enough to skip code which requires an image to be present. (Maybe this is still a bit too subtle, but better than before.) Set an error flag, and render the blue screen we introduced for shader errors. (For this purpose also move the rendering of it to final output, to ensure it's visible at all.) The error flag is temporary, because the associated failure might also be temporary, unlike shader compilation errors.
* vo_opengl: d3d11egl: enable "required" GLSL extensionswm42016-05-193-0/+10
| | | | | | | | ANGLE doesn't handle this very strictly. But if they change this in the future, it shouldn't brick us. Not quite happy with this glsl_extensions fields, but it is quite unintrusive after all.
* 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