summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* vf_buffer: remove this filterwm42017-12-122-87/+0
| | | | | It has been deprecated for a while and is 100% useless. It was forgotten in the recent filter purge. Get rid of it.
* w32_common: update outdated comment about wakeup eventspavelxdd2017-12-111-2/+1
| | | | | mpv doesn't use WM_USER for wakeup events since 91079c0 Updated the comment.
* vf_convert: default to limited range when converting RGB to YUVwm42017-12-111-0/+5
| | | | | | | | | | Full range YUV causes problems everywhere. For example it's usually the wrong choice when using encoding mode, and libswscale sometimes messes up when converting to full range too. (In this partricular case, we found that converting rgba->yuv420p16 full range actually seems to output limited range.) This actually restores a similar heueristic from the late vf_scale.c.
* vo_gpu: hwdec_drmprime_drm: silence error on failed autoprobingwm42017-12-111-1/+1
| | | | | | | | | | When autoprobing the hwdec interops (which now happens to all compiled interops if hardware decoding is used), failure to load an interop should not print an error in the normal case. So hide it. (We could make the log level conditional on whether autoprobing is used, but directly loading it without autoprobing is obscure, and most other interops don't do this either.)
* hwdec: document a forgotten parameterwm42017-12-111-0/+1
| | | | Add the "all" value to the --gpu-hwdec-interop help output.
* video: remove code duplication by calling a hwdec loader helperwm42017-12-111-2/+1
| | | | | Make gl_video_load_hwdecs() call gl_video_load_hwdecs_all() when all HW decoders should be loaded.
* video: properly initialize and set hwdec_interopwm42017-12-111-0/+2
| | | | Don't reset --gpu-hwdec-interop if vo_gpu uses dumb mode.
* vd_lavc: always load VO interops with non-copy hw decoderswm42017-12-111-0/+4
| | | | | | | | For METHOD_INTERNAL hwdecs (non-copy cases), make sure the VO interops are always loaded, because those decoders will output hardware pixel formats, which will need special support in vo_gpu. Otherwise, initialization will fail, complaining that it can't convert the output format to something the VO supports.
* vo: fix a compiler warning by properly printing a 64bit integerJan Ekström2017-12-111-1/+1
|
* vd_lavc: add rkmpp to the hwdec_wrappers array.LongChair2017-12-101-0/+1
| | | | Allows to get the hwdec picked up properly by mpv on rockchip devices
* vo_gpu: d3d11: check for timestamp query supportJames Ross-Gowan2017-12-091-0/+9
| | | | | | | | | | Apparently timestamp queries are optional for 10level9 devices. Check for support when creating the device rather than spamming error messages during rendering. CreateQuery can be used to check for support by passing NULL as the final parameter. See: https://msdn.microsoft.com/en-us/library/windows/desktop/ff476150.aspx#ID3D11Device_CreateQuery
* w32_common: improve the window message state machinepavelxdd2017-12-071-1/+13
| | | | | | | | * Distinguish between the window being moved or not. * Skip trying to snap if currently in full screen or an embedded window. * Exit snapped state if the size changed when the window was being moved.
* w32_common: skip window snapping if Windows handled itpavelxdd2017-12-071-2/+12
| | | | | | Check the expected width and height against up-to-date window placement. If they do not match, we will consider snapping to have happened on Windows' side.
* vo: add support for externally driven renderloop and make wayland use itRostislav Pehlivanov2017-12-054-4/+70
| | | | | | | | | | | Fixes display-sync (though if you change virtual desktops you'll need to seek to re-enable display-sync) partially under wayland. As an advantage, rendering is completely disabled if you change desktops or alt+tab so you lose no performance if you leave mpv running elsewhere as long as it isn't visible. This could also be ported to other VOs which supports it.
* vo_gpu: d3d11_helpers: use better formatting for PCI IDsJames Ross-Gowan2017-12-041-4/+6
| | | | | The old format was definitely misleading, since it used an 0x prefix and formatted the device IDs with %d.
* Fix various typos in log messagesNicolas F2017-12-032-2/+2
|
* video: probe format of primary plane in drm/egl contextAnton Kindestam2017-12-031-3/+59
| | | | | | | | | We need to support hardware/drivers which do not support ARGB8888 in their primary plane. We also use p->primary_plane_format when creating the gbm surface, to make sure it always matches (in actuality there should be little difference).
* hwdec: whitespace cleanup in hwdec_drmprime_drm.cAnton Kindestam2017-12-031-2/+2
|
* video: fix use of possibly-NULL pointer in drm_egl_initAnton Kindestam2017-12-031-1/+2
|
* video: fix double free in drm_atomic_create_contextAnton Kindestam2017-12-031-1/+2
| | | | | | | | | | | | Passing in an invalid DRM overlay id with the --drm-overlay option would cause drmplane to be freed twice: once in the for-loop and once at the error-handler label fail. Solve by setting drmpanel to NULL after freeing it. Also the 'return false' statement after the error handler label should probably be 'return NULL', given that the return type of drm_atomic_create_context returns a pointer.
* build: remove POSIX/sysv shared memory testwm42017-12-022-48/+17
| | | | | | vo_x11 and vo_xv need this. According to the Linux manpage, all involved functions are POSIX-2001 anyway. (I just assumed they were not, because they're mostly System V UNIX legacy garbage.)
* vd_lavc: don't request native pixfmt with -copy and METHOD_INTERNALwm42017-12-021-0/+1
| | | | | | | | | If the codec uses AV_CODEC_HW_CONFIG_METHOD_INTERNAL, and we're using the -copy method, then don't request the native pix_fmt. It might not have a AVFrame.hw_frames_ctx set, and we couldn't read back at all. On top of that, most of those decoders probably don't provide read-back when using such opaque formats anyway, while providing separate decoding modes to decode to RAM.
* video: remove some more hwdec legacy stuffwm42017-12-0210-93/+50
| | | | | | | | | Finally get rid of all the HWDEC_* things, and instead rely on the libavutil equivalents. vdpau still uses a shitty hack, but fuck the vdpau code. Remove all the now unneeded remains. The vdpau preemption thing was not unused anymore; if someone cares this could probably be restored.
* vd_lavc, vdpau, vaapi: restore emulated API avoidancewm42017-12-025-3/+48
| | | | | | This code is for trying to avoid using an emulation layer when using auto probing, so that we end up using the actual API the drivers provide. It was destroyed in the recent refactor.
* hwdec: don't require setting legacy hwdec fieldswm42017-12-027-30/+18
| | | | | | | | | | With the recent changes, mpv's internal mechanisms got synced to libavcodec's once more. Some things are still needed for filters (until the mechanism gets replaced), but there's no need to require other hwdec methods to use these fields. So remove them where they are unnecessary. Also fix some minor leaks in the dxva2 backends, and set the driver_name field in the Apple ones. Untested on Apple crap.
* vd_lavc: simpler way to check for opque hw framewm42017-12-021-3/+1
| | | | The ->fmt shit is something I'd like to phase out.
* vd_lavc: sort -copy hwdec modes to end of listwm42017-12-021-6/+12
| | | | | | | | | | | | | | | Otherwise, if e.g. "nvdec" didn't work, but "nvdec-copy" did, it would never try "vdpau", which is actually the next non-copy mode on the autprobe list. It's really expected that it selects "vdpau". Fix this by sorting the -copy modes to the end of the final hwdec list. But we still don't want preferred -copy modes like "nvdec-copy" to be sorted after fragile non-preferred modes like "cuda", and --hwdec=auto should prefer "nvdec-copy" over it, so make sure the copying mode does not get precedence over preferred vs. non-preferred mode. Also simplify the existing auto_pos sorting condition, and fix the fallback sort order (although that doesn't matter too much).
* vd_lavc: allow forcing single implementations with --hwdecwm42017-12-021-2/+3
|
* vd_lavc: slightly simplifywm42017-12-021-34/+28
| | | | | | Factor the somewhat-duplicated code into an append function. Also fix setting the copying flag in one of the cases. This also ensures some uniformity.
* vd_lavc: coding stylewm42017-12-021-1/+1
|
* hwdec: remove unused HWDEC_* constantswm42017-12-011-19/+1
| | | | Removing the rest requires replacing some other mechanisms, later.
* vd_lavc: fix dumb nonsensewm42017-12-011-1/+4
|
* vd_lavc, mp_image: remove weird mpv specific palette constantwm42017-12-013-9/+3
| | | | | Was for times when we were trying to be less dependent on libav* I guess.
* vd_lavc: merge redundant headerwm42017-12-012-94/+77
| | | | This is not needed anymore.
* vd_lavc: rewrite how --hwdec is handledwm42017-12-014-483/+354
| | | | | | | | | | | | | | | | Change it from explicit metadata about every hwaccel method to trying to get it from libavcodec. As shown by add_all_hwdec_methods(), this is a quite bumpy road, and a bit worse than expected. This will probably cause a bunch of regressions. In particular I didn't check all the strange decoder wrappers, which all cause some sort of special cases each. You're volunteering for beta testing by using this commit. One interesting thing is that we completely get rid of mp_hwdec_ctx in vd_lavc.c, and that HWDEC_* mostly goes away (some filters still use it, and the VO hwdec interops still have a lot of code to set it up, so it's not going away completely for now).
* vd_lavc: drop mediacodec direct rendering support temporarilywm42017-12-012-69/+8
| | | | | | | | | | | | The libavcodec mediacodec support does not conform to the new hwaccel APIs yet. It has been agreed uppon that this glue code can be deleted for now, and support for it will be restored at a later point. Readding would require that it supports the AVCodecContext.hw_device_ctx API. The hw_device_ctx would then contain the surface ID. vo_mediacodec_embed would actually perform the task of creating vo.hwdec_devs and adding a mp_hwdec_ctx, whose av_device_ref is a AVHWDeviceContext containing the android surface.
* video: move d3d.c out of decode sub directorywm42017-12-017-5/+5
| | | | | | It makes more sense to have it in the general video directory (along with vdpau.c and vaapi.c), since the decoder source files don't even access it anymore.
* vd_lavc: delete hw_d3d11va.c/hw_dxva2.c and merge leftoverswm42017-12-015-117/+39
| | | | | | Like with all hwaccels, there's little that is actually specific to decoding (which has been moved away anyway), and what is left are declarations (which will also go away soon).
* hw_dxva2: move dxva2 code to d3d.cwm42017-12-012-117/+126
| | | | This source file will disappear, so just collect the leftovers in d3d.c.
* video: refactor hw device creation for hwdec copy modeswm42017-12-0111-203/+207
| | | | | | | | | | Lots of shit code for nothing. We probably could just use libavutil's code for all of this. But for now go with this, since it tends to prevent stupid terminal messages during probing (libavutil has no mechanism to selectively suppress errors specifically during probing). Ignores the "emulated" API flag (for avoiding vaapi/vdpau wrappers), but it doesn't matter that much for -copy anyway.
* video: fix memory leaks with hwdec copy modeswm42017-12-011-2/+2
| | | | | | | This leaked 2 unreffed AVFrame structs (roughly 1KB) per decoded frame. Can I blame the FFmpeg API and the weird difference between freeing and unreffing an AVFrame?
* vd_lavc: move entrypoint for hwframes_refinewm42017-12-017-11/+9
| | | | | | | The idea is to get rid of vd_lavc_hwdec, so special functionality like this has to go somewhere else. At this point, hwframes_refine is only needed for d3d11, and it doesn't do much, so for now the new callback has no context. In can be made more fancy if really needed.
* vd_lavc: remove process_image callbackwm42017-12-012-9/+3
| | | | Now unused.
* d3d11: move code for d3d11eglrgb hackwm42017-12-012-10/+3
|
* vo_gpu: hwdec: remove redundant fieldswm42017-12-0113-18/+3
| | | | | | | | | | | | | The testing_only field is not referenced anymore with vaglx removed and the previous commit dropping all uses. The ra_hwdec_driver.api field became unused with the previous commit, but all hwdec interop drivers still initialized it. Since this touches highly OS-specific code, build regressions are possible (plus the previous commit might break hw decoding at runtime). At least hwdec_cuda.c still used the .api field, other than initializing it.
* vo_gpu: make it possible to load multiple hwdec interop driverswm42017-12-019-143/+158
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make the VO<->decoder interface capable of supporting multiple hwdec APIs at once. The main gain is that this simplifies autoprobing a lot. Before this change, it could happen that the VO loaded the "wrong" hwdec API, and the decoder was stuck with the choice (breaking hw decoding). With the change applied, the VO simply loads all available APIs, so autoprobing trickery is left entirely to the decoder. In the past, we were quite careful about not accidentally loading the wrong interop drivers. This was in part to make sure autoprobing works, but also because libva had this obnoxious bug of dumping garbage to stderr when using the API. libva was fixed, so this is not a problem anymore. The --opengl-hwdec-interop option is changed in various ways (again...), and renamed to --gpu-hwdec-interop. It does not have much use anymore, other than debugging. It's notable that the order in the hwdec interop array ra_hwdec_drivers[] still matters if multiple drivers support the same image formats, so the option can explicitly force one, if that should ever be necessary, or more likely, for debugging. One example are the ra_hwdec_d3d11egl and ra_hwdec_d3d11eglrgb drivers, which both support d3d11 input. vo_gpu now always loads the interop lazily by default, but when it does, it loads them all. vo_opengl_cb now always loads them when the GL context handle is initialized. I don't expect that this causes any problems. It's now possible to do things like changing between vdpau and nvdec decoding at runtime. This is also preparation for cleaning up vd_lavc.c hwdec autoprobing. It's another reason why hwdec_devices_request_all() does not take a hwdec type anymore.
* vo_opengl: hwdec_vaegl: Reenable vaExportSurfaceHandle()Mark Thompson2017-11-301-3/+3
| | | | It will be present from libva 2.1 (VAAPI 1.1.0 or higher).
* vd_lavc: prefer nvdec over vdpau with --hwdec=autowm42017-11-302-14/+16
| | | | | | | | | | | | | | | | nvdec aka cuvid aka cuda should work much better than vdpau, and support newer codecs (such as vp9), and more advanced surface formats (like 10 bit). This requires moving the d3d hwaccels in the autoprobe order, since on Windows, d3d decoding should be preferred over nvidia proprietary stuff. Users of older drivers will need to force --hwdec=vdpau, since it could happen that the vo_gpu cuda hwdec interop loads (so the vdpau interop is not loaded), but the hwdec itself doesn't work. I expect this does not break AMD (which still needs vdpau for vo_gpu interop, until libva is fixed so it can fully support AMD).
* vo_gpu: remove hwdec_vaglx interopwm42017-11-302-235/+0
| | | | | | This has stopped being useful a long time ago, and it's the only GPL source file in the vo_gpu source directories. Recently it wasn't even loaded at all, unless you forced loading it.
* vf: remove a stray HAVE_GPLwm42017-11-301-3/+0
| | | | These were determined to be LGPL a few commits ago.
* vf_lavfi: remove old internal wrapper API stuffwm42017-11-292-117/+0
| | | | | This was for filters "redirecting" to vf_lavfi. All filters using it have been removed.
* vf_sub, vf_format: change license to LGPLwm42017-11-292-24/+15
| | | | | | | | | | | | They were added to the "to deleted" list and never relicensed, because I thought I'd delete them early. But it's possible that they'll stay in mpv for a longer time, so relicense them. Still leaving them as deprecated and scheduled for removal, so they can still be dropped once there is a better way to deal with them, if they get annoying, or if a better mechanism is found that makes them unnecessary. All contributors agreed. There are some minor changes by people who did not agree, but these are all not relevant or have been removed.
* vf: remove most GPL video filterswm42017-11-2913-1500/+0
| | | | | | | | | | | | | Almost all of them had their guts removed and replaced by libavfilter long ago, but remove them anyway. They're pointless and have been scheduled for deprecation. Still leave vf_format (because we need it in some form) and vf_sub (not sure). This will break some builtin functionality: lavfi yadif defaults are different, auto rotation and stereo3d downconversion are broken. These might be fixed later.
* vf: add vf_convert as interim replacement for vf_scalewm42017-11-292-2/+132
| | | | | | | | | | | We want to drop vf_scale, but we still need a way to auto convert between imgfmts. In particular, vf.c will auto insert the "scale" filter if the VO doesn't support a pixfmt. To avoid chaos, create a new vf_convert.c filter, based on vf_scale.c, but without the unrelicensed code parts. In particular, this filter does not do scaling and has no options. It merely converts from one imgfmt to another, if needed.
* vo_gpu: d3d11: don't use runtime version for UAV slot countJames Ross-Gowan2017-11-191-1/+1
| | | | | | FL 11_1 is only supported with the Direct3D 11.1 runtime anyway, so there is no need to check both the runtime version and the feature level.
* vo_gpu: d3d11_helpers: don't try BGRA_SUPPORTJames Ross-Gowan2017-11-191-20/+4
| | | | | | | | | The D3D11_CREATE_DEVICE_BGRA_SUPPORT flag doesn't enable support for BGRA textures. BGRA textures will be supported whether or not the flag is passed. The flag just fails device creation if they are not supported as an API convenience for programs that need BGRA textures, such as programs that use D2D or D3D9 interop. We can handle devices without BGRA support fine, so don't bother with the flag.
* vo_gpu: d3d11: mark the bgra8 format as unorderedJames Ross-Gowan2017-11-191-1/+1
| | | | Whoops. I was confused by the double-negative here.
* w32_common: move imm32.dll function to w32->api structpavelxdd2017-11-151-15/+12
| | | | | | | | | For consistency with already implemented shcore.dll function loading in w32->api: Moved loading of imm32.dll to w32_api_load, and declare pImmDisableIME function pointer in the w32->api struct. Removed unloading of imm32.dll.
* vo_gpu/context_android: Process surface resizes correctlysfan52017-11-141-10/+11
|
* vo_gpu: ra_gl: remove stride hackwm42017-11-121-4/+1
| | | | Same reasoning as in commit 9b5d062d36e3.
* vo_gpu: d3d11: remove flipped texture upload hackJames Ross-Gowan2017-11-121-8/+0
| | | | Made unnecessary by 4a6b04bdb930.
* cocoa: always return the target NSRect when in fullscreenAkemi2017-11-111-1/+4
| | | | | | there is no need to calculate a new rectangle when in fullscreen since we always want to cover the whole screen. so just return the target rectangle.
* vo_gpu: never pass flipped images to ra or ra backendswm42017-11-101-2/+7
| | | | | | | | | | | | | | | | | | | Seems like the last refactor to this code broke playing flipped images, at least with --opengl-pbo --gpu-api=opengl. Flipping is rather a shitmess. The main problem is that OpenGL does not support flipped uploading. The original vo_gl implementation considered it important to handle the flipped case efficiently, so instead of uploading the image line by line backwards, it uploaded it flipped, and then flipped it in the renderer (basically the upload path ignored the flipping). The ra code and backends probably have an insane and inconsistent mix of semantics, so fix this by never passing it flipped images in the first place. In the future, the backends should probably support flipped images directly. Fixes #5097.
* vo_gpu: hwdec_d3d11va: allow zero-copy video decodingJames Ross-Gowan2017-11-073-62/+159
| | | | | | | | | | | | | |