summaryrefslogtreecommitdiffstats
path: root/libvo
Commit message (Collapse)AuthorAgeFilesLines
* vo_direct3d: refactor D3D initialization and reconfigure codewm42012-03-171-171/+111
| | | | | | | | | | | | | | | | | | | | | | | | | This simplifies the code and removes code duplication. There should be no actual semantic differences to the previous code. The only exception is that the new code doesn't query the display adapter's desktop pixel format on backbuffer resizing anymore. In my opinion the format can never change anyway, and if it does, it will cause the D3D device to become "uncooperative" and we will recreate it in flip_page. Remove attempts to handle d3d_device when it's NULL (outside of the initialization paths). d3d_device can only be NULL if recreating a D3D device, that was in "incooperative" state, fails. The current (and previous) code seems to assume that this never happens. It is unlikely that these NULL checks improved correct operation in any way, or at least they won't anymore after the recent changes done to the code. If it should be possible that a device can't be reset/recreated for a while (during display resolution changes? when another D3D application is in fullscreen mode?), another solution has to be found. It is unknown why the code recreates the IDirect3D9 interface when the device was uncooperative. At least on Windows XP + reference rasterizer, resuming works without recreating it. Leave this code just in case.
* vo_direct3d: disable using shaders by default, and add direct3d_shaders VOwm42012-03-172-10/+44
| | | | | | | | | | | | | | Now using the "direct3d" VO will never make use of shaders. Instead, users are supposed to use the direct3d_shaders VO entry, which is exactly the same as direct3d, except with shaders enabled by default. "direct3d" always uses the Direct3D StretcRect API call to render videos. Playing formats not supported by this function will force mplayer to insert a scale filter to convert video frames in software. "direct3d_shaders" prefers shader color conversion, but can fall back to StretchRect if the format can be handled. (This happens only with some insignificant packed YUV formats.)
* vo_direct3d: use new VO API, and do some minor reformattingwm42012-03-171-269/+298
| | | | | | | | | | | | | | | | The minor reformats are mainly about adding more line breaks to fit a 80 column limit. Using the new VO API implies removing all non-const global variables (because that is one important goal of the new API), so do that as well. The code already had all variables in a context struct, and changing all the functions to pass this context struct along was all what had to be done. Also handle redrawing properly: if something changes that requires an immediate redrawing operation (e.g. setting video equalizers when paused or when playback is slow), vo->want_redraw should be set, instead of redrawing on your own.
* vo_direct3d: implement YUV conversion using shaderswm42012-03-173-192/+842
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Use the 3D rendering functions and shaders to render the video frame. This is very similar to vo_gl. Most planar formats with varying chroma shifts and bit depths are supported (including 10 bit), as well as some RGB formats. The old code that used D3D's StretchRect function is still available, but will by default be used with the least priority. Also implement video equalizers and colorspace selection. These use the same code as vo_gl and vo_vdpau, and are available only if shader YUV conversion is active. The rendering is extremely simple and naive, there are no filters etc. Since compiling shaders seems to require the 500 MB DirectX SDK, all shaders come in pre-compiled form, and there is no make rule to compile them. mplayer should be compilable without 500 MB of garbage. The main problem is that compiling shaders within an application seems to require d3dx9_*.dll, which isn't installed by default. Add an option ("disable-texture-align") that allows making the video textures exactly the same size as the source video. The code used to align the OSD texture size on 16 for unknown reasons, but since this was perhaps a good reason, this behavior is kept for video textures as well. (There is a chance that the alignment improves performance and stability with some drivers.) Passing this option disables this behavior. It is useful for reducing texture filtering artifacts at the bottom/right borders.
* vo_direct3d: reduce number of lock calls in OSD renderingwm42012-03-171-29/+21
| | | | | | The code locked the texture once for each OSD object that was rendered. But there doesn't seem to be any good reason to do that, so lock it only once during OSD rendering.
* vo_direct3d: use the same texture management for EOSD and OSDwm42012-03-171-152/+166
| | | | | | | | | | | | | | | | | | | The OSD code used a shadow texture on systems that don't report D3DDEVCAPS_TEXTURESYSTEMMEMORY. Do that for EOSD as well. Refactor the OSD texture management code to reduce code duplication. I have not the slightest clue about Direct3D9 texture management, so it seems like a good idea not to do something different for EOSD textures, even though the OSD code does exactly the same as far as texture handling goes. It's also worth noting that D3DDEVCAPS_TEXTURESYSTEMMEMORY doesn't seem to be supported by most real systems [1], and maintaining a shadow copy in system memory in order to update textures is required. The previous EOSD texture code may or may not have worked on some or all real systems, I can't really tell by reading the MSDN documentation only. [1] http://www.kludx.com/capability.php?capability=17
* windows support: prefer vo_direct3d over vo_directxwm42012-03-171-3/+3
|
* vo_direct3d: make VO re-config faster by not recreating the whole D3D statewm42012-03-171-36/+38
| | | | | | | | | | | The D3D state (the IDirect3DDevice9 and all textures and buffers) were released and recreated in the config() function. This is completely unnecessary. Instead explicitly handle changes. The video surface is only reallocated if the video format or the video size changes. The OSD texture is only reallocated if the window size is increased. The EOSD texture is not released. Since the resize code is reused to deal with reconfig changes, some of these improvements (and possible bugs) apply to normal window resizing as well.
* vo_direct3d: don't framestep when paused and OSD is updatedwm42012-03-171-4/+23
| | | | | | | | | | The required feature for this, VOCTRL_REDRAW_OSD, was unimplemented for unknown reasons. It is trivial to add. There is still a weird issue when switching the fullscreen state while paused. I have no idea why this happens. The contents of the video should survive the window reconfiguration (at least we don't free it), and we explicitly redraw the screen after fullscreen.
* vo_direct3d: add EOSD supportwm42012-03-171-36/+335
| | | | | This allows rendering subtitles in display resolution. It also makes inserting the vf_ass video filter unnecessary.
* vo_direct3d: minor cleanupwm42012-03-171-10/+23
| | | | | | The code assumed the last format passed to query_format will be the one that is used on playback. This is probably true and thus didn't cause any bugs, but make query_format side effect free just like the other VOs.
* vo_directx: do not clip overlay against screen sizewm42012-03-171-3/+1
| | | | | | Clipping it makes the video output look extremely crappy. There seems no good reason to do this, and VirtualBox is fine with overlays larger than the screen.
* win32: different method to force window aspect ratiowm42012-03-171-15/+53
| | | | | | | | | | | | | The code used WM_WINDOWPOSCHANGING to force an spect ratio. This didn't behave well if the left/top window borders were used for resizing. Resizing with these borders changed the screen position of the right/bottom as well, which is unintuitive and annoying. Use WM_SIZING instead. Unlike WM_WINDOWPOSCHANGING, WM_SIZING knows about which border is being used for resizing and can act accordingly. Note that the calculated window size doesn't necessarily match with the size mplayer calculates, but this problem exists on x11 as well.
* win32, vo_directx: don't use vo_dx/dy, directly query window positionwm42012-03-172-9/+9
| | | | | This should be a bit robuster than trying to maintain vo_dx/dy. vo_dy/dy are now completely unused on win32, except for initialization.
* win32: fix window creation and size handlingwm42012-03-171-48/+109
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit fixes various issues with the way the window position and size is setup. Most importantly, it fixes some bugs with restoring from fullscreen state. Rename create_rendering_context() to reinit_window_state(). This function doesn't create anything, it just sets the window bounds and styles. Do not use vo_dx/dy for the window position, as video_out.c overwrites it with each vo_config() call. Use private variables window_x/y instead. A big cause for issues was that reinit_window_state() accidentally cleared the WS_VISIBLE style. I suspect that the API call to temporarily hide the window was a hack to deal with this. Another bug was that the window style was changed without calling SetWindowPos with SWP_FRAMECHANGED (as the MSDN documentation says). Properly initialize window position and size on vo_config following the same rules as the x11 backend: - Never change the window position. The window position should be kept, as the user might move the window, and resetting the window position e.g. during ordered chapter playback is not desired. - Never change the window size, unless the size of the video changes. These rules don't apply to fullscreen. When switching from fullscreen to windowed mode, the backend should restore the previous windowed size and position. When the VO was reconfigured during playback (vo_config() etc.), the saved window position and size should be changed according to the rules above, even if the window was in fullscreen mode during reconfiguring. Note that these rules might be perceived as awkward by some users: if you play multiple files with different resolutions, the window won't be centered when playing the files after the first. This is not a bug.
* vo_directx: minor fixes and reformatreimar2012-03-171-883/+847
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Restore hunk disabling overlay when the Window is minimized. This was accidentally removed in r33657. Fixes bug 1950. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33894 b3059339-0415-0410-9bf9-f77b7e298cf2 Simplify code handling minimized state. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33895 b3059339-0415-0410-9bf9-f77b7e298cf2 Apply uncrustify to vo_directx.c. The vast majority of changes are whitespace changes, but in some cases {} was merged with other lines or a ; was removed after a } from a switch and similar minor and obviously correct changes. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33896 b3059339-0415-0410-9bf9-f77b7e298cf2 Fix array layout uncrustify messed up. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33897 b3059339-0415-0410-9bf9-f77b7e298cf2 Remove pointless () and {}. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33898 b3059339-0415-0410-9bf9-f77b7e298cf2 Make NULL checks simpler/more consistent. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33899 b3059339-0415-0410-9bf9-f77b7e298cf2 Use FFMIN/FFMAX. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33901 b3059339-0415-0410-9bf9-f77b7e298cf2 Simplify struct initialization. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33902 b3059339-0415-0410-9bf9-f77b7e298cf2 Split out read/write part from data struct and make read-only struct const. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33903 b3059339-0415-0410-9bf9-f77b7e298cf2 Store fixed-length string directly in struct, avoid pointer indirection. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33904 b3059339-0415-0410-9bf9-f77b7e298cf2 Replace some inappropriate while() loops with for() git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33905 b3059339-0415-0410-9bf9-f77b7e298cf2 Simplify some more struct initializations. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33906 b3059339-0415-0410-9bf9-f77b7e298cf2 Avoid typedef. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33907 b3059339-0415-0410-9bf9-f77b7e298cf2 Use struct initializer in one more case. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33908 b3059339-0415-0410-9bf9-f77b7e298cf2 Simplify printing of error strings. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33909 b3059339-0415-0410-9bf9-f77b7e298cf2 Conflicts: libvo/vo_directx.c
* Merge remote-tracking branch 'origin/master' into my_masterwm42012-03-168-37/+31
|\ | | | | | | | | | | | | | | Conflicts: command.c mp_core.h mplayer.c screenshot.c
| * vo_gl: improve 10-bit YUV->RGB conversion accuracy slightlyUoti Urpala2012-03-094-17/+16
| | | | | | | | | | | | | | | | | | | | Modify the YUV->RGB conversion matrix to take into account the difference between the same color value being x/255 in a 8-bit texture and x*256/65535 in a 16-bit texture (actually things are stored as x*4/65535 for 10-bit color, but that can be ignored here). This 0.4 % difference in the shader float value could make shades of gray in 10-bit (or generally more than 8 bit) YUV produce RGB values with green slightly higher than red/blue.
| * windows support: unicode filenameswm42012-03-092-11/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Windows uses a legacy codepage for char* / runtime functions accepting char *. Using UTF-8 as the codepage with setlocale() is explicitly forbidden. Work this around by overriding the MSVCRT functions with wrapper macros, that assume UTF-8 and use "proper" API calls like _wopen etc. to deal with unicode filenames. All code that uses standard functions that take or return filenames must now include osdep/io.h. stat() can't be overridden, because MinGW-w64 itself defines "stat" as a macro. Change code to use use mp_stat() instead. This is not perfectly clean, but still somewhat sane, and much better than littering the rest of the mplayer code with MinGW specific hacks. It's also a bit fragile, but that's actually little different from the previous situation. Also, MinGW is unlikely to ever include a nice way of dealing with this.
| * cleanup: Silence compilation warnings on MinGW-w64wm42012-03-012-9/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some of the code, especially the dshow and windows codec loader parts, are extremely hacky and likely full of bugs. The goal is merely getting rid of warnings that could obscure more important warnings and actual bugs, instead of fixing actual problems. This reduces the number of warnings from over 500 to almost the same as when compiling on Linux. Note that many problems stem from using the ancient wine-derived windows headers. There are some differences to the "proper" windows header. Changing the code to compile with the proper headers would be too much trouble, and it still has to work on Unix. Some of the changes might actually break compilation on legacy MinGW, but we don't support that anymore. Always use MinGW-w64, even when compiling to 32 bit. Fixes some warnings in the win32 loader code on Linux too.
* | Merge remote-tracking branch 'origin/master' into my_masterwm42012-03-054-14/+26
|\| | | | | | | | | | | Conflicts: mplayer.c screenshot.c
| * vo_png: set AVCodecContext parameters before opening itUoti Urpala2012-02-281-19/+21
| | | | | | | | | | | | | | Instead of opening avctx in preinit() and setting paramters later, (re)open it in config() where parameters can be set first. This fixes a failure to open the codec with new libavcodec versions that check pix_fmt during avcodec_open2().
| * vo: reject vo_redraw_frame() if no frames have been drawnUoti Urpala2012-02-282-1/+4
| | | | | | | | | | | | | | | | vo_xv crashed if existing frames had been lost due to a config() call in the middle of a file and vo_redraw_frame() was called. Add checks to reject vo_redraw_frame() unless at least one frame has been flipped after the the last configuration change, so individual VOs do not have to deal with this case.
| * build: switch to libavutil bswap.h and intreadwrite.hUoti Urpala2012-02-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Remove the private bswap and intreadwrite.h implementations and use libavutil headers instead. Originally these headers weren't publicly installed by libavutil at all. That already changed in 2010, but the pure C bswap version in installed headers was very inefficient. That was recently (2011-12) improved and now using the public bswap version probably shouldn't cause noticeable performance problems, at least if using a new enough compiler.
| * Update Libav API usesUoti Urpala2012-02-011-5/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change various code to use the latest Libav API. The libavcodec error_recognition setting has been removed and replaced with different semantics. I removed the "--lavdopts=er=<value>" option accordingly, as I don't think it's widely enough used to be worth attempting to emulate the old option semantics using the new API. A new option with the new semantics can be added later if needed. Libav dropped APIs that were necessary with all Libav versions until quite recently (like setting avctx->age), and it would thus not be possible to keep compatibility with previous Libav versions without adding workarounds. The new APIs also had some bugs/limitations in the recent Libav release 0.8, and it would not work fully (at least some avcodec options would not be set correctly). Because of those issues, this commit makes no attempt to maintain compatibility with anything but the latest Libav git head. Hopefully the required fixes and improvements will be included in a following Libav point release.
* | mpcodecs: remove mp_image_t.x/ywm42012-02-246-18/+16
| | | | | | | | These were never used.
* | x11: fix crash when using switch_video (broken by UTF-8 input changes)wm42012-02-241-0/+1
| |
* | vo_gl: add "backend" suboption to allow selecting the GUI backendwm42012-02-094-35/+54
| | | | | | | | | | | | | | | | | | | | | | | | The "backend" suboption allows selecting the GUI backend used by vo_gl. Normally, it's auto-selected, but sometimes it's desireable to explicitly select it. Remove the gl_sdl VO. This can now be done by using: --vo=gl:backend=sdl This is based on svn commit 34438, and tries to be compatible with it. The undocumented numeric backend names serve this purpose. (They are undocumented because names are preferred.)
* | vo_gl: minor cleanupsreimar2012-02-093-22/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix spelling. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34006 b3059339-0415-0410-9bf9-f77b7e298cf2 Fix disabled code. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34007 b3059339-0415-0410-9bf9-f77b7e298cf2 Remove pointless pointer indirection for shader program strings. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34016 b3059339-0415-0410-9bf9-f77b7e298cf2 Remove usage of glColor3f, there is not really a point in it. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34149 b3059339-0415-0410-9bf9-f77b7e298cf2
* | vo_gl: add noise filterreimar2012-02-093-13/+81
| | | | | | | | | | | | | | | | | | | | Add disabled feature: noise filter for vo_gl. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34014 b3059339-0415-0410-9bf9-f77b7e298cf2 Hook up -vo gl noise support. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34015 b3059339-0415-0410-9bf9-f77b7e298cf2
* | x11: fix setting UTF-8 window titles for some special caseswm42012-01-251-9/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Setting the WM_NAME/WM_ICON_NAME window properties didn't always work: apparently there are some characters that can't be represented in the X STRING or COMPOUND_TEXT encodings, such as U+2013 EN DASH. The function Xutf8TextListToTextProperty partially converts the string, and returns a value different from 'Success'. This means vo_x11_set_property_string didn't set these window properties. On most modern window managers, this is not a problem, since these use the _NET_WM_NAME/_NET_ICON_NAME and the UTF8_STRING encoding. Some older WMs like IceWM don't read these, and the window title remains blank. It's not clear what exactly we should do in this situation, but fix it by setting set the WM_NAME/WM_ICON_NAME properties as UTF8_TEXT. This violates the ICCCM, but at least IceWM seems to handle this well. See also: http://lists.freedesktop.org/archives/xorg/2004-September/003391.html http://lists.freedesktop.org/archives/xorg/2004-September/003395.html Also fix a minor memory leak when conversion to COMPOUND_TEXT fails.
* | Merge branch 'eosd' into my_masterwm42012-01-186-346/+503
|\ \
| * | vo_gl: use generic eosd codewm42011-12-253-145/+124
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is an experiment. The change probably doesn't matter much. One issue with the old code was that "large" images caused each sub-image to be created and rendered as a new texture. "Large" in this case means larger than 32x32 pixels, which actually isn't very large with screen sizes beyond 1500x1000 pixels. This means rendering a simple subtitle for a fullscreened video may allocate many small textures, one for each glyph. On the other hand, the old code could be fixed by tuning the texture sizes for "modern" work loads. Also, the new code uses less deprecated OpenGL features and draws all sub-images in one batch. There are two possible issues the new code could cause: - Drivers could have performance issues with the larger texture sizes and the number of glTexSubImage2D calls on it - There is only one EOSD texture, which could become full (it's enlarged on demand, but restricted by driver texture size limitations) It has been reported that this is faster on OSX with ATI GPUs than the old code.
| * | libvo, vo_vdpau: make the EOSD packer code from vo_vdpau genericwm42011-12-253-201/+379
| | | | | | | | | | | | | | | | | | | | | The code in eosd_packer.c/.h is taken from vo_vdpau.c and has been made independent from vdpau API specifics. This allows other VOs, which need to pack the small EOSD images into a large surface for efficiency, to use this code.
* | | Merge branch 'utf8_input' into my_masterwm42012-01-183-134/+69
|\ \ \
| * | | x11: remove wskeys.hwm42012-01-182-107/+20
| | | | | | | | | | | | | | |