summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* vo_gpu: add rgba16hf to the list of FBO formatsJames Ross-Gowan2017-10-181-1/+2
| | | | | | | This should be functionally identical to rgba16f, since the formats only differ in their representation on the CPU, but it could be useful for RA backends that don't expose rgba16f, like Vulkan. It's definitely useful for the WIP D3D11 backend.
* vo_rpi: fix build (probably)wm42017-10-171-1/+1
| | | | Untested. If it works, fixes #4919.
* vo_gpu: remove weird p->vo indirectionwm42017-10-171-11/+9
| | | | That's just unnecessary.
* vo_gpu: fix video sometimes not being rerendered on equalizer changewm42017-10-174-4/+9
| | | | | | | | | | | | | | With video paused, changing the brightness controls (or similar) would sometimes not rerender the video frame. So the OSD would redraw, but the video wouldn't change. This is caused by output caching, and a redraw request is free to return the cached frame. Change it such to invalidate the cached frame if any of the options or the equalizer change. In theory, gl_video_reset_surfaces() could be called if the equalizer changes - this would apparently force interpolatzion to redraw all frames. But this looks kind of crappy when changing the equalizer during playback. It'll "eventually" use the correct settings anyway, and when paused interpolation is off.
* vdpau: remove some more dead codewm42017-10-162-11/+0
|
* video: remove special path for hwdec screenshotswm42017-10-163-96/+1
| | | | | | | This was phased out, and was used only by vdpau by now. Drop the mechanism and the vdpau special code, which means screenshots won't include the vf_vdpaupp processing anymore. (I don't care enough about vdpau, it's on its way out.)
* video: fix previous commitwm42017-10-161-2/+1
| | | | Sigh.
* video: make previously added hwdec params mechanism more genericwm42017-10-163-18/+20
| | | | | | | | | | | | The mechanism introduced in b135af6842bf assumed AVHWFramesContext would be enough. Apparently it's not - the intended use with Rockchip (not Rokchip btw.) requires accessing actual frame data in order to access the AVDRMFrameDescriptor struct. Just pass the entire mp_image to the new function. This is more flexible, although it slightly worries me that it will be less reusable for things which require setting up mp_image_params before any real frames are processed (such as filters).
* video: properly pass through ICC datawm42017-10-162-8/+24
| | | | | | | | | | | | | | | | | | The same should happen with any other side data that matters to mpv, otherwise filters will drop it. (No, don't try to argue that mpv should use AVFrame. That won't work.) ffmpeg_garbage() is copy&paste from frame_new_side_data() in FFmpeg (roughly feed201849b8f91), because it's not public API. The name reflects my opinion about FFmpeg's API. In mp_image_to_av_frame(), change the too-fragile *new_ref = (struct mp_image){0}; into explicitly zeroing out the fields that are "transferred" to the created AVFrame.
* mp_image: merge AVFrame conversion functionswm42017-10-161-38/+29
| | | | | | | | Merge mp_image_copy_fields_to_av_frame() into mp_image_from_av_frame(), same for the other direction. There isn't any good reason to keep them separate, and the refcounting handling makes it only more awkward.
* video: add mp_image_params.hw_flags and add an examplewm42017-10-166-1/+74
| | | | | | | | | | | | | | | | | | | | | | | | | | | | It seems this will be useful for Rokchip DRM hwcontext integration. DRM hwcontexts have additional internal structure which can be different depending on the decoder, and which is not part of the generic hwcontext API. Rockchip has 1 layer, which EGL interop happens to translate to a RGB texture, while VAAPI (mapped as DRM hwcontext) will use multiple layers. Both will use sw_format=nv12, and thus are indistinguishable on the mp_image_params level. But this is needed to initialize the EGL mapping and the vo_gpu video renderer correctly. We hope that the layer count is enough to tell whether EGL will translate the data to a RGB texture (vs. 2 texture resembling raw nv12 data). For that we introduce MP_IMAGE_HW_FLAG_OPAQUE. This commit adds the flag, infrastructure to set it, and an "example" for D3D11. The D3D11 addition is quite useless at this point. But later we want to get rid of d3d11_update_image_attribs() anyway, while we still need a way to force d3d11vpp filter insertion, so maybe it has some justification (who knows). In any case it makes testing this easier. Obviously it also adds some basic support for triggering the opaque format for decoding, which will use a driver-specific format, but which is not supported in shaders. The opaque flag is not used to determine whether d3d11vpp needs to be inserted, though.
* video: make it possible to always override hardware decoding formatwm42017-10-161-0/+2
| | | | | | | | Mostly an obscure option for testing. But --videotoolbox-format can be deprecated, as it becomes redundant. We rely on the libavutil hwcontext implementation to reject invalid pixfmts, or not to blow up if they are incompatible.
* vo_gpu: remove some minor dead codewm42017-10-161-3/+1
| | | | | This was for the "opengl" compat VO entry, which is now handled differently.
* vo_gpu: semi-fix --gpu-context/--gpu-api options and help outputwm42017-10-164-17/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This was confusing at best. Change it to output the actual choices. (Seems like in the end it's always me who has to clean up other people's bullshit.) Context names were not unique - but they should be, so fix it. The whole point of the original --opengl-backend option was to side-step the tricky auto-detection, so you know exactly what you get. The goal of this commit is to make --gpu-context work the same way. Fix the non-unique names by appending "vk" to the names. Keep in mind that this was not suitable for slecting the "UI" backend anyway, since "x11" would force GLX, whereas people on not-NVIDIA actually want "x11egl". Users trying to use --gpu-context=x11 to force the X11 backend would always end up with GLX, which would at least break VAAPI hardware decoding for them. Basically the idea that this option could select the "UI" type is completely broken - it selects an implementation, which implies a UI. Selecting the UI type This would require a separate mechanism. (Although in theory this separate mechanism could be part of the --gpu-context option - in any case, someone would have to implement it.) To achieve help output that can actually be understood, just duplicate the code. Most of that code is duplicated anyway, and trying to share just the list code with the result of making the output unreadable doesn't make too much sense. If we wanted to save code/effort, we could just remove the help output altogether. --gpu-api has non-unique entries, and it would be nice to group them (e.g. list all OpenGL capable contexts with "opengl"), but C makes this simple idea too much of a pain, so don't do it. Also remove a stray tab from the android entry on the manpage.
* mp_image: select an explicit fallback for chroma locationwm42017-10-161-0/+7
| | | | | | | | | | If the chroma location is missing, vo_gpu will use centered chroma. Select a better chroma location by default: normally, it will always be MPEG video chroma location. If full levels are used, use JPEG chroma location, because that sort of sounds like it could make sense as it might coincide with JPEG being decoded. See e.g. #4804.
* vo_gpu: mali-fbdev: fix build errorTobias Jakobi2017-10-131-2/+2
| | | | Apparantly the context was renamed.
* wayland_common: init output_list during main struct initRostislav Pehlivanov2017-10-121-1/+2
| | | | | Otherwise if display connection or xkb init failed the uninit function could segfault.
* wayland_common: require wl_output v2 and send MP_INPUT_RELEASE_ALL on uninitRostislav Pehlivanov2017-10-111-8/+13
| | | | | | Every compositor (including toy compositors) has had support for wl_output v2 since forever, so there's little point in supporting degraded output for 5 year old releases (especially considering we require zxdg6 which is far more recent).
* vo_gpu: shaderc: include debug info when --gpu-debug is setJames Ross-Gowan2017-10-111-0/+2
| | | | | | | This adds symbol information to the generated SPIR-V, which shows up in the SPIR-V assembly dump. It's also useful for potential RA backends that use SPIRV-Cross, since the symbol information is used in the generated shader source.
* Add checks for HAVE_GPL to various GPL-only source fileswm42017-10-1019-0/+95
| | | | | | | | This should actually cover all of them, if you take into account that some unchanged GPL source files include header files with such checks. Also this was done already for the libaf derived code. This is only for "safety" and to avoid misunderstandings.
* wayland_common: adjust default cursor size and scale its bufferRostislav Pehlivanov2017-10-101-2/+3
| | | | | | | It turns out compositors which do scaling scale the cursor as well, so every single surface needs to get scaled too. Also, 32 corresponds to the default size for both GTK+ and KDE.
* vo: fix reference to mediacodec_embedAman Gupta2017-10-091-2/+2
|
* vo_gpu: android: fix gpu contextAman Gupta2017-10-091-0/+4
|
* vo_opengl: hwdec_vaegl: Use vaExportSurfaceHandle() if presentMark Thompson2017-10-091-0/+80
| | | | | | | | | | | This new interface in libva2 offers a cleaner way to export surfaces which can then be imported to EGL. In particular, this works with the Mesa driver, so we can have proper playback without a pointless download and upload on AMD cards. This change does nothing with libva1, and will fall back to the libva1 interface (vaDeriveImage() + vaAcquireBufferHandle()) if vaExportSurfaceHandle() is not present.
* vaapi: Use libva2 message callbacksMark Thompson2017-10-091-3/+29
| | | | They are no longer global, so they work vaguely sensibly.
* vo_gpu: simplify opengl aliaswm42017-10-092-31/+2
| | | | | This makes the replacement warning message worse, but I don't think I care enough.
* vo_gpu: remove duplicated optionswm42017-10-091-1/+0
| | | | | All these options (like --gpu-context etc.) were duplicated. It's amazing that it didn't cause more problems than it did.
* vo_opengl: context_drm_egl: Don't create a new framebuffer for every frameMark Thompson2017-10-091-22/+27
|
* vo_gpu: add android opengl backendAman Gupta2017-10-091-0/+151
| | | | | | | | | | At the moment, rendering on Android requires ``--vo=opengl-cb`` and a lot of java<->c++ bridging code to receive the receive and react to the render callback in java. Performance also suffers with opengl-cb, due to the overhead of context switching in JNI. With this patch, Android can render using ``--vo=gpu --gpu-context=android`` (after setting ``--wid`` to point to an android.view.Surface on-screen).
* vo: add mediacodec_embed output driverAman Gupta2017-10-092-0/+93
| | | | | Allows rendering IMGFMT_MEDIACODEC frames directly onto an android.view.Surface
* hwdec: add mediacodec hardware decoder for IMGFMT_MEDIACODEC framesAman Gupta2017-10-095-0/+54
|
* vo: add VO_CAP_NOREDRAW for upcoming vo_mediacodec_embedAman Gupta2017-10-092-1/+8
| | | | | | | | | | | MediaCodec uses a fixed number of output buffers to hold frames, and expects that output buffers will be released as soon as possible. Once rendered, the underlying frame is automatically released and cannot be reused or rerendered. The new VO_CAP_NOREDRAW forces mpv to release frames immediately after they are rendered or dropped, to ensure that MediaCodec decoder does not run out of buffers and stall out.
* hwdec: rename mediacodec to mediacodec-copyAman Gupta2017-10-093-10/+27
|
* img_format: AV_PIX_FMT_PAL8 is RGBwm42017-10-091-2/+5
| | | | | | | | | | | | | | | | | This partiular format is not marked as AV_PIX_FMT_FLAG_RGB in FFmpeg's pixdesc table, so mpv assumed it's a YUV format. This is a regression, since the old code in mp_imgfmt_get_desc() also treated this format specially to avoid this problem. Another format which was special-cased in the old code was AV_PIX_FMT_MONOBLACK, so make an exception for it as well. Maybe this problem could be avoided by mp_image_params_guess_csp() not forcing certain colorimetric parameters by the implied colorspace, but certainly that would cause other problems. At least there are mistagged files out there that would break. (Do we actually care?) Fixes #4965.
* wayland_common: implement output tracking, cleanups and bugfixesRostislav Pehlivanov2017-10-094-215/+246
| | | | | | | | | | | | | | | | | | This commit: - Implements output tracking (e.g. monitor plug/unplug) - Creates the surface during registry (no other dependencies) - Queues the callback immediately after surface creation - Cleaner and better event handling (functions return directly) - Better reconfigure handling (resizes reduced to 1 during init) - Don't unnecessarily resize (if dimensions match) Apart from that fixes 2 potential memory leaks (mime type and window title), 2 string ownership issues (output name and make need to be dup'd), fixes some style issues (switches were indented) and finally adds messages when disabling/enabling idle inhibition. The callback setter function was removed in preparation for the commit which will use the frame event cb because it was unnecessary.
* wayland_common: allow vo_wayland_uninit(NULL)Niklas Haas2017-10-071-0/+2
| | | | ...again
* Revert "wayland_common: add support for embedding"Rostislav Pehlivanov2017-10-052-6/+0
| | | | This reverts commit 8d8d4c5cb1b3553215a8ba547d4db463fdc88831.
* wayland_common: respect close eventsRostislav Pehlivanov2017-10-051-3/+9
| | | | | Overlooked. Also add a comment and only set the parent if WinID is set.
* wayland_common: add support for embeddingRostislav Pehlivanov2017-10-052-0/+5
|
* wayland_common: reset the LIVE_RESIZING flag when resizing endsRostislav Pehlivanov2017-10-051-10/+14
| | | | | | The VO code resets each flag individually, and it doesn't do it for this one. Also make the prints use the struct names rather than the hardcoded ones, forgot to add those to the last wayland_common commit.
* build: switch preliminary LGPL mode from v3 to v2.1wm42017-10-051-9/+1
| | | | | | | | | | | iive agreed to relicense things that are still in mpv to LGPLv2.1. So change the licenses of the affected files, and rename the configure switch for LGPL mode to --enable-preliminary-lgpl2. (The "preliminary" part will probably be removed from the configure switch soon as well.) Also player/main.c hasn't had GPL parts since a few commits ago.
* wayland_common: don't hardcode protocol names during registryRostislav Pehlivanov2017-10-041-8/+8
| | | | Use the interface names from the wl_interface structs they provide.
* wayland_common: rewrite from scratchRostislav Pehlivanov2017-10-036-1053/+1209
| | | | | | | | | | | | The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
* vo_wayland: removeRostislav Pehlivanov2017-10-036-1059/+0
| | | | | This VO was buggy and never worked correctly. Like with wayland_common, it needs to be rewritten from scratch.
* vo_gpu: gl: implement proper extension string searchwm42017-10-023-10/+23
| | | | | | | The existing code in check_ext() avoided false positive due to sub-strings, but allowed false negatives. Fix this with slightly better search code, and make it available as function to other source files. (There are some cases of strstr() still around.)
* vo_gpu: enable 3DLUTs in dumb modeNiklas Haas2017-09-301-1/+3
| | | | | | Unless FBOs are unsupported, this works. In particular, it's required to get ICC profiles working in voluntary dumb mode. So instead of blanket-disabling it, only disable it in the !have_fbo false case.
* vf_vavpp: restrict allowed sw upload formats to nv12/yuv420pwm42017-09-301-20/+3
| | | | | | | | | | | | | | | | | | | | We allowed any input format that was generally supported by libva, but this is probably nonsense, as the actual surface format was always fixed to nv12. We would have to check whether libva can upload a given pixel format to a nv12 surface. Or we would have to use a separate frame pool for input surfaces with the exact sw_format - but then we'd also need to check whether the vaapi VideoProc supports the surface type. Hardcode nv12 and yuv420p as input formats, which we know can be uploaded to nv12 surfaces. In theory we could get a list of supported upload formats from libavutil, but that also require allocating a dummy hw frames context just for the query. Add a comment to the upload code why we can allocate an output surface for input. In the long run, we'll probably want to use libavfilter's vaapi deinterlacer, but for now this would break at least user options.
* vaapi: replace error macro implementationwm42017-09-302-12/+3
| | | | | | | | | | The current check_va_status() function could probably be argued to be derived from the original VAAPI's patch check_status() function, thus GPL-only. While I have my doubts that it applies to an idiom on this level, it's better to replace it. Similar idea, different expression equals no copyright association. An earlier commit message promised this, but it was forgotten.
* video: fix green shitwm42017-09-301-1/+1
|
* vaapi: change license to LGPLwm42017-09-293-15/+15
| | | | | | | | | | | | | | | | | | | | | | Originally mpv vaapi support was based on the MPlayer-vaapi patches. These were never merged in upstream MPlayer. The license headers indicated they were GPL-only. Although the actual author agreed to relicensing, the company employing him to write this code did not, so the original code is unusable to us. Fortunately, vaapi support was refactored and rewritten several times, meaning little code is actually left. The previous commits removed or moved that to GPL-only code. Namely, vo_vaapi.c remains GPL-only. The other code went away or became unnecessary mainly because libavcodec itself gained the ability to manage the hw decoder, and libavutil provides code to manage vaapi surfaces. We also changed to mainly using EGL interop, making any of the old rendering code unnecessary. hwdec_vaglx.c is still GPL. It's possibly relicensable, because much of it was changed, but I'm not too sure and further investigation would be required. Also, this has been disabled by default for a while now, so bothering with this is a waste of time. This commit simply disables it at compile time as well in LGPL mode.
* vaapi: move legacy code to vo_vaapi.cwm42017-09-293-440/+310
| | | | | | Done for license reasons. vo_vaapi.c is turned into some kind of dumpster fire, and we'll remove it as soon as I'm mentally ready for unkind users to complain about removal of this old POS.
* vf_vavpp: use error checking macrowm42017-09-291-19/+11
|
* vf_vavpp: use libavutil hw frames API for frame pool and uploadwm42017-09-295-49/+119
| | | | | Another step to get rid of the legacy crap in vaapi.c. (Most is still kept, because it's in use by vo_vaapi.c.)
* vaapi: use newer libavutil vaapi pixfmt namewm42017-09-291-1/+1
| | | | | AV_PIX_FMT_VAAPI_VLD is clearly deprecated - it just doesn't raise any compiler warnings.
* vaapi: minor changeswm42017-09-291-7/+7
| | | | | | | | | | | | This is for relicensing. Some of this code is loosely based on vo_vaapi.c from the original MPlayer-vaapi patches. Most of the code has changed, and only the initialization code and check_status() look remotely similar. The initialization code is changed to be like Libav's (hwcontext_vaapi.c). check_va_status() is just a C idiom, but to play it safe, we'll either drop it from LGPL code (or recreate it). vaapi.c still contains plenty of code from the original patches, but the next commits will move them out of the LGPL code paths.
* vo_gpu: vulkan: reword commentNiklas Haas2017-09-291-3/+4
| | | | | This is fixed upstream (and we now know it's a driver bug) so reword the comment.
* vo_gpu: force layout std430 for PCsNiklas Haas2017-09-291-1/+1
| | | | | | | | Seems to be fixed upstream in the nvidia driver, so it's probably a good idea to 1. force the layout and 2. remove the warning, as it now actually works. Users with older drivers would run into errors, but they can still use shaderc as a replacement. (And it's not like the old status quo was any better)
* vo_gpu: fix --opengl-gamma redirectNiklas Haas2017-09-281-1/+1
| | | | | It still pointed at --gpu-gamma, but we decided on --gamma-factor instead.
* vo_gpu: set the correct number of vertex attribsNiklas Haas2017-09-281-2/+2
| | | | | | | This was always set to the length of the VAO, but it should have been set to the number of vertex attribs actually in use for this frame. No idea how that managed to survive the test framework on nvidia/linux, but ANGLE caught it.
* vo_gpu: vulkan: add support for WindowsJames Ross-Gowan2017-09-283-0/+112
|
* vo_gpu: make the vertex attribs dynamicNiklas Haas2017-09-286-100/+102
| | | | |