summaryrefslogtreecommitdiffstats
path: root/video/out/vo_direct3d.c
Commit message (Collapse)AuthorAgeFilesLines
* Add checks for HAVE_GPL to various GPL-only source fileswm42017-10-101-0/+5
| | | | | | | | 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.
* vo_direct3d: fix buildwm42017-08-221-5/+0
| | | | Broken by previous commit. Fix completely untested.
* video: redo video equalizer option handlingwm42017-08-221-19/+0
| | | | | | | | | | | | | | | | | | | | | | | I really wouldn't care much about this, but some parts of the core code are under HAVE_GPL, so there's some need to get rid of it. Simply turn the video equalizer from its current fine-grained handling with vf/vo fallbacks into global options. This makes updating them much simpler. This removes any possibility of applying video equalizers in filters, which affects vf_scale, and the previously removed vf_eq. Not a big loss, since the preferred VOs have this builtin. Remove video equalizer handling from vo_direct3d, vo_sdl, vo_vaapi, and vo_xv. I'm not going to waste my time on these legacy VOs. vo.eq_opts_cache exists _only_ to send a VOCTRL_SET_EQUALIZER, which exists _only_ to trigger a redraw. This seems silly, but for now I feel like this is less of a pain. The rest of the equalizer using code is self-updating. See commit 96b906a51d5 for how some video equalizer code was GPL only. Some command line option names and ranges can probably be traced back to a GPL only committer, but we don't consider these copyrightable.
* vo_direct3d: remove non-working nv12 shader supportwm42017-06-301-11/+0
| | | | | | | | | It never worked. It relied on some obscure texture format to provide the equivalent of GL_RG or GL_LUMINANCE_ALPHA, but no hardware seemed to report support for it ever. No idea what's the correct way to do this. On D3D11 it exists, of course. (Actually I'd like to remove the whole VO.)
* video: get rid of swapped packed YUVwm42017-06-301-1/+0
| | | | | | Another legacy annoyance. The only place where packed YUV is still important is slightly older Apple hardware or drivers, which require it for efficient hardware decoding.
* vo_direct3d: fix buildwm42017-06-291-1/+0
| | | | That format is worthless anyway.
* video: drop some unused IMGFMT aliaseswm42017-06-291-1/+0
| | | | | | These formats are supported in a generic way. To get rid of IMGFMT_NV21, remove support from vo_direct3d.c completely.
* options: remove deprecated sub-option handling for --vo and --aowm42016-11-251-1/+1
| | | | | | | | Long planned. Leads to some sanity. There still are some rather gross things. Especially g_groups is ugly, and a hack that can hopefully be removed. (There is a plan for it, but whether it's implemented depends on how much energy is left.)
* win32: fix some Clang warningsJames Ross-Gowan2016-11-171-1/+1
| | | | | | | | - win32-console-wrapper.c was inconsistently using the explicit Unicode versions of some Windows API functions and structures. - vo.c should use llabs for int64_t, since long is 32-bit on Windows. - vo_direct3d.c had a potential use of an uninitialized variable if it took the first goto error_exit.
* vo: remove unused VOCTRL_GET_PANSCANwm42016-09-081-2/+0
| | | | | | 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.
* options: deprecate suboptions for the remaining AO/VOswm42016-09-051-0/+1
|
* vo_direct3d: deprecate direct3d_shaders aliaswm42016-09-051-21/+0
| | | | | And remove the difference between the aliases. This is needed to make the sub-option changes less painful.
* vo_direct3d: add missing headerPaul B Mahol2016-08-141-0/+1
| | | | | | Fixes build under cygwin. Signed-off-by: wm4 <wm4@nowhere>
* vo_direct3d: remove bitmap packerwm42016-07-011-85/+70
| | | | See previous comments.
* Fix misspellingsstepshal2016-06-261-1/+1
|
* vo_direct3d: remove passing device to decoderwm42016-05-091-18/+0
| | | | | This was never really used anyway. Removing it for the sake of the following commit.
* video: remove some useless old RGB formatswm42016-01-251-2/+0
| | | | | | | | | | | | | Some VOs had support for these - remove them. Typically, these formats will have only some use in cases where using RGB software conversion with libswscale is faster than letting the VO/GPU do it (i.e. almost never). For the sake of testing this case, keep IMGFMT_RGB565. This is the least messy format, because it has no padding/alpha bits with unknown semantics. Note that decoding to these formats still works. We'll let libswscale repack the data to whatever the VO in use can take.
* mpv_talloc.h: rename from talloc.hDmitrij D. Czarkoff2016-01-111-1/+1
| | | | This change helps avoiding conflict with talloc.h from libtalloc.
* csputils: rename "yuv2rgb" functionswm42015-12-091-1/+1
| | | | | | They're not necessarily restricted to YUV aka YCbCr. vo_direct3d.c and demux_disc.c (DVD specific code) changes untested.
* vo_direct3d: fix operationwm42015-10-311-7/+1
| | | | | | | | | Regression since commit 93db4233. I think the bit that was forgotten here was to remove the vo_w32_config() return value completely. The VO failed to init because that function always returned 0. This commit removes these bits and fixes the VO. Fixes #2434.
* video/out: remove an unused parameterwm42015-10-031-1/+1
| | | | | | | | | | | This parameter has been unused for years (the last flag was removed in commit d658b115). Get rid of it. This affects the general VO API, as well as the vo_opengl backend API, so it touches a lot of files. The VOFLAGs are still used to control OpenGL context creation, so move them to the OpenGL backend code.
* win32: cleanup: remove some unneeded thingswm42015-10-021-1/+1
|
* vo_direct3d: create multithreaded IDirect3DDevice9wm42015-07-301-1/+2
| | | | | | | | | | | | | | | A user complains that it leads to the dxva driver failing, leading to messages like this: [ffmpeg/video] h264: Failed to execute: 0x8007000e [ffmpeg/video] h264: hardware accelerator failed to decode picture Reportedly, this happens only with vo_direct3d, not with vo_opengl. The only difference is that vo_direct3d attempts to share the D3D device with the decoder. Possibly the error is that the device in the VO is not created with D3DCREATE_MULTITHREADED. Change this. Probably fixes #2178.
* vo_direct3d, dxva2: use the same D3D devicewm42015-07-031-0/+18
| | | | | Since we still read-back (and don't have hard plans on changing this), this doesn't have much of an advantage.
* video: do not align source position to 2wm42015-05-211-5/+9
| | | | | vo_direct3d still seems to require this (tested on Windows 8.1 with Intel graphics). Do it in vo_direct3d instead of messing with all VOs.
* Update license headersMarcin Kurczewski2015-04-131-5/+4
| | | | Signed-off-by: wm4 <wm4@nowhere>
* video/out: fix screenshot image formatswm42015-04-071-1/+1
| | | | | | | Use variants without alpha. I skipped vo_sdl, because format selection seems a bit more complicated here, and nobody cares about vo_sdl anymore.
* video/out: remove unused colorspace reportingwm42015-03-311-9/+0
| | | | | | | | Rarely used and essentially useless. The only VO for which this was implemented correctly and for which this did anything was vo_xv, but you shouldn't use vo_xv anyway (plus it support BT.601 only, plus a vendor specific extension for BT.709, whose presence this function essentially reported - use xvinfo instead).
* video: uninline memcpy_pic functionswm42015-03-201-1/+0
| | | | | | | | | There's literally no reason why these functions have to be inline (they might be performance critical, but then the function call overhead isn't going to matter at all). Uninline them and move them to mp_image.c. Drop the header file and fix all uses of it.
* osd: simplify an aspect of change detection handlingwm42015-03-181-9/+6
| | | | | | | | | | | | | | | | | | There was a somewhat obscure optimization in the OSD and subtitle rendering path: if only the position of the sub-images changed, and not the actual image data, uploading of the image data could be skipped. In theory, this could speed up things like scrolling subtitles. But it turns out that even in the rare cases subtitles have such scrolls or axis-aligned movement, modern libass rarely signals this kind of change. Possibly this is because of sub-pixel handling and such, which break this. As such, it's a worthless optimization and just introduces additional complexity and subtle bugs (especially in cases libass does the opposite: incorrectly signaling a position change only, which happened before). Remove this optimization, and rename bitmap_pos_id to change_id.
* win32: fix some more -Wparentheses warningswm42015-03-041-1/+1
| | | | | | | Stupid compiler. For decode_surrogate_pair(), I changed the order of evaluation; it shouldn't matter, but this order is more readable in my opinion.
* vo_direct3d: support NV12 with shaderswm42015-03-021-45/+82
| | | | | | | | | | | | | Semi-important, because --hwdec=dxva2 outputs NV12, and we really don't want people to end up with the "old" StretchRect method. Unfortunately, I couldn't actually get it to work. It seems most D3D drivers (including the wine D3D implementation) reject D3DFMT_A8L8, and I could not find any other 2-channel 8 bit Direct3D 9 format. It seems newer D3D APIs have DXGI_FORMAT_R8G8_UNORM, but there's no way to get it in D3D9. Still pushing this; maybe it actually works on some drivers.
* vo: simplify VOs by adding generic screenshot supportwm42015-01-241-27/+0
| | | | | | | | | | | At the time screenshot support was added, images weren't refcounted yet, so screenshots required specialized implementations in the VOs. But now we can handle these things much simpler. Also see commit 5bb24980. If there are VOs in the future which can't do this (e.g. they need to write to the image passed to vo_driver->draw_image), this still could be disabled on a per-VO basis etc., so we lose no potential performance advantages.
* video: separate screenshot modeswm42015-01-231-8/+6
| | | | | | | | | Use different VOCTRLs for "window" and normal screenshot modes. The normal one will probably be removed, and replaced by generic code in vo.c, and this commit is preparation for this. (Doing it the other way around would be slightly simpler, but I haven't decided yet about the second one, and touching every VO is needed anyway in order to remove the unneeded crap. E.g. has_osd has been unused for a long time.)
* video: remove vfcap.hwm42015-01-211-3/+2
| | | | | | | | | | | | | | | | | And remove all uses of the VFCAP_CSP_SUPPORTED* constants. This is supposed to reduce conversions if many filters are used (with many incompatible pixel formats), and also for preferring the VO's natively supported pixel formats (as opposed to conversion). This is worthless by now. Not only do the main VOs not use software conversion, but also the way vf_lavfi and libavfilter work mostly break the way the old MPlayer mechanism worked. Other important filters like vf_vapoursynth do not support "proper" format negotation either. Part of this was already removed with the vf_scale cleanup from today. While I'm touching every single VO, also fix the query_format argument (it's not a FourCC anymore).
* vo_direct3d: unify d3d "reset" and uninit pathswm42015-01-211-24/+21
| | | | | | | | I'm still not sure how exactly handling of "lost" devices is supposed to be handled. In theory, you only have to "reset" the device, instead of recreating _everything_. But as it is, the code for proper uninit and for handling the reset is exactly the same, so move it into a function to reduce code duplication and the danger of potential bugs.
* vo_direct3d: disable shaders if unavailablewm42015-01-211-23/+24
| | | | | | | | | | Apparently, extremely crappy graphics drivers don't allow you to use shaders. Simply disable use of shaders if this happens, and use the "old" method instead. One unexpectedly tricky thing is that you need a d3d_device to create a shader, which in turn requires a window, so the initialization order changes.
* vo_direct3d: fix shader colormatrix generationwm42015-01-071-5/+5
| | | | It was accidentally broken in d42d60bc1.
* csputils: move image_params -> csp_params into a functionwm42015-01-061-3/+1
| | | | | | | | | Although the line count increases, this is better for making sure everything is handled consistently for all users of the mp_csp_params stuff. This also makes sure mp_csp_params is always initialized with MP_CSP_PARAMS_DEFAULTS (for consistency).
* csputils: get rid of mp_csp_detailswm42015-01-061-3/+3
| | | | It used to be central, but now it's just unneeded.
* vo_direct3d: check whether D3DFMT_A8 is availablewm42014-11-271-11/+29
| | | | | | | | I suspect this is what is happening in github issue #1265 (at least partially). If D3DFMT_A8 is not available, fall back to RGBA. This is less efficient in general, so we normally want to avoid it.
* vo_direct3d: fix texture-memory sub-option, extend itwm42014-11-181-5/+13
| | | | | | | | | | This sub-option was turned into a flag when the sub-option parser was changed to the generic one (probably accidentally). Turn it into a proper choice-option. Also, adjust what the options do. Though none of this probably makes much sense; the default should work, and if it doesn't, the GPU/driver is probably beyond help.
* command: make window-scale property observablewm42014-11-021-0/+2
| | | | | | | | | | | | Add a generic mechanism to the VO to relay "extra" events from VO to player. Use it to notify the core of window resizes, which in turn will be used to mark all affected properties ("window-scale" in this case) as changed. (I refrained from hacking this as internal command into input_ctx, or to poll the state change, etc. - but in the end, maybe it would be best to actually pass the client API context directly to the places where events can happen.)
* vo_direct3d: support nv12/nv21 directlywm42014-10-261-0/+8
|
* vo_direct3d: allow resizing before video initwm42014-08-061-1/+1
| | | | | | | This can just happen in the time between VO creation, and the first call to vo_reconfig. It seems the recent threading changes exposed this bug. Fixes #986.
* win32: never call GetClientRect(0, ...)wm42014-08-061-1/+2
| | | | | | | | | | | | | | | | | Sometimes GetClientRect() appeared to fail during init, and since we don't check GetClientRect() calls (because they're on our own window, and logically can never fail), bogus resizes were triggered. This could cause vo_direct3d to fail initialization. The reason was that w32->window was set to 0 during early window initialization: CreateWindow*() can send messages to the new window, even though it hasn't returned yet. This means w32->window is not yet set to our window handle, and functions in WndProc may accidentally pass hwnd=0 to win32 API functions. Fix it by initializing w32->window on opportunity. This also means we always strictly expect that the WndProc is used with our own window only.
* win32: make private struct private, refactorwm42014-07-261-4/+4
| | | | | | | | | | | | | | | | Preparation for moving win32 windowing to a separate thread. The codesize is reduced a bit, because some small functions are inlined, which reduces noise. The main change is that now most functions use the private struct directly, instead of accessing it indirectly through vo->w32. Accesses to vo are minimalized. The final goal is adding some sort of new windowing backend API. It would be cleaner to use that as context pointer for all functions (like struct vo was previously used), but since this is work in progress, we just go with this commit.
* video/out: fix redrawing with no video frame for some VOswm42014-06-181-1/+3
| | | | | | With the change to merge osd drawing into video frame drawing, some bogus logic got in: they skipped drawing the OSD if no video frame is available. This broke --no-video --force-window mode.
* vo: make draw_image and vo_queue_image transfer image ownershipwm42014-06-171-2/+5
| | | | Basically a cosmetic change. This is probably more intuitive.
* video: introduce failure path for image allocationswm42014-06-171-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Until now, failure to allocate image data resulted in a crash (i.e. abort() was called). This was intentional, because it's pretty silly to degrade playback, and in almost all situations, the OOM will probably kill you anyway. (And then there's the standard Linux overcommit behavior, which also will kill you at some point.) But I changed my opinion, so here we go. This change does not affect _all_ memory allocations, just image data. Now in most failure cases, the output will just be skipped. For video filters, this coincidentally means that failure is treated as EOF (because the playback core assumes EOF if nothing comes out of the video filter chain). In other situations, output might be in some way degraded, like skipping frames, not scaling OSD, and such. Functions whose return values changed semantics: mp_image_alloc mp_image_new_copy mp_image_new_ref mp_image_make_writeable mp_image_setrefp mp_image_to_av_frame_and_unref mp_image_from_av_frame mp_image_new_external_ref mp_image_new_custom_ref mp_image_pool_make_writeable mp_image_pool_get mp_image_pool_new_copy mp_vdpau_mixed_frame_create vf_alloc_out_image vf_make_out_image_writeable glGetWindowScreenshot
* video/out: change aspects of OSD handlingwm42014-06-151-5/+7
| | | | | | | | | Let the VOs draw the OSD on their own, instead of making OSD drawing a separate VO driver call. Further, let it be the VOs responsibility to request subtitles with the correct PTS. We also basically allow the VO to request OSD/subtitles at any time. OSX changes untested.
* video: synchronize mpv rgb pixel format names with ffmpeg nameswm42014-06-141-3/+3
| | | | | | | | | | | This affects packed RGB formats up to 16 bits per pixel. The old mplayer names used LSB-to-MSB order, while FFmpeg (and some other libraries) use MSB-to-LSB. Nothing should change with this commit, i.e. no bit order or endian bugs should be added or fixed. In some cases, the name stays the same, even though the byte order changes, e.g. RGB8->BGR8 and BGR8->RGB8, and this affects the user-visible names too; this might cause confusion.
* win32: don't use VOCTRL_UPDATE_SCREENINFOwm42014-05-061-1/+1
| | | | Not very tested. At least it compiles.
* Fix some libav* include statementswm42014-04-191-4/+4
| | | | | | | | | | | | | Fix all include statements of the form: #include "libav.../..." These come from MPlayer times, when FFmpeg was somehow part of the MPlayer build tree, and this form was needed to prefer the local files over system FFmpeg. In some cases, the include statement wasn't needed or could be replaced with mpv defined symbols.
* Fix compilation on OSX and win32wm42014-03-291-1/+1
| | | | Probably.
* video/out: remove legacy colorspace stuffwm42014-03-291-13/+14
| | | | | | | | | Reduce most dependencies on struct mp_csp_details, which was a bad first attempt at dealing with colorspace stuff. Instead, consistently use mp_image_params. Code which retrieves colorspace matrices from csputils.c still uses this type, though.
* video/out: do remaining config to reconfig replacementswm42014-01-241-22/+10
| | | | | | | The main difference between the old and new callbacks is that the old callbacks required passing the window size, which is and always was very inconvenient and confusing, since the window size is already in vo->dwidth and vo->dheight.
* video/out: don't access aspdat in VOswm42014-01-221-4/+4
| | | | | | | | | | | vo->aspdat is basically an outdated version of vo->params, plus some weirdness. Get rid of it, which will allow further cleanups and which will make multithreading easier (less state to care about). Also, simplify some VO code by using mp_image_set_attributes() instead of caring about display size, colorspace, etc. manually. Add the function osd_res_from_image_params(), which is often needed in the case OSD renders into an image.
* sub: uglify OSD