summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* options: slightly better option update mechanismwm42016-09-191-0/+1
| | | | | | | | | | | | | | Extend the flag-based notification mechanism that was used via M_OPT_TERM. Make the vo_opengl update mechanism use this (which, btw., also fixes compilation with OpenGL renderers forcibly disabled). While this adds a 3rd mechanism and just seems to further the chaos, I'd rather have a very simple mechanism now, than actually furthering the mess by mixing old and new update mechanisms. In particular, we'll be able to remove quite some property implementations, and replace them with much simpler update handling. The new update mechanism can also more easily refactored once we have a final mechanism that handles everything in an uniform way.
* displayconfig: treat a refresh rate of 1 as invalidJames Ross-Gowan2016-09-181-2/+8
| | | | Found in Windows 8.1/VirtualBox.
* options: simplify M_OPT_EXITwm42016-09-172-3/+3
| | | | | | | | | | | | | There were multiple values under M_OPT_EXIT (M_OPT_EXIT-n for n>=0). Somehow M_OPT_EXIT-n either meant error code n (with n==0 no error?), or the number of option valus consumed (0 or 1). The latter is MPlayer legacy, which left it to the option type parsers to determine whether an option took a value or not. All of this was changed in mpv, by requiring the user to use explicit syntax ("--opt=val" instead of "-opt val"). In any case, the n value wasn't even used (anymore), so rip this all out. Now M_OPT_EXIT-1 doesn't mean anything, and could be used by a new error code.
* vo_opengl: don't pass negative height to overlay_adjust()wm42016-09-161-1/+1
| | | | | | Negative height is used to signal a flipped framebuffer. There's absolutely no reason to pass this down to overlay_adjust(), and only requires implementers to deal with an additional special-case.
* player: use better way to wait for input and dispatching commandswm42016-09-161-0/+2
| | | | | | | | | | | | | | | | | | | Instead of using input_ctx for waiting, use the dispatch queue directly. One big change is that the dispatch queue will just process commands that come in (e.g. from client API) without returning. This should reduce unnecessary playloop excutions (which is good since the playloop got a bit fat from rechecking a lot of conditions every iteration). Since this doesn't force a new playloop iteration on every access, this has to be enforced manually in some cases. Normal input (via terminal or VO window) still wakes up the playloop every time, though that's not too important. It makes testing this harder, though. If there are missing wakeup calls, it will be noticed only when using the client API in some form. At this point we could probably use a normal lock instead of the dispatch queue stuff.
* player, ao, vo: don't call mp_input_wakeup() directlywm42016-09-162-6/+16
| | | | | | | | | | | | | Currently, calling mp_input_wakeup() will wake up the core thread (also called the playloop). This seems odd, but currently the core indeed calls mp_input_wait() when it has nothing more to do. It's done this way because MPlayer used input_ctx as central "mainloop". This is probably going to change. Remove direct calls to this function, and replace it with mp_wakeup_core() calls. ao and vo are changed to use opaque callbacks and not use input_ctx for this purpose. Other code already uses opaque callbacks, or has legitimate reasons to use input_ctx directly (such as sending actual user input).
* hwdec_cuda: Rename config variable to be more consistentPhilip Langdale2016-09-163-4/+4
| | | | | | 'cuda-gl' isn't right - you can turn this on without any GL and get some non-zero benefit (with the cuda-copy hwaccel). So 'cuda-hwaccel' seems more consistent with everything else.
* vo_opengl: rpi: cosmetic changewm42016-09-151-2/+2
| | | | I almost feel sorry wasting a commit on this.
* vo_opengl: fix OSD with icc-profile after previous commitwm42016-09-141-0/+2
| | | | | | This happened to break because the texture unit wasn't reset to 0, which some code expects. The OSD code in particular set the OSD texture on the wrong texture unit, with the result that OSD/OSC was not visible.
* vo_opengl: dynamically manage texture unitswm42016-09-145-30/+54
| | | | | | | | | | | | | | | | | | | | | A minor cleanup that makes the code simpler, and guarantees that we cleanup the GL state properly at any point. We do this by reusing the uniform caching, and assigning each sampler uniform its own texture unit by incrementing a counter. This has various subtle consequences for the GL driver, which hopefully don't matter. For example, it will bind fewer textures at a time, but also rebind them more often. For some reason we keep TEXUNIT_VIDEO_NUM, because it limits the number of hook passes that can be bound at the same time. OSD rendering is an exception: we do many passes with the same shader, and rebinding the texture each pass. For now, this is handled in an unclean way, and we make the shader cache reserve texture unit 0 for the OSD texture. At a later point, we should allocate that one dynamically too, and just pass the texture unit to the OSD rendering code. Right now I feel like vo_rpi.c (may it rot in hell) is in the way.
* vo_opengl: require explicit reset on shader cache after renderingwm42016-09-144-8/+30
| | | | | | | | | The caller now has to call gl_sc_reset(), and _after_ rendering. This way we can unset OpenGL state that was setup for rendering. This affects the shader program, for example. The next commit uses this to automatically manage texture units via the shader cache. vo_rpi.c changes untested.
* vo_opengl: remove a redundant glActiveTexture() callwm42016-09-141-2/+2
| | | | | This bound video textures to individual texture units - this is how it used to work long ago, but now is pointless, and maybe even dangerous.
* vo_opengl: make the number of PBOs tunableNiklas Haas2016-09-142-5/+7
| | | | | Also set the number of PBOs from 2 to 3, which should be better for pipelining. This makes it easier to add more in the future.
* vo_opengl: drm: use new EGL context creation codewm42016-09-141-42/+7
|
* vo_opengl: wayland: use new EGL context creation codewm42016-09-141-49/+8
|
* vo_opengl: EGL: dump some version infowm42016-09-141-0/+8
|
* vo_opengl: EGL: better desktop-GL context creationwm42016-09-141-19/+65
| | | | | | | | | | | | Stops Mesa from restricting us to OpenGL 3.0. It also tries to create GLES 3 contexts for drivers which do not just return a higher context when requesting GLES 2. I don't know whether this code is a good or bad idea. A not-so-good aspect is that we don't check for EGL 1.5 (or 1.4 extensions) for some of the more advanced context attributes. But EGL implementations should be able to tolerate it and return an error, and then we'd use the fallback.
* vo_opengl: EGL: silence eglBindAPI() error messagewm42016-09-131-1/+1
| | | | | It's not helpful and will be printed with EGL implementations that don't support OpenGL at all. Just shut it up.
* vo_rpi, vo_opengl: separate RPI/EGL-specific code for both VOswm42016-09-133-220/+200
| | | | | | | | | This used to be shared, but since vo_rpi is going to be removed, untangle them. There was barely any actual code shared since the recent changes anyway. As a subtle change, we also stop opening libGLESv2.so explicitly in the vo_opengl backend, and use RTLD_DEFAULT instead.
* vo_opengl: rpi: use new egl context creation helper functionwm42016-09-131-26/+13
| | | | Only for the "new" vo_opengl backend code.
* vo_x11: fix some ifdefferywm42016-09-131-2/+2
| | | | This failed to compile when xext was not available.
* vo_opengl: mali fbdev supportwm42016-09-132-0/+171
| | | | | | | | | | | | Minimal support just for testing. Only the window surface creation (including size determination) is really platform specific, so this could be some generic thing with platform-specific support as some sort of sub-driver, but on the other hand I don't see much of a need for such a thing. While most of the fbdev usage is done by the EGL driver, using this fbdev ioctl is apparently the only way to get the display resolution.
* vo_opengl: factor some EGL context creation codewm42016-09-135-74/+122
| | | | | | | Add a function to egl_helpers.c for creating an EGL context and make context_x11egl.c use it. This is meant to be generic, and should work with other windowing APIs as well. The other EGL-using code in mpv can be switched to it.
* vo_opengl: fix typo in bt.601 auto-guessing logicNiklas Haas2016-09-131-1/+1
| | | | | | | The wrong enum got copied here, so it was essentially using the transfer characteristics as the primaries (instead of the primaries), which accidentally worked fine most of the time (since the two usually coincided), but broke on weird/mistagged files.
* vo_rpi: deprecate this VOwm42016-09-122-3/+6
|
* vo: change defines to an enumwm42016-09-121-15/+17
| | | | | (They're flags, so it still doesn't make sense to actually name the enum and use it as a type.)
* vo_opengl: fix non-C11 TLS fallback for gccwm42016-09-121-1/+1
| | | | | | The consequence of this was that e.g. hardware decoding with VAAPI-EGL could sometimes not work if the compiler didn't support C11. (Although I found this one on RPI, which also uses this mechanism.)
* vo_opengl: better behavior in GL error corner caseswm42016-09-121-4/+5
| | | | | | | | | | | If the shader fails to compile, and assertion could trigger in gl_sc_gen_shader_and_reset() due to the code trying to recreate the shader every time, and re-appending the uniforms every time. Just reset the uniform array to fix this. Some disturbed GL drivers might not return anything for glGetShaderiv() if the GL state got "lost", so initialize variables just for additional robustness.
* vo_opengl: rpi: merge vo_rpi featureswm42016-09-122-20/+255
| | | | | | | | | | | Since vo_rpi is going to be deprecated, better port its features to the vo_opengl backend. The most tricky part is the fact that recreating dispmanx elements will conflict with the GL context. Fortunately, RPI's EGL support is reasonably compliant, and we can transplant the context to newly created dispmanx elements, making this much easier. This means unlike vo_rpi, the GL state will actually not be recreated.
* vo_opengl: redirect window screenshot requests to backendwm42016-09-121-5/+5
| | | | | | If the glReadPixels method is not available, let the backend do it. Useful for the next commit.
* vo_opengl: add hw overlay support and use it for RPIwm42016-09-127-2/+453
| | | | | | | | | | | This overlay support specifically skips the OpenGL rendering chain, and uses GL rendering only for OSD/subtitles. This is for devices which don't have performant GL support. hwdec_rpi.c contains code ported from vo_rpi.c. vo_rpi.c is going to be deprecated. I left in the code for uploading sw surfaces (as it might be slightly more efficient for rendering sw decoded video), although it's dead code for now.
* hwdec_cuda: Add trivial cuda-copy wrapperPhilip Langdale2016-09-112-0/+10
| | | | | | | | | The cuvid decoder already knows how to copy back to system memory if NV12 frames are requested, and this will happen if the decoder is used without the hwdec. For convenience, let's add a wrapper hwdec so people don't have to explicitly pick the cuvid decoder if they want this behaviour.
* hwdec_cuda: Implement download_image for screenshotsPhilip Langdale2016-09-101-0/+53
| | | | Data has to be copied to system memory for screenshots.
* hwdec_cuda: Use the non-deprecated CUDA-GL interop APIPhilip Langdale2016-09-101-12/+26
| | | | | | | | | | The nvidia examples use the old (as in CUDA 3.x) interop API which is deprecated, and I think not even functional on recent versions of CUDA for windows. As I was following the examples, I used this old API. So, let's update to the new API, and hopefully, it'll start working on windows too.
* vo: remove unused VOCTRL_GET_PANSCANwm42016-09-0812-25/+1
| | | | | | It was used to determine whether the VO supports VOCTRL_SET_PANSCAN. With all those changes to property semantics this became unnecessary, and its only use was dropped at some point.
* vo: don't access global options unsynchronizedwm42016-09-081-6/+10
| | | | | And since there's no proper fine-grained option change notification mechanism yet, intercept updates to "framedrop" manually.
* vo_opengl: use dedicated image unref function in config casewm42016-09-081-1/+1
| | | | | | | Just another corner-caseish potential issue. Unlike unreffing the image manually, unref_current_image() also takes care of properly unmapping hwdec frames. (The corner-case part of this is that it's probably never mapped at this point, but it's apparently not entirely guaranteed.)
* vo_opengl: simplify a conditionwm42016-09-081-2/+1
| | | | | | | | | | | The " || vimg->mpi" part virtually never seems to trigger, but on the other hand could possibly create unintended corner cases (for example by trying to upload a NULL image, which would then be marked as an error and render a blue screen). I guess it's a leftover from over times, where a NULL image meant "redraw the current frame". This is now handled by actually passing along the current frame.
* hwdec/opengl: Add support for CUDA and cuvid/NvDecodePhilip Langdale2016-09-087-1/+421
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Nvidia's "NvDecode" API (up until recently called "cuvid" is a cross platform, but nvidia proprietary API that exposes their hardware video decoding capabilities. It is analogous to their DXVA or VDPAU support on Windows or Linux but without using platform specific API calls. As a rule, you'd rather use DXVA or VDPAU as these are more mature and well supported APIs, but on Linux, VDPAU is falling behind the hardware capabilities, and there's no sign that nvidia are making the investments to update it. Most concretely, this means that there is no VP8/9 or HEVC Main10 support in VDPAU. On the other hand, NvDecode does export vp8/9 and partial support for HEVC Main10 (more on that below). ffmpeg already has support in the form of the "cuvid" family of decoders. Due to the design of the API, it is best exposed as a full decoder rather than an hwaccel. As such, there are decoders like h264_cuvid, hevc_cuvid, etc. These decoders support two output paths today - in both cases, NV12 frames are returned, either in CUDA device memory or regular system memory. In the case of the system memory path, the decoders can be used as-is in mpv today with a command line like: mpv --vd=lavc:h264_cuvid foobar.mp4 Doing this will take advantage of hardware decoding, but the cost of the memcpy to system memory adds up, especially for high resolution video (4K etc). To avoid that, we need an hwdec that takes advantage of CUDA's OpenGL interop to copy from device memory into OpenGL textures. That is what this change implements. The process is relatively simple as only basic device context aquisition needs to be done by us - the CUDA buffer pool is managed by the decoder - thankfully. The hwdec looks a bit like the vdpau interop one - the hwdec maintains a single set of plane textures and each output frame is repeatedly mapped into these textures to pass on. The frames are always in NV12 format, at least until 10bit output supports emerges. The only slightly interesting part of the copying process is that CUDA works by associating PBOs, so we need to define these for each of the textures. TODO Items: * I need to add a download_image function for screenshots. This would do the same copy to system memory that the decoder's system memory output does. * There are items to investigate on the ffmpeg side. There appears to be a problem with timestamps for some content. Final note: I mentioned HEVC Main10. While there is no 10bit output support, NvDecode can return dithered 8bit NV12 so you can take advantage of the hardware acceleration. This particular mode requires compiling ffmpeg with a modified header (or possibly the CUDA 8 RC) and is not upstream in ffmpeg yet. Usage: You will need to specify vo=opengl and hwdec=cuda. Note that hwdec=auto will probably not work as it will try to use vdpau first. mpv --hwdec=cuda --vo=opengl foobar.mp4 If you want to use filters that require frames in system memory, just use the decoder directly without the hwdec, as documented above.
* vo_opengl: fix incorrect video rendering after vdpau preemption recoverywm42016-09-071-0/+1
| | | | | This could also trigger in certain other cases, whenever it falls back to dumb mode.
* vo_opengl: fix another potential vdpau preemption issuewm42016-09-071-1/+2
| | | | | | reinit() will change the image params fields, so give it a copy. Will fix potential crashes if preemption happens more than once.
* osdep: rename atomics.h to atomic.hwm42016-09-074-4/+3
| | | | | The standard header is stdatomic.h, so the extra "s" freaks me out every time I look at it.
* vo_vdpau: rename some sub-optionswm42016-09-061-3/+6
| | | | | Since the sub-options have been deprecated very recently, and are redirected to global options, we don't need to document this change.
* vo_opengl: simplify option handlingwm42016-09-063-45/+37
| | | | | | | | | | | | | Instead of copying the options around... just don't. video.c now has full control over when options are updated. (It still gets notified from outside, but it decides when the updated options are copied: when m_config_cache_update() is called.) So there's no need for tricky stuff, and it can be simplified a bit. Also change lcms.c. We could do it like video.c, and get the options from the global config store. But it seems simpler to just provide a pointer to an option struct, which is arbitrarily mutated from the outside (from the perspective of lcms.c).
* vo_opengl: fix --icc-profile initial behaviorwm42016-09-061-0/+1
| | | | | | | | | Setting --icc-profile had no effect, until a vo_opengl option was changed at runtime. We must initialize the renderer for the initial option state too. For some reason, the ICC profile gets loaded twice. The next commit happens to fix this.
* options: deprecate suboptions for the remaining AO/VOswm42016-09-059-1/+10
|
* options: add automagic hack for handling sub-option deprecationswm42016-09-052-0/+7
| | | | | | | | | | | | | | | | | I decided that it's too much work to convert all the VO/AOs to the new option system manually at once. So here's a shitty hack instead, which achieves almost the same thing. (The only user-visible difference is that e.g. --vo=name:help will list the sub-options normally, instead of showing them as deprecation placeholders. Also, the sub-option parser will verify each option normally, instead of deferring to the global option parser.) Another advantage is that once we drop the deprecated options, converting the remaining things will be easier, because we obviously don't need to add the compatibility hacks. Using this mechanism is separate in the next commit to keep the diff noise down.
* vo_direct3d: deprecate direct3d_shaders aliaswm42016-09-052-24/+2
| | | | | And remove the difference between the aliases. This is needed to make the sub-option changes less painful.
* vo_image: move to global optionswm42016-09-053-25/+52
| | | | | This is a bit "special", because the config tree wants unique m_sub_options pointers in the whole thing.
* options: add a mechanism to make sub-option replacement slightly easierwm42016-09-053-1/+7
| | | | | | | | Instead of requiring each VO or AO to manually add members to MPOpts and the global option table, make it possible to register them automatically via vo_driver/ao_driver.global_opts members. This avoids modifying options.c/options.h every time, including having to duplicate the exact ifdeffery used to enable a driver.
* w32_common: initialize playback status as soon as possiblewm42016-09-021-16/+25
| | | | | | | | On a VOCTRL_UPDATE_PLAYBACK_STATE store the state, and use it to initialize the next time the task list becomes available. This actually fixes #3482. Revert commit f2e25e9e because it's not needed anymore.
* command: remove vo-cmdlinewm42016-09-021-1/+0
| | | | | | With the recent vo_opengl changes it doesn't do anything anymore. I don't think a deprecation period is necessary, because the command was always marked as experimental.
* vo_opengl: deprecate sub-options, add them as global optionswm42016-09-026-242/+207
| | | | | | | | | | | | | | | | | | | | | | | | vo_opengl sub-option were always rather annoying to handle. It seems better to make them global options instead. This is simpler and easier to use. The only disadvantage we are aware of is that it's not clear that many/all of these new global options work with vo_opengl only. --vo=opengl-hq is also deprecated. There is extensive compatibility with the old behavior. One exception is that --vo-defaults will not apply to opengl-hq (though with opengl it still works). vo-cmdline is also dysfunctional and will be removed in a following commit. These changes also affect opengl-cb. The update mechanism is still rather inefficient: it requires syncing with the VO after each option change, rather than batching updates. There's also no granularity (video.c just updates "everything", and if auto-ICC profiles are enabled, vo_opengl.c will fetch them on each update). Most of the manpage changes were done by Niklas Haas <git@haasn.xyz>.
* vo_opengl: rename 3dlut-size to icc-3dlut-sizewm42016-09-021-1/+2
| | | | | Not documenting this yet, because a later commit will change all the options anyway.
* vo: use new option update mechanismwm42016-09-023-3/+23
| | | | | | | | | | | | | | | | This is still rather basic. run_reconfig() and run_control() update the options because it's needed for panscan (and other video scaling options), and fullscreen, border, ontop updates. In the old model, these options could be accessed only while both playback thread and VO threads were locked (i.e. during synchronous calls like vo_control()), so this should be sufficient in order not to miss any updates. In the future, a more fine-grained update mechanism could be added to handle these updates "exactly". x11_common.c contains an evil hack, as I see no reasonable way to handle this properly. The VO thread can't "lock" the main thread, so this is not simple.
* vo_opengl: minor renderer option access refactor</