summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* vo_opengl: fix issues with some obscure pixel formatswm42015-12-075-11/+39
| | | | | | | | | | | | | | | | | | | The computation of the tex_mul variable was broken in multiple ways. This variable is used e.g. by debanding for moving expansion of 10 bit fixed-point input to normalized range to another stage of processing. One obvious bug was that the rgb555 pixel format was broken. This format has component_bits=5, but obviously it's already sampled in normalized range, and does not need expansion. The tex_mul-free code path avoids this by not using the colormatrix. (The code was originally designed to work around dealing with the generally complicated pixel formats by only using the colormatrix in the YUV case.) Another possible bug was with 10 bit input. It expanded the input by bringing the [0,2^10) range to [0,1], and then treating the expanded input as 16 bit input. I didn't bother to check what this actually computed, but it's somewhat likely it was wrong anyway. Now it uses mp_get_csp_mul(), and disables expansion when computing the YUV matrix.
* vo_opengl: decrease default lookup texture size to 64Bin Jin2015-12-071-2/+2
| | | | | | It turns out that with accurate lookup we can decrease the default size of texture now. Do it to compensate the performance loss introduced by the LUT_POS macro.
* vo_opengl: make LOOKUP_TEXTURE_SIZE configurableBin Jin2015-12-072-4/+5
|
* vo_opengl: Fix minor LUT sampling errorBin Jin2015-12-073-11/+22
| | | | | | Define a macro to correct the coordinate for lookup texture. Cache the corrected coordinate for 1D filter and use mix() to minimize the performance impact.
* filter_kernels: add warnings for potential LUT sampling errorBin Jin2015-12-071-0/+6
|
* cocoa: fix recent regressionwm42015-12-071-4/+6
| | | | | | | Commit 9db50c67 changed it so that the window title can now be a NULL string. Completely untested. Probably fixes #2570.
* win32: add option to set VO MMCSS profilewm42015-12-061-1/+5
| | | | This was requested.
* vo: get rid of vo_get_window_title()wm42015-12-066-34/+28
| | | | | | | | | | | It always was a weird artifact - VOCTRLs are meant _not_ to require special handling in the code that passes them through (like in vo.c). Removing it is also interesting to further reduce the dependency of backends on struct vo. Just get rid of it. Removing it is somewhat inconvenient, because in many situations the UI window is created after the first VOCTRL_UPDATE_WINDOW_TITLE. This means these backends have to store it in a new field in their own context.
* vd_lavc: fix avctx NULL checkswm42015-12-051-1/+4
| | | | | | If reinit after a fallback from hardware fails, this field can be NULL. The check in control() was broken due to a typo (found by Coverity), and decode() lacked the check entirely.
* vo_opengl_cb: avoid NULL pointer deref in corner caseswm42015-12-051-1/+2
| | | | Found by Coverity.
* vo_opengl: improve boundary check for polar filtersBin Jin2015-12-051-2/+2
| | | | | | | | | If the sampling point is placed diagonally, the radius difference could be as large as sqrt(2.0). And a loosened check with (radius - 1) would potentially include pixels out of the range. Fix the check to handle those corner case properly to avoid unnecessary texture lookup and improve the performance a bit.
* win32: remove dwmapi.dll dynamic loadingwm42015-12-041-34/+5
| | | | All Windows versions we support have this API.
* filter_kernels: remove redundant corner case checkBin Jin2015-12-041-1/+0
| | | | Actually, the original code would bypass some code path below.
* vo_opengl: require --enable-gpl3 for nnediwm42015-12-033-2/+31
| | | | | | | | | There are claims that nnedi3.c doesn't constitute its own new implementation, but is derived from existing HLSL or OpenCL shaders distributed under the LGPLv3 license. Until these are resolved, do the "correct" thing and require --enable-gpl3 to build nnedi.
* video: readd codec delay estimationwm42015-12-023-0/+18
| | | | | | | | | | | | | | | | | Approximately reverts commit 3ccac74d. This failed with some avi files, which do pseudo-VFR by sending packets with empty frames (or repeat frames, depending on point of view). Specifically, these packets are not 0 bytes, so they don't get skipped by libavformat, as with the usual VFR avi hack. Instead, the packet contains a VOP with vop_coded=0, so libavcodec will just return no frame. We could probably distinguish such skipped frames and delayed frames by explicitly measuring the codec delay by counting how long it takes to get the very first frame (and then treat skips as explicit drops), but we may as well simply reinstate the old code. To appease to at least one semi-broken case, do not enable this logic on the RPI, as the FFmpeg MMAL wrapper has arbitrary buffering (and MMAL itself is asynchronous).
* vo_opengl: fix backend=x11 on Intelwm42015-12-021-1/+1
| | | | "backend=x11" was resolved to x11_probe, which is unintentional.
* vo_opengl: add credits to NNEDI3 shaderBin Jin2015-12-021-0/+16
| | | | Add credits to several existing implementation of NNEDI3 shader.
* vo_opengl: enable NNEDI3 prescaler on OpenGL ES 3.0Bin Jin2015-12-023-14/+19
| | | | | | | | | | | | | | It turns out that both UBO and intBitsToFloat() are supported in OpenGL ES 3.0[1][2], enable them so that NNEDI3 prescaler can be used in a wider range of backends. Also fixes some implicit int-to-float conversions so that the shader actually compiles on GLES. Tested on Linux desktop (nvidia 358.16) with "es" sub-option. [1]: https://www.khronos.org/opengles/sdk/docs/man3/html/glGetUniformBlockIndex.xhtml [2]: https://www.khronos.org/opengles/sdk/docs/manglsl/docbook4/xhtml/intBitsToFloat.xml
* vo_opengl_cb: pass mpv_global to gl_videowm42015-11-301-1/+1
| | | | | | | | I guess gl_video->global was originally meant to be optional, but now it crashes in some newer code with vo_opengl_cb, which tries to init it with this field set to NULL (because normally it's not needed). Probably fixes #2542.
* vo: cosmetics: split functionwm42015-11-291-41/+56
| | | | | Split two huge chunks from the update_vsync_timing_after_swap() function. There should be no functional changes.
* vo: make using estimated FPS more conservativewm42015-11-291-0/+6
| | | | | | | | | | Don't use the average FPS if there are likely skipped vsyncs. Note that we don't use the normal skip detection, as it is unreliable if the real and assumed display FPS differ too much. The normal skip detection is still in place as it's more reliable in the case when vsync jitters much, but the display FPS is relatively exact. Further improvement over commit 41f2c653.
* vo: remove redundant and broken codewm42015-11-291-2/+0
| | | | This was stupid.
* vo_opengl: make tscale=mitchell:tscale-clamp the defaultwm42015-11-291-2/+4
| | | | Looks better than "oversample". tscale-clamp suggested by haasn.
* vo_opengl: warn if interpolation is enabled, but not display-syncwm42015-11-281-0/+10
| | | | | | | Try to avoid user confusion. Reading the global options in this place is a pretty disgusting hack, but it's still the most robust way.
* vo: report when switching back to system-reported FPS toowm42015-11-281-4/+11
| | | | | | Instead of just when switching away from it. Further improvement over commit 41f2c653.
* vo: wait longer before abandoning system-reported display-fpswm42015-11-281-1/+4
| | | | Further improvement over commit 41f2c653.
* vo_opengl: fix interpolation with display-syncwm42015-11-282-12/+9
| | | | | | | | | | | | | | | | | | | | At least I hope so. Deriving the duration from the pts was not really correct. It doesn't include speed adjustments, and becomes completely wrong of the user e.g. changes the playback speed by a huge amount. Pass through the accurate duration value by adding a new vo_frame field. The value for vsync_offset was not correct either. We don't need the error for the next frame, but the error for the current one. This wasn't noticed because it makes no difference in symmetric cases, like 24 fps on 60 Hz. I'm still not entirely confident in the correctness of this, but it sure is an improvement. Also, remove the MP_STATS() calls - they're not really useful to debug anything anymore.
* vo: change vo_frame field unitswm42015-11-273-9/+6
| | | | | | | This was just converting back and forth between int64_t/microseconds and double/seconds. Remove this stupidity. The pts/duration fields are still in microseconds, but they have no meaning in the display-sync case (also drop printing the pts field from opengl/video.c - it's always 0).
* vo: switch back to system-reported display FPS if possiblewm42015-11-271-8/+10
| | | | | | If we switched away from the system FPS, we were remaining in this mode ssentially forever. There's no reason to do so; switch back if the estimated FPS gets worse again. Improvement over commit 41f2c653.
* vo: factor redundant timer callswm42015-11-271-3/+4
| | | | Call it once instead of 3 times.
* vo: fix audio-timing framedrop regressionswm42015-11-271-4/+5
| | | | | | | | | | | | | | Commit 12eb8b2d accidentally disabled framedropping in the audio timing case. It tried to replace the last_flip field with the prev_vsync one, which didn't work because prev_sync is reset to 0 if the timing code is used. Fix it by always setting it properly. This field must (or should) be reinitialized to something sensible when switching to display sync timing mode; since prev_vsync is not reset anymore, the check when to reinitialize this field has to be adjusted as well. It's a bit weird that update_vsync_timing_after_swap() now does some minor work for timing mode too, but I guess it's ok, if only to avoid additional fields and timer calls.
* vo: disregard system-reported display FPS if it's too imprecisewm42015-11-271-13/+42
| | | | | | | | | | | | If the system-reported display FPS (returned by the VO backends, or forced with --display-fps) is too imprecise (deviating frame duration by more than 1%). This works if the display FPS is off by almost 1 (typical for old/bad/broken OS APIs). Actually it even works if the FPs is completely wrong. Is it a good idea? Probably not. It might be better to only output a warning message. But unless there are reports about it going terribly wrong, I'll go with this for now.
* vo: improve vsync delay detectionwm42015-11-271-9/+15
| | | | | | | Actually I'm not content with the detection added in commit 44376d2d. It triggers too often if vsync is very jittery. It's easy to avoid this: we add more samples to the detection by reusing the drift computation loop. If there's a significant step in the drift, we consider it a drop.
* w32_common: implement icc-profile-autoJames Ross-Gowan2015-11-261-7/+50
| | | | | | | | | | | | This adds basic support for ICC profiles. Per-monitor profiles are supported. WCS profiles are not supported, but there is an API for converting WCS profiles to ICC, so they might be supported in future. I'm just not sure if anyone actually uses them. Reloading the ICC profile when it's changed in the control panel is also not supported. This might be possible by using the WCS APIs and watching the registry for changes, but there is no official API for it, and as far as I can tell, no other Windows programs can do it.
* vo: smooth out reported vsync timewm42015-11-251-18/+23
| | | | | | | | | | Return the estimated/ideal flip time to the timing logic (meaning vo_get_delay() returns a smoothed out time). In addition to this add some lame but working drift compensation. (Useful especially if the display FPS is wrong by a factor such as 1.001.) Also remove some older leftovers. The vsync_interval_approx and last_flip fields are redundant or unneeded.
* vo: add new frame drop detectionwm42015-11-251-0/+15
| | | | | | | | For the vo-delayed-frame-count property. Slightly less dumb than the previous one (which was removed earlier), but still pretty dumb. But this also seems to be relatively robust, even with strong vsync jittering.
* vo: do not use display FPS for framedropwm42015-11-251-38/+2
| | | | | | | This logic was kind of questionable anyway, and --display-sync should give much better results. (I would even go as far as saying that the FPS-dependent framedrop code made things worse in some situations. Not all, though.)
* vo_opengl: disable interpolation without display-syncwm42015-11-254-33/+10
| | | | | Without display-sync mode, our guesses wrt. vsync phase etc. are much worse, and I see no reason to keep the complicated "vsync_timed" code.
* command, vo: add estimated-display-fps propertywm42015-11-252-0/+79
| | | | | | | | | | This is simply the average refresh rate. Including "bad" samples is actually an advantage, because the property exists only for informational purposes, and will reflect problems such as the driver skipping a vsync. Also export the standard deviation of the vsync frame duration (normalized to the range 0-1) as vsync-jitter property.
* vo_rpi: set aspect ratiowm42015-11-251-5/+8
| | | | | Otherwise, the MMAL output component will letter-box the video within the specified dest_rect while keeping square pixels.
* vo_rpi: log subtitle render timewm42015-11-251-0/+4
|
* vo_rpi: add an option to disable OSDwm42015-11-251-19/+25
| | | | | | The OSD takes up an entire fullscreen dispmanx layer. Although the GPU should be able to handle it (possibly even without any disadvantages), it'll still be useful for debugging performance issues.
* vo_opengl: win32: test for exclusive modeJames Ross-Gowan2015-11-263-0/+129
| | | | | | | | | | This is a hack, but unfortunately the DwmGetCompositionTimingInfo heuristic does not work in all cases (with multiple-monitors on Windows 8.1 and even with a single monitor in Windows 10.) See the comment in mp_w32_is_in_exclusive_mode() for more details. It should go without saying that if any better method of doing this reveals itself, this hack should be dropped.
* vo_opengl: angle: don't load libGLESv2.dllJames Ross-Gowan2015-11-261-17/+1
| | | | | ANGLE has EGL_KHR_get_all_proc_addresses, so all GLES core functions can be queried with eglGetProcAddress.
* vo: remove VOCTRL_GET_RECENT_FLIP_TIMEwm42015-11-234-19/+1
| | | | | | | | | | | It doesn't have any real purpose anymore. Up until now, it was still implemented by vo_wayland, but since we changed how the frame callbacks work, even that appears to be pointless. Originally, the plan was to somehow extend this mechanism to all backends and to magically fix frame scheduling, but since we can't hope for proper mechanisms even on wayland, this idea looks way less interesting.
* dxva2: reject 10 bit HEVCwm42015-11-231-0/+4
| | | | | | | | | 10 bit HEVC would require DXVA2_ModeHEVC_VLD_Main10, and most a different surface type (judging by lavfsplitter source code, both P010 and P016 would work). Since I'm unable to test this stuff, exclude 10 bit for now. See #2516.
* win32: don't show progress indicator in idle modeJames Ross-Gowan2015-11-232-5/+13
|
* vo_opengl: fix superxbr on GLESwm42015-11-211-6/+6
| | | | Well, not that anyone does or should care.
* vo_opengl: angle: allow using D3D9 backendwm42015-11-211-22/+31
| | | | | | | | | | | | | | The D3D9 backend does not support GLES 3, which makes it pretty useless. But it still might be a legitimate replacement of vo_direct3d.c on Windows 7 machines. Note that we could just use: eglGetDisplay(EGL_D3D11_ELSE_D3D9_DISPLAY_ANGLE) But for now I'll leave the old code. Maybe this can exclude use of software rendering backends (EGL_PLATFORM_ANGLE_DEVICE_TYPE_WARP_ANGLE). Since I'm not sure, I won't touch it.
* vo_opengl: use ANGLE by default if available (except for "hq" preset)wm42015-11-213-11/+15
| | | | | | | | | Running mpv with default config will now pick up ANGLE by default. Since some think ANGLE is still not good enough for hq features, extend the "es" option to reject GLES backends, and add to to the opengl-hq preset. One consequence is that mpv will by default use libswscale to convert 10 bit video to 8 bit, before it reaches the VO.
* vo_opengl: enable dumb-mode automatically if possiblewm42015-11-191-6/+44
| | | | | | | | | | | | | | | I decided that I actually can't stand how vo_opengl unnecessarily puts the video through 3 shader stages (instead of 1). Thus, what was meant to be a fallback for weak OpenGL implementations, the dumb-mode, now becomes default if the user settings allow it. The code required to check for the settings isn't so wild, so I guess it's manageable. I still hope that one day, our rendering logic can generate ideal shader stages for this case too. Note that in theory, dumb-mode could be reenabled at runtime due to a color management 3D LUT being set, so a separate dumb_mode field is required. The dumb-mode option can't just be overwritten.
* vo_opengl: support 3D textures on ANGLEwm42015-11-192-3/+13
| | | | | | | Unfortunately, color management can still not work, because no GLES version specified so far support fixed-point 16 bit textures. Maybe we could use integer textures, but these don't support filtering. Using float textures would be another possibility.
* vo_opengl: switch FBO format on GLESwm42015-11-191-5/+11
| | | | | GL_RGB10_A2 is the best fixed-point format we can get on GLES/ANGLE for now. (Unless we somehow switch to non-normalized integer textures.)
* vo_opengl: make 1D textures completely optionalwm42015-11-192-5/+6
| | | | | | | | Polar scalers use 1D textures, because they're slightly faster on some GPUs than 2D textures. But 2D textures work too, so add support for them. Allows using these scalers with ANGLE.
* vo_opengl: fix some more GLES shader issueswm42015-11-191-6/+6
| | | | | | Just like commit f9a2fc59. There are probably some more such cases. The vec2 constructor calls are probably fine, but don't bother with confusing inconsistencies.
* vo_opengl: create FBOs in a more GLES conformant waywm42015-11-191-2/+40
| | | | | | | | | | | | | | | While desktop GL's glTexImage2D() essentially accepts anything, GLES is much stricter. The combination of allowed formats/types/internal formats is exactly specified. The GLES 3.0.4 specification lists them in table 3.2. (The ANGLE API validation code references this table.) The table could probably be extended into a general declarative table about GL formats covering other uses, but this would be a big non-trivial project, so don't bother and accept a minor degree of duplication with other tables. Note that the format and type do (or should) not matter here, because no image data is transferred to the GPU.
* vo_opengl: better check for float texture supportwm42015-11-191-7/+8
| | | | | | We don't only need float textures for advanced scaling - we also need them to be filterable with GL_LINEAR. On GLES, this is not supported until GLES 3.1, but some implementation expose them with extensions.
* vo_opengl: check shader string before sscanfing itKevin Mitchell2015-11-191-1/+1
|
* vo_opengl: add missing log newlineKevin Mitchell2015-11-191-1/+1
|
* vo_opengl: add RGBA8 framebuffer format, enable non-dumb mode for ES 3.0wm42015-11-191-1/+2
| | | | | | | This makes advanced scaling sort-of work for GLES 3.0 (on ANGLE). It's still not very advisable, as 8 bits might not be enough to avoid debanding. (Ironically, the debanding filter can be enabled, and does not raise any GL errors - but probably doesn't do anything useful.)
* vo_opengl: don't mix floats and integers in dither shaderwm42015-11-191-3/+3
| | | | | Some GLSL dialects (GLSL ES 3.00) do not have such implicit conversions. They have to be made floats for the sake of the shader compiler.
* vo_opengl: fix ANGLE GLES3 modeJames Ross-Gowan2015-11-192-2/+9
| | | | | | Turns out glGetTexLevelParameter, which is missing in ANGLE, is a GLES3.1 function. Removing it from the list of core GLES3 functions makes ANGLE work in GLES3 mode.
* x11: request bypassing compositorwm42015-11-181-0/+6
| | | | | | | Maybe this is a good idea. Also add an option to disable it again, for the sake of testing. Fixes #2502.
* vo_opengl: add initial ANGLE supportJames Ross-Gowan2015-11-182-0/+219
| | | | |