summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* subprocess-win: fix swprintf usageJames Ross-Gowan2017-07-291-1/+2
| | | | | | | The count parameter refers to the number of wide-characters to write to the buffer (including the terminating NUL character, which is always added,) not the number of bytes. See C99 7.24.2.3 or https://msdn.microsoft.com/en-us/library/ybk95axf.aspx
* appveyor: use a clean %PATH%James Ross-Gowan2017-07-281-0/+2
| | | | | | | AppVeyor build workers have Git for Windows on the %PATH%, which includes some MSYS2 binaries. Having multiple MSYS2 installations on the %PATH% causes cygheap errors, so remove them and make sure %PATH% only has stuff we need.
* subprocess-win: don't leak pipe handle on errorJames Ross-Gowan2017-07-281-1/+3
|
* vo_opengl: support loading custom user texturesNiklas Haas2017-07-277-117/+418
| | | | | | | | | | | Parsing the texture data as raw strings makes the textures the most portable and self-contained. In order to facilitate different types of shaders, the parse_user_shader interaction has been changed to instead have it loop through blocks and call the passed functions for each valid block parsed. This is more modular and also cleaner, with better code separation. Closes #4586.
* vo_opengl: slightly refactor user_shaders codeNiklas Haas2017-07-273-73/+53
| | | | | | | | | | | | | | - Each struct tex_hook now stores multiple hooks, this allows us to avoid the awkward way of the current code has to add the same pass multiple times. - As a consequence, SHADER_MAX_HOOKS was split up into SHADER_MAX_PASSES (number of tex_hooks) and SHADER_MAX_HOOKS (number of hooked textures per tex_hook), and both numbers decreased correspondingly. - Instead of having a weird free() callback, we can just leverage talloc's recursive free behavior. The only user is the user shaders code anyway.
* vo_opengl: tone map on the maximum signal componentNiklas Haas2017-07-271-19/+25
| | | | | | | | | | This actually makes sure we don't decolor due to clipping even when the signal itself exceeds the luma by a significant factor, which was pretty common for saturated blues (and to a lesser degree, reds) - most noticeable in skies etc. This prevents the turn-the-sky-cyan effect of mobius tone mapping, and should also improve the other tone mapping modes in quality.
* vo_opengl: fix mpgl_caps bit checkNiklas Haas2017-07-271-1/+1
| | | | | As pointed out by @bjin, this would match if _any_ of the reqs are set. Need to test for explicit equality.
* vo_opengl: start work on rendering API abstractionwm42017-07-268-175/+838
| | | | | | | | | | | | | | | | | | | | | | This starts work on moving OpenGL-specific code out of the general renderer code, so that we can support other other GPU APIs. This is in a very early stage and it's only a proof of concept. It's unknown whether this will succeed or result in other backends. For now, the GL rendering API ("ra") and its only provider (ra_gl) does texture creation/upload/destruction only. And it's used for the main video texture only. All other code is still hardcoded to GL. There is some duplication with ra_format and gl_format handling. In the end, only the ra variants will be needed (plus the gl_format table of course). For now, this is simpler, because for some reason lots of hwdec code still requires the GL variants, and would have to be updated to use the ra ones. Currently, the video.c code accesses private ra_gl fields. In the end, it should not do that of course, and it would not include ra_gl.h. Probably adds bugs, but you can keep them.
* vo_opengl: describe the texture uploading modeNiklas Haas2017-07-261-1/+2
| | | | | Be a bit more transparent here, which is especially helpful when people are sending me screenshots of stats pages.
* vo_opengl: check against shmem limitsNiklas Haas2017-07-266-26/+54
| | | | | | The radius check was not strict enough, especially not for all platforms. To fix this, actually check the hardware capabilities instead of relying on a hard-coded maximum radius.
* vo_opengl: fix image uniforms for older OpenGLJames Ross-Gowan2017-07-261-0/+2
| | | | | This explicitly enables the GL_ARB_shader_image_load_store extension, which seems to fix compute shaders for Intel/GL 3.0.
* vo_opengl: cosmetic changeNiklas Haas2017-07-251-8/+6
|
* subprocess-win: remove VLA usageJames Ross-Gowan2017-07-261-2/+4
| | | | This only ever waits on four handles at most anyway.
* vo_opengl: add PRINTF_ATTRIBUTE to gl_sc_ssboNiklas Haas2017-07-251-1/+1
| | | | | Doesn't uncover any bugs, but apparently we're getting in the habit of this anyway.
* vo_opengl: kill off FBOTEX_COMPUTE againNiklas Haas2017-07-253-26/+16
| | | | | | | | | | | The textures not having an FBO actually caused regressions when trying to render the subtitles on top of this texture (--blend-subtitles), which still relied on an FBO. So just kill off the logic entirely. Why worry about a single FBO wasted when we're allocating like 10 anyway. Fixes #4657.
* vo_opengl: fix incoherent SSBO usageNiklas Haas2017-07-251-0/+1
| | | | | | | According to the OpenGL spec, atomic access to SSBO variables is *not* guaranteed to be coherent, even when reusing the same SSBO attached to the same shader across different frames. So we actually need a glMemoryBarrier here, at least in theory.
* vo_opengl: cosmetic fixNiklas Haas2017-07-251-2/+2
|
* vo_opengl: fix incoherent texture usageNiklas Haas2017-07-252-0/+5
| | | | | | | | | This bug slipped past my attention because nvidia ignores memory barriers, but this is not necessarily always the case. Since image_load_store is incoherent (specifically, writing to images from compute shaders is incoherent) we need to insert a memory barrier to make it coherent again. Since we only care about texture fetches, that's the only barrier we need.
* vo_opengl: adjust the rules for linearizationNiklas Haas2017-07-242-22/+45
| | | | | | | | | | | | | | | | | | Two changes, compounded into one since they affect the same logic: 1. Never use linearization for HDR downscaling 2. Always use linearization for interpolation Instead of fixing p->use_linear at the beginning of pass_render_frame, we flip it on "dynamically" as needed. I plan on killing this p->use_linear frame (along with other per-pass metadata) and moving them into their own struct for tracking the "current" state of the video, but that's a separate/upcoming refactor. As a small bonus, reduce some code duplication in the interpolation logic. Fixes #4631
* vo_opengl: enable compute shader for mesaBin Jin2017-07-255-4/+26
| | | | | | | | | Mesa 17.1 supports compute shader but not full specs of OpenGL 4.3. Change the code to detect OpenGL extension "GL_ARB_compute_shader" rather than OpenGL version 4.3. HDR peak detection requires SSBO, and polar scaler requires 2D array extension. Add these extensions as requirement as well.
* manpage: expand --hwdec warningsNiklas Haas2017-07-241-17/+36
| | | | | | | | | | | | | I've found more test cases where hwdec=cuda shits itself, even hwdec=cuda-copy. So the whole “copyback is no worse than swdec” is simply not true. Also, in the light of 10 bit media files and APIs silently truncating to 8 bit, the warnings need to be generalized a bit. It's no longer safe to say that “doesn't convert to RGB” means “perfect playback”. I've also added a very strong disclaimer to the whole hwdec scenario clarifying why hwdec is usually a bad idea unless absolutely needed, because I've seen issue after issue that is resolved by disabling hwdec.
* vo_opengl: support user compute shadersNiklas Haas2017-07-244-0/+23
| | | | | These are identical to regular fragment shader hooks, but with extra metadata indicating the preferred block size.
* vo_opengl: implement compute shader based EWA kernelNiklas Haas2017-07-243-7/+81
| | | | | | | | | | | This performs almost 50% faster on my machine (!!), from 4650μs down to about 3176μs for ewa_lanczossharp. It's possible we could use a similar approach to speed up the separable scalers, although with vastly simpler code. For separable scalers we'd also have the additional huge benefit of only needing padding in one direction, so we could potentially use a big 256x1 kernel or something to essentially compute an entire row at once.
* vo_opengl: support HDR peak detectionNiklas Haas2017-07-2410-22/+201
| | | | | | | | | | | | | | This is done via compute shaders. As a consequence, the tone mapping algorithms had to be rewritten to compute their known constants in GLSL (ahead of time), instead of doing it once. Didn't affect performance. Using shmem/SSBO atomics in this way is extremely fast on nvidia, but it might be slow on other platforms. Needs testing. Unfortunately, setting up the SSBO still requires OpenGL calls, which means I can't have it in video_shaders.c, where it belongs. But I'll defer worrying about that until the backend refactor, since then I'll be breaking up the video/video_shaders structure anyway.
* vo_opengl: support compute shadersNiklas Haas2017-07-247-100/+317
| | | | | | | | These can either be invoked as dispatch_compute to do a single computation, or finish_pass_fbo (after setting compute_size_minimum) to render to a new texture using a compute shader. To make this stuff all work transparently, we try really, really hard to make compute shaders as identical to fragment shaders as possible in their behavior.
* vo_opengl: cut down on FBOTEX_FUZZY abuseNiklas Haas2017-07-241-4/+2
| | | | | | | | Don't use FBOTEX_FUZZY where the FBO is sized according to p->texture_w/h, since this changes infrequently (and when it does, we need to reset everything anyway). No real reason to make this change other than that it possibly prevents nasty surprises in the future, so I feel more comfortable about it.
* build: warn against VLAwm42017-07-241-1/+2
| | | | | Although C99 supports them, they are optional in C11, and we don't like/use them anyway.
* common, vo_opengl: add/use helper for formatted strings on the stackwm42017-07-244-10/+22
| | | | | | | | | | | Seems like I really like this C99 idiom. No reason not to generalize it do snprintf(). Introduce mp_tprintf(), which basically this idiom to snprintf(). This macro looks like it returns a string that was allocated with alloca() on the caller site, except it's portable C99/C11. (And unlike alloca(), the result is valid only within block scope.) Use it in 2 places in the vo_opengl code. But it has the potential to make a whole bunch of weird looking code look slightly nicer.
* vo_opengl: check format on some printf-like callswm42017-07-242-3/+5
| | | | Fix 1 incorrect use.
* vo_opengl: add direct rendering supportwm42017-07-2414-4/+448
| | | | | | | | | | | | | | | | | | | | Can be enabled via --vd-lavc-dr=yes. See manpage additions for what it does. This reminds of the MPlayer -dr flag, but the implementation is completely different. It's the same basic concept: letting the decoder render into a GPU buffer to avoid a copy. Unlike MPlayer, this doesn't try to go through filters (libavfilter doesn't support this anyway). Unless a filter can work in-place, DR will be silently disabled. MPlayer had very complex semantics about buffer types and management (which apparently nobody ever understood) and weird restrictions that mostly limited it to mpeg2 style codecs. The mpv code does not do any of this, and just lets the decoder allocate an arbitrary number of untyped images. (No MPlayer code was used.) Parts of the code based on work by atomnuker (starting point for the generic code) and haasn (some GL definitions, some basic PBO code, and correct fencing).
* mp_image: expose some image allocation code as helpers, refactorwm42017-07-232-20/+129
| | | | | | | Refactor the image allocation code, and expose part of it as helper code. This aims towards allowing callers to easily allocate mp_image references from custom-allocated linear buffers. This is exposing only as much as what should be actually required.
* mp_image_pool: disallow adding read only frameswm42017-07-231-2/+6
| | | | | | Remove the feature of adding read-only frames to mp_image_pool_add(). This makes no sense, because an image pool is an allocator, and must always return writable images. Also check these assumptions earlier.
* vo_opengl: osd: remove stale declarationwm42017-07-231-1/+0
| | | | Was missed in the previous changes.
* vo_opengl: add printf format checking to pass_describe()wm42017-07-221-0/+1
|
* vo_opengl: make VAO helper private, remove old VAO mechanismwm42017-07-222-44/+17
| | | | The struct describing vertex attributes is still public, of course.
* vo_opengl: osd: use new VAO mechanismwm42017-07-223-49/+43
| | | | | | | In addition to using the new VAO mechanism introduced in the previous commit, this tries to keep the OSD code self-contained. This doesn't work all too well (because of the pass and CMS stuff), but it's still better than before.
* vo_opengl: add mechanism to create/cache VAO on the flywm42017-07-223-19/+64
| | | | | | This removes VAO handling from video.c. Instead the shader cache will create the VAO as needed. The consequence is that this creates a VAO per shader, which might be a bit wasteful, but doesn't matter anyway.
* vo_opengl: osd: refactor and simplifywm42017-07-225-43/+34
| | | | | | | | Reduce this to 1 draw call per OSD pass. This removes the need for some annoying special handling regarding 3D video support (we supported duplicating the OSD/subtitles for side-by-side 3D output etc.). Remove the unneeded texture sampler uniform thing.
* options: drop --video-aspect-method=hybridwm42017-07-215-34/+6
| | | | | | | | | Remove this code because it could be argued that it contains GPL-only code (see commit 642e963c860 for details). The remaining aspect methods appear to work just as well, are potentially more compatible to other players, and the code becomes much simpler.
* client API: drop some compatibility handlingwm42017-07-212-13/+5
| | | | See commit e4bc563fd2dcf for more information.
* input: drop deprecated "osd" commandwm42017-07-214-26/+1
| | | | | Complicated situation due to changes by GPL-only author, but also unnecessary due to newer mechanisms.
* options: kill --field-dominancewm42017-07-217-31/+4
| | | | GPL-only author, no chance of relicensing.
* demux_lavf: don't free AVFormatContext.key fieldwm42017-07-211-2/+0
| | | | We don't even set it anymore. This really should be up to libavformat.
* ao_oss: fix a dumb calculationwm42017-07-211-2/+3
| | | | | | | period_size used the wrong unit, and even if the unit had been correct, was assigned the wrong value. Probably fixes #4642.
* manpage: fix minor spelling mistake in mpv.rstJames Cowgill2017-07-191-1/+1
| | | | Found by https://lintian.debian.org/
* travis: trigger website rebuild on VERSION changes tooRicardo Constantino2017-07-191-1/+1
| | | | Needed to update the stable manual if no DOCS were changed.
* Update VERSIONMartin Herkt2017-07-181-1/+1
|
* Release 0.26.0v0.26.0Martin Herkt2017-07-182-1/+144
|
* csputils: fix mp_colorspace_equal missing fieldNiklas Haas2017-07-181-0/+1
| | | | Forgot to equality test for mp_colorspace.light
* manpage: upcase JavaScript for section title case consistency.torque2017-07-171-1/+1
|
* vo_opengl: avoid constant divisionsNiklas Haas2017-07-172-40/+42
| | | | | | | These are apparently expensive on some drivers which are not smart enough to turn x/42 into x*1.0/42. So, do it for them. My great test framework says it's okay
* demux_disc: fix bluray subtitle language retrievalwm42017-07-161-4/+4
| | | | | | | | | It seems like adjusting the raw stream ID should be done only for DVD. Otherwise, getting the subtitle language for Bluray breaks. Untested. Regression since fb9a32977d6. Fixes #4611 (probably).
* vo_opengl: styleNiklas Haas2017-07-161-1/+1
| | | | Use uintptr_t instead of size_t. Shouldn't matter, but is cleaner.
* vo_opengl: use MP_ALIGN_UP instead of FFALIGNNiklas Haas2017-07-161-1/+1
| | | | Consistency/style
* vo_opengl: use glBufferSubData instead of glMapBufferRangeNiklas Haas2017-07-164-27/+10
| | | | | | | | | | | | | | | | | | | | Performance seems pretty much unchanged but I no longer get nasty spikes on NUMA systems, probably because glBufferSubData runs in the driver or something. As a simplification of the code, we also just size the PBO to always have the full size, even for cropped textures. This seems slower but not by relevant amounts, and only affects e.g. --vf=crop. It also slightly increases VRAM usage for textures with big strides. This new code path is especially nice because it no longer depends on GL_ARB_map_buffer_range, and no longer uses any functions that can possibly fail, thus simplifying control flow and seemingly deprecating the manpage's claim about possible image corruption. In theory we could also reduce NUM_PBO_BUFFERS since it doesn't seem like we're streaming uploads anyway, but leave it in there just in case some drivers disagree...
* ytdl_hook: add a header to support geo-bypassJagannathan Tiruvallur Eachambadi2017-07-161-1/+1
| | | | | | youtube-dl supports bypassing some geographic restrictions by setting X-Forwarded-For header when used with geo-bypass and geo-bypass-country.
* osd_libass: avoid libass warnings if scripts set ASS text earlywm42017-07-162-19/+30
| | | | | | | | | | | | | | | | Lua scripts can call osd_set_external() early (before the VO window is created and obj->vo_res is filled), in which case the PlayResX field would be set to nonsense, and libass would print a pointless warning. There's an easy and a hard fix: either just go on and pass dummy values to libass (basically like before, just clamp them to avoid the values which make libass print the warning). Or attempt to update the PlayRes field to correct values on rendering (since at rendering time, you always know the screen size and the correct values). Do the latter. Since various things use PlayRes for scaling things, this might still not be fully ideal. This is a general problem with the async scripting interface.
* Replace remaining avcodec_close() callswm42017-07-166-27/+7
| | | | | | | | This API isn't deprecated (yet?), but it's still inferior and harder to use than avcodec_free_context(). Leave the call only in 1 case in af_lavcac3enc.c, where we apparently seriously close and reopen the encoder for whatever reason.
* vo_opengl: update BufferData usage hintsNiklas Haas2017-07-151-2/+11
| | | | | | | | | | | | | | | STREAM is better than DYNAMIC because we're only using it once per frame. As for COPY vs DRAW, that was pretty much incorrect to begin with - but surprisngly, COPY is actually faster (sometimes significantly so, e.g. on my NUMA system). After testing, the best I can gather is that it has to do with the fact that COPY requires fewer redundant memcpy()s, and also 3x reduce RAM bandwidth (in theory). Anyway, that bit shouldn't introduce any regressions, it's just a documentation update. Maybe I'll change my mind about the comment again the future, it's really hard to tell. Vulkan, please save us!
* vo_opengl: coalesce intra-plane PBOsNiklas Haas2017-07-152-14/+17
| | | | | | | | | | | | | | Instead of allocating three PBOs and cycling through them, we allocate one PBO that's three times as large, and cycle through the subregion offsets. This results in arguably simpler code and faster initialization performance. Especially for 4K textures, initializing PBOs can take quite some time (e.g. 180ms -> 110ms). For 1080p, it's more like 66ms -> 52ms for me. The alignment to 4096 is completely unnecessary by spec, but we do it anyway just for peace of mind.
* img_format: fix a commentwm42017-07-151-3/+2
| | | | | This was changed a while ago. Part of it might still apply to the old D3D hwaccel glue code, though.
* vo_opengl: generalize --scale-clamp etc.Niklas Haas2017-07-126-11/+18
| | | | | This can help fight ringing without completely killing it, thus providing a middle-ground between ringing and aliasing.
* vo_opengl: remove redundant gl_video_setup_hooks callNiklas Haas2017-07-121-1/+0
| | | | | | | | This is unnecessary to call from gl_video_resize, because the hooks only (possibly) change when the actual vo_opengl options change. This used to be required back when mpv still had prescaling built in, but since that was all moved to user shaders and the code removed, this is a left-over artifact.
* player: change default section when loading encoding-profiles.confwm42017-07-122-5/+9
| | | | | | | </