summaryrefslogtreecommitdiffstats
path: root/video/out/vo_direct3d.c
Commit message (Collapse)AuthorAgeFilesLines
* 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 code path with lockingwm42014-01-181-1/+1
| | | | | | | | | | | | | | | Do two things: 1. add locking to struct osd_state 2. make struct osd_state opaque While 1. is somewhat simple, 2. is quite horrible. Lots of code accesses lots of osd_state (and osd_object) members. To make sure everything is accessed synchronously, I prefer making osd_state opaque, even if it means adding pretty dumb accessors. All of this is meant to allow running VO in their own threads. Eventually, VOs will request OSD on their own, which means osd_state will be accessed from foreign threads.
* Split mpvcore/ into common/, misc/, bstr/wm42013-12-171-1/+1
|
* Move options/config related files from mpvcore/ to options/wm42013-12-171-2/+2
| | | | | | | | | Since m_option.h and options.h are extremely often included, a lot of files have to be changed. Moving path.c/h to options/ is a bit questionable, but since this is mainly about access to config files (which are also handled in options/), it's probably ok.
* Rename sub.c/.h to osd.c/.hwm42013-11-241-1/+1
| | | | | This was way too misleading. osd.c merely calls the subtitle renderers, instead of actually dealing with subtitles.
* m_config: refactor option defaults handlingwm42013-10-241-2/+8
| | | | | | | | | | | | | Keep track of the default values directly, instead of creating a new instance of the option struct just to get the defaults. Also get rid of the special handling of m_obj_desc.init_options. Instead, handle it purely by the option parser. Originally, I wanted to handle --vo=opengl-hq and --vo=direct3d_shaders with this (by making them aliases to the real VOs with a different preset), but since --vo =opengl-hq=help prints the wrong values (as consequence of the simplification), I'm not doing that, and instead use something different.
* video/out: remove useless info struct and redundant fieldswm42013-10-231-14/+4
| | | | The author and comment fields were printed only in -v mode.
* video/out: always support redrawing VO window at any pointwm42013-10-021-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | Before, a VO could easily refuse to respond to VOCTRL_REDRAW_FRAME, which means the VO wouldn't redraw OSD and window contents, and the player would appear frozen to the user. This was a bit stupid, and makes dealing with some corner cases much harder (think of --keep-open, which was hard to implement, because the VO gets into this state if there are no new video frames after a seek reset). Change this, and require VOs to always react to VOCTRL_REDRAW_FRAME. There are two aspects of this: First, behavior after a (successful) vo_reconfig() call, but before any video frame has been displayed. Second, behavior after a vo_seek_reset(). For the first issue, we define that sending VOCTRL_REDRAW_FRAME after vo_reconfig() should clear the window with black. This requires minor changes to some VOs. In particular vaapi makes this horribly complicated, because OSD rendering is bound to a video surface. We create a black dummy surface for this purpose. The second issue is much simpler and works already with most VOs: they simply redraw whatever has been uploaded previously. The exception is vdpau, which has a complicated mechanism to track and filter video frames. The state associated with this mechanism is completely cleared with vo_seek_reset(), so implementing this to work as expected is not trivial. For now, we just clear the window with black.
* Some more mp_msg conversionswm42013-08-231-78/+61
| | | | | Also add a note to mp_msg.h, since it might be not clear which of the two mechanisms is preferred.
* core: move contents to mpvcore (2/2)Stefano Pigozzi2013-08-061-3/+3
| | | | Followup commit. Fixes all the files references.
* video/out: remove options argument from preinit()wm42013-07-221-1/+1
| | | | | All VOs use proper option parsing now, and compatibility hacks are not needed.
* vo_direct3d: use new option APIwm42013-07-221-85/+34
|
* vo_direct3d: fix warning on MinGWwm42013-07-221-5/+0
| | | | | | Commit 6ab2eeb attempted to fix it on Cygwin, but now it broke on MinGW in turn. Don't think too hard about it and just remove the code. (vo.c already prints the video rectangle anyway.)
* direct3d: Fixes format string that assumed sizeof(LONG) == sizeof(long)Diogo Franco (Kovensky)2013-07-201-1/+2
|
* w32: use vo_w32_control() for all VOswm42013-05-261-32/+11
|
* video: remove aspect.h includes from files which don't need itwm42013-03-171-1/+0
|
* core: simplify OSD capability handling, remove VFCAP_OSDwm42013-03-011-11/+2
| | | | | | | | | | | | | | | | | | | VFCAP_OSD was used to determine at runtime whether the VO supports OSD rendering. This was mostly unused. vo_direct3d had an option to disable OSD (was supposed to allow to force auto-insertion of vf_ass, but we removed that anyway). vo_opengl_old could disable OSD rendering when a very old OpenGL version was detected, and had an option to explicitly disable it as well. Remove VFCAP_OSD from everything (and some associated logic). Now the vo_driver.draw_osd callback can be set to NULL to indicate missing OSD support (important so that vo_null etc. don't single-step on OSD redraw), and if OSD support depends on runtime support, the VO's draw_osd should just do nothing if OSD is not available. Also, do not access vo->want_redraw directly. Change the want_redraw reset log