summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* vo_opengl: apply vo-cmdline command incrementallywm42016-06-053-27/+26
| | | | | | | | | | Instead of implicitly resetting the options to defaults and then applying the options, they're always applied on top of the current options (in the same way adding new options to the CLI command line will). This does not apply to vo_opengl_cb, because that has an even worse mess which I refuse to deal with.
* vo_opengl_cb: icc-profile-auto does not and will not workwm42016-06-051-0/+2
| | | | | In theory we could probably make icc-profile-auto a vo_opengl-specific option, but I won't bother with this. Logging an error is simpler.
* vo_opengl: possibly update icc profile after changing optionswm42016-06-051-7/+12
| | | | | Changing the options can enable icc-profile-auto, and in this case the profile has to be reteieved again from the system.
* vo_opengl: somewhat simplify suboption handling messwm42016-06-041-64/+16
| | | | | | | | | | | | | | | Enable m_sub_options_copy() to copy nested sub-options, and also enable it to create an option struct from defaults. We can get rid of most of the crap in assign_options() now. Calling handle_scaler_opt() to get a static allocation for scaler name is still needed. It's moved to reinit_scaler(), which seems to be a better place for it. Without it, dangling pointers could be created when options are changed. (And in fact, this fixes possible dangling pointers for window.name.) In theory we could create a dynamic copy, but that seemed even more messy. Chance of regressions.
* vo_opengl: cleanup icc + runtime option changing behaviorwm42016-06-043-43/+72
| | | | | | | | | | | | | | Commit 026b75e7 actually enabled changing icc options at runtime (via vo_cmdline), but it didn't quite work. In particular, changing the icc- profile option just kept the old profile, because it was cached accordingly. As part of this, change gl_lcms.opts from a struct to a pointer to a struct. We properly copy it, instead of allowing possibly dangling strings, like it was done in a working but unclean way before. Also, reinit the whole rendering chain when the auto icc profile changes, just like it's done when icc options are changed.
* vo_opengl: minor simplification to gl_lcms_set_memory_profile()wm42016-06-043-11/+11
| | | | | | Passing the bstr thing as pointer makes no sense. Everywhere else bstr structs are passed by value because they're so small. Only when it's supposed to receive a return value they're not.
* vo_opengl: remove pointless NULL-checkwm42016-06-041-1/+1
| | | | It's never NULL.
* vo_opengl: move all icc handling from vo_opengl.c to video.cwm42016-06-035-26/+35
| | | | | | | | | | | | | | | Originally, video.c did not access any CMS things (other than lut3d being set on it), but this has changed. In practice, almost all accesses to it have moved to video.c. vo_opengl only created it, and set the auto icc profile path. Complete the move. Some things wrt. option handling are a bit fishy. (But when is this not the case.) icc-profile-auto was not tested, but the distributed human CI will take care of it.
* vo_opengl: move struct lut3d definitionwm42016-06-033-8/+6
| | | | | This was dumb. Also, lcms.h has actually no need to include video.h besides this and csputils.h (makes it slightly less entangled).
* vo_opengl: fix giant memory leaks with icc profileswm42016-06-031-0/+2
| | | | Well this was dumb.
* wayland: mark existing dnd entry print as debug rather than an errorRostislav Pehlivanov2016-05-311-1/+1
| | | | | | | | It gets printed on every alt+tab or desktop switch under mutter and weston, and offers no useful information since it's handled by destroying the previous entry. Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
* wayland: correctly report display refresh rateRostislav Pehlivanov2016-05-311-4/+6
| | | | | | | | | | | | This commit will cause the wayland backend and vo to correctly report the display frame rate. This didn't work as VOCTRL_GET_DISPLAY_FPS was received way too early, before the window was created (and thus current_output set). The VO will now signal VO_EVENT_WIN_STATE after window initialization and upon a resize. Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
* vo_opengl: default hdr-tone-mapping to hableNiklas Haas2016-05-301-0/+2
| | | | | | | | | This algorithm works really well. Setting it is a much better "out-of-the-box" experience than just clipping, which will always look ugly. In other words, with this default, users of mpv will just be able to play HDR content without even realizing it's HDR (pretty much).
* vo_opengl: refactor HDR mechanismNiklas Haas2016-05-306-27/+54
| | | | | | | | | | | | | | | | | | | | Instead of doing HDR tone mapping on an ad-hoc basis inside pass_colormanage, the reference peak of an image is now part of the image params (alongside colorspace, gamma, etc.) and tone mapping is done whenever peak_src != peak_dst. To get sensible behavior when mixing HDR and SDR content and displays, target-brightness is a generic filler for "the assumed brightness of SDR content". This gets rid of the weird display_scaled hack, sets the framework for multiple HDR functions with difference reference peaks, and allows us to (in a future commit) autodetect the right source peak from the HDR metadata. (Apart from metadata, the source peak can also be controlled via vf_format. For HDR content this adjusts the overall image brightness, for SDR content it's like simulating a different exposure)
* wayland: implement HIDPI supportRostislav Pehlivanov2016-05-304-12/+50
| | | | | | | | | | | | | | | | | | | | | | | | | The wayland protocol exposes scaling done by the compositor to compensate for small window sizes on small high DPI displays. If the program ignores the scaling done, what'll happen is the compositor is going to ask the program to be scaled down by N times the window size and then it'll upscale the program's surface by N times. The scaling algorithm seems to be bilinear so the scaling is quite obvious. This commit sets up callbacks to listen for the scaling factor of each output and, on rescale events, notifies the compositor that the surface's scale is what the compositor asked for and changes the player's surface to the appropriate size, causing no scaling to be done by the compositor. Compositors not supporting this interface will ignore the callbacks and do nothing, keeping program behaviour the same. For compositors supporting and using this interface (mutter), this will fix the rendering to be pixel precise as it should be. Both the opengl wayland backend and the wayland vo have been fixed to support this. Verified to not break either on weston and mutter. Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
* vf: fix filter auto-insertionwm42016-05-301-3/+13
| | | | | | | | | | | | | Commit 0348cd08 was too naive/simple, and always inserted the d3d11vpp filter if any d3d11 output image formats were supported, even if it makes no sense. For example --vf=format=rgb8 already breaks it. It needs to take the set of supported input formats into account. the weird format negotiation makes this hard. As a simple and cheap solution, make some assumptions about the supported formats of a filter. I hope to simplify this one day by using another format negotiation algorithm, but this can probably wait.
* mp_image: properly communicate aspect ratio through AVFramewm42016-05-301-1/+6
| | | | | No idea why this wasn't done before. In particular, this fixes playing anamorphic video through --lavfi-complex.
* mp_image: don't reset pixel aspect with mp_image_set_size()wm42016-05-302-4/+3
| | | | | | | | | | | | | | | No reason to do so. See also commit 240ba92b. Since now many mp_images will never have a pixel aspect ratio set, redefine a 0/0 aspect ratio to "undefined" instead invalid. This also brings it more in line with how decoder vs. container aspect ratios are handled. Most callers seem to be fine with the new behavior. mp_image_params_valid() in particular has to be adjusted, or some things stop working due to mp_images not becoming valid after setting size and format.
* vo_opengl: add hable tone-mapping algorithmNiklas Haas2016-05-303-0/+13
| | | | | | | | Developed by John Hable for use in Uncharted 2. Also used by Frictional Games in SOMA. Originally inspired by a filmic tone mapping algorithm created by Kodak. From http://frictionalgames.blogspot.de/2012/09/tech-feature-hdr-lightning.html
* vo_opengl: rename tone-mapping=simple to reinhardNiklas Haas2016-05-303-6/+6
| | | | | This is the canonical name for the algorithm. I simply didn't know it before.
* w32_common: center window on original window center on video resizemaniak13492016-05-301-0/+8
| | | | | | Position the window around the original window center on video size change (when switching to the next file with different resolution, for example) instead of keeping the position of its top-left corner fixed.
* mp_image: don't lose pixel aspect ratio when setting formatwm42016-05-291-1/+3
| | | | | | This is quite unexpected. It's caused by mp_image_set_size(), which is used to update certain fields which can be format-dependent, but which is actually also supposed to reset the pixel aspect ratio.
* video: remove d3d11 video processor use from OpenGL interopwm42016-05-299-446/+481
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We now have a video filter that uses the d3d11 video processor, so it makes no sense to have one in the VO interop code. The VO uses it for formats not directly supported by ANGLE (so the video data is converted to a RGB texture, which ANGLE can take in). Change this so that the video filter is automatically inserted if needed. Move the code that maps RGB surfaces to its own inteorp backend. Add a bunch of new image formats, which are used to enforce the new constraints, and to automatically insert the filter only when needed. The added vf mechanism to auto-insert the d3d11vpp filter is very dumb and primitive, and will work only for this specific purpose. The format negotiation mechanism in the filter chain is generally not very pretty, and mostly broken as well. (libavfilter has a different mechanism, and these mechanisms don't match well, so vf_lavfi uses some sort of hack. It only works because hwaccel and non-hwaccel formats are strictly separated.) The RGB interop is now only used with older ANGLE versions. The only reason I'm keeping it is because it's relatively isolated (uses only existing mechanisms and adds no new concepts), and because I want to be able to compare the behavior of the old code with the new one for testing. It will be removed eventually. If ANGLE has NV12 interop, P010 is now handled by converting to NV12 with the video processor, instead of converting it to RGB and using the old mechanism to import that as a texture.
* 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
| | | | | | | | | | | |