summaryrefslogtreecommitdiffstats
path: root/libvo
Commit message (Collapse)AuthorAgeFilesLines
* Merge remote-tracking branch 'origin/master'wm42012-04-019-1517/+165
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: bstr.c bstr.h etc/input.conf input/input.c input/input.h libao2/ao_pulse.c libmpcodecs/vf_ass.c libmpcodecs/vf_vo.c libvo/gl_common.c libvo/x11_common.c mixer.c mixer.h mplayer.c
| * cocoa_common: update screen info before entering fullscreenStefano Pigozzi2012-03-251-0/+1
| | | | | | | | | | | | If the user moved the window to another screen, fullscreen mode would still use the original screen. Fix to use the screen the window is currently on (unless overridden by --xineramascreen).
| * VO: move gl+cocoa before corevideo in default VO orderStefano Pigozzi2012-03-251-1/+4
| | | | | | | | | | | | | | | | | | The gl video output is faster and has more features than corevideo, so it should be preferred on mac osx. This doesn't affect GUI compatibility because they specify the corevideo video output along with the suboptions for the shared buffer name to mmap in.
| * cocoa_common: add license informationStefano Pigozzi2012-03-252-0/+38
| |
| * vo_quartz: remove this video outputStefano Pigozzi2012-03-252-1375/+0
| | | | | | | | | | | | | | | | | | This video output is not useful anymore. It is based on Carbon to draw the mplayer window and this has been deprecated by Apple in 10.5. The upcoming 10.8 OSX release should deprecate most of Carbon, so it doesn't make sense to keep vo_quartz in the codebase when there are modern and better alternatives (vo_gl and vo_corevideo).
| * cocoa_common: fix double click handlingStefano Pigozzi2012-03-251-8/+8
| | | | | | | | | | | | | | The Cocoa framework generates only a NS*MouseDown event when handling the second click of a double click (no NS*MouseUp). If that's the case put mouse up key in mplayer2's fifo when dealing with the MouseDown Cocoa event.
| * cocoa_common: accept window drag event from the whole window surfaceStefano Pigozzi2012-03-251-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | Change the window to accept mouse drag events not only on the title bar, but also on the rest of the window surface; this includes the video area. It looks like the changing of the window mask resets the behaviour specified in the delegate method, probably due to some strange interaction with NSBorderlessWindow. For this reason call -setPresentationOptions in the -fullscreen method to remind cocoa the behaviour we want.
| * options, x11+cocoa: add option --cursor-autohide-delayStefano Pigozzi2012-03-253-16/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add option --cursor-autohide-delay to control the number of milliseconds with no user interaction before the mouse cursor is hidden. There are two negative values with useful special meanings: * A value of -1 prevents the cursor from hiding (useful for users with multiple displays). * A value of -2 prevents the cursor from showing upon activity. The default is 1 second to keep the behaviour consistent with the past X11 backend implementation. Remove the vo_mouse_autohide field as it was always true.
| * x11: remove wskeys.hwm42012-03-252-107/+20
| | | | | | | | | | Use the <X11/keysym.h> xlib header instead. I'm not sure why mplayer defined these constants itself.
| * x11: input: add print and menu keyswm42012-03-251-0/+1
| |
| * x11: add KP_Separator to key mappingwm42012-03-252-0/+2
| | | | | | | | | | | | | | | | | | | | | | At least on some keyboards, the key between '0' and 'Enter' on the key pad is mapped to KP_Separator. Since X11 VOs accept unicode input, the mplayer keycode this key generates depended on the numlock state, and with numlock enabled this mapped to an ASCII character. This is probably not what the user wanted, since two physical keys will always map to the same key code. Map it to KP_DEC.
| * x11: allow unicode inputwm42012-03-252-29/+49
| | | | | | | | | | | | | | | | | | This change allows using non-ASCII keys with X11. These keys were ingored before. Technically, this creates an invisible, non-interactive input method context. If creation fails, the code falls back to the old method, which allows a subset of ASCII only.
| * x11: fix setting UTF-8 window titles for some special caseswm42012-03-251-29/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * vo_gl: cocoa: add support for --ontopStefano Pigozzi2012-03-253-4/+33
| | | | | | | | | | Make the cocoa backend change the non-fullscreen window level according to the value of the ontop property.
| * vo_xv: remove direct rendering supportUoti Urpala2012-03-251-111/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Direct rendering support in vo_xv (used with --dr) had at least two problems. First, OSD drawing modified the buffers; this meant that if the buffers were used for reference frames there would be video corruption. I don't think "performance optimization" with this level of drawbacks is appropriate with today's machines any more. Direct rendering could still be used for non-reference frames, but there's a second problem: with direct rendering enabled the same buffer is used for every frame, and with the XShm extension that is used by default there's no checking that the previous frame has been completely uploaded to the graphics card before it's overwritten by the next one. This could be fixed, but as Xv is becoming obsolete I don't see it as a priority to improve it. Thus I'm simply removing the parts of functionality that were more likely to break things than improve playback.
| * cosmetics: misc minor cleanupsUoti Urpala2012-03-251-1/+0
| | | | | | | | | | The deleted ZRM* things were only relevant to vo_zr, which was deleted earlier.
| * core: restructure main play loop, continue audio after videoUoti Urpala2012-03-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | Restructure parts of the code in the main play loop. The main functionality difference is that if a video track ends first, now audio will continue to be played until it ends too. Now the process also wakes up less often if there's no need to update video or audio. This will reduce unnecessary wakeups especially when paused, but may make handling of input events laggier when fd-based notifications are not supported (like most input on Windows).
* | gl_common: minor cleanup/refactorwm42012-03-312-64/+44
| | | | | | | | | | | | | | | | | | Remove all platform/GUI specific includes from gl_common.h. Get rid of the ugly union in MPGLContext. Use function pointers instead of an ifdef ridden switch statement in uninit_mpglcontext(). Always include glext.h, not only on Windows. None of this should actually change any functionality.
* | gl_common: remove unused glValName()wm42012-03-312-58/+0
| | | | | | | | Using helper programs like apitrace is better for debugging.
* | gl_common: move header hacks into gl_header_fixes.hwm42012-03-312-208/+232
| | | | | | | | | | Keep this horrible (but unfortunately necessary) kludge out of the main code.
* | libvo: add vo_gl3wm42012-03-317-0/+3082
| | | | | | | | | | | | | | | | | | This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
* | gl_common: cocoa: add OpenGL 3.2 context creation codeStefano Pigozzi2012-03-313-10/+53
| | | | | | | | | | Add a new option to the cocoa window creation code in order to decide which OpenGL context to create.
* | gl_common: slightly change win32 GL 3 context creationwm42012-03-312-18/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The code used OpenGL 3 specific functions for querying the extension string when the actual GL 3 context wasn't created yet. This appears to work fine on nVidia, but could break otherwise. Remove the offending getFunctions call and retrieve the needed function pointer manually. (This way the wglCreateContextAttribsARB function pointer can be removed from struct GL too.) (Amusingly exposes a wine bug; they made the same mistake.) Explicitly check the extension string whether the function is available, although this probably doesn't matter in practice. Also retrieve bit depth information on win32.
* | gl_common: OpenGL 3.x context support on windowsKovensky2012-03-312-1/+107
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Also include GL/glext.h on windows: Mingw's (and cygwin's) GL/gl.h has GL/glext.h's inclusion commented out for some reason. Their glext.h is also ancient, so do yourself a favor and replace your GL/glext.h with the one from http://www.opengl.org/registry/api/glext.h . A workaround is needed for NVidia's broken wglCreateContextAtrribsARB: It'll return an error if the requested OpenGL version is previous to 3.2 *and* you request a profile... which is exactly *not* what the wgl_create_context spec says should happen. Handle it by removing the profile request from attribs[] and retrying the context creation once more if the first try fails. And after my first foray into OpenGL I already find a driver quirk. Oh well.
* | gl_common: add OpenGL 3.x context creationwm42012-03-312-117/+423
| | | | | | | | | | | | | | | | | | | | Also add a bunch of GL functions to the function loader, which will be needed by vo_gl3. Remove some unused legacy GL functions from the loader. Use the proper name for glGetProgramivARB. glGetProgramiv is a different and incompatible function. The ARB variant is used for ARB shaders, while the proper one is for GLSL.
* | vo_direct3d: fix crash when using RGB formatswm42012-03-261-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | The function mp_get_yuv2rgb_coeffs() expects valid values for input_bits. When using RGB formats, input_bits is outside the range of what mp_get_yuv2rgb_coeffs() expects. This doesn't matter since we don't use the result of that function in the RGB case, but it triggered an assertion. This is a regression from commit a8168102668337f3c1, "vo_gl: improve 10-bit YUV->RGB conversion accuracy slightly".
* | windows support: prefer vo_direct3d_shaders over vo_direct3dwm42012-03-171-1/+1
| | | | | | | | | | Since "direct3d" has broken color levels with some drivers, and there is no simple fix for this, prefer "direct3d_shaders".
* | vo_direct3d: fix bug in screenshot code with some pixel formatswm42012-03-171-1/+1
| | | | | | | | | | | | A typo caused the height of the image copy to be incorrectly calculated with some less common pixel formats, when X chroma shift != Y chroma shift.
* | vo_direct3d: fix crash when repeatedly reinitializing an uncooperative devicewm42012-03-171-2/+4
| |
* | vo_direct3d: stop D3D from switching the FPU to single precision modewm42012-03-171-1/+2
| | | | | | | | | | | | | | | | | | | | | | Add the flag D3DCREATE_FPU_PRESERVE, which tells Direct3D not to switch the FPU to single precision mode. Single precision mode would mean that all floating point calculations are done in float precision, even if using double variables. The MSDN documentation seems to discourage use of this flag with scary warnings about bad performance and stability, but I suspect in practice switching off this completely unreasonable behavior is fine.
* | vo: fix EOSD change detectionwm42012-03-171-29/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The case when the EOSD sub-images changed position, but didn't need re-upload, wasn't handled correctly. If a subtitle script made text move over the screen (without any other changes), the subtitle display wasn't updated. vo_vdpau was not affected, because vdpau directly reads the sub-image positions on every frame. The fix could be simpler. It could recreate the vertex array every frame. This commit keeps the optimization that nothing is done when the libass native change detection doesn't report any change. Maybe this optimization isn't worth doing, since recreating the vertex array is relatively cheap compared to amount of work required to render complicated subtitles. The eosd_packer_generate function returning 3 boolean flags is ugly.
* | win32: properly set window titlewm42012-03-172-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | Set the window title on win32 based VOs using the same logic as on X11 and Cocoa. Until now, the window title when using vo_direct3d and vo_gl was hardcoded to "MPlayer - The Movie Player", and vo_directx showed "MPlayer". Now it will show "mplayer2", unless the --title or --use-filename-title options are used. Change the internal window class name to the string "mplayer2" too.
* | vo_direct3d: implement screenshotswm42012-03-171-0/+186
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are 4 code paths when taking a screenshot: - textured rendering mode - StretchRect rendering mode with planar formats - StretchRect with packed formats - full-window screenshot mode The implementation of the full-window mode (capturing the window contents, instead of the video) is very inefficient: it will create a surface of desktop size, copy the desktop contents, allocate a new memory image, and copy in the window contents. The code in screenshot.c will (as of now) allocate and convert the image from BGR to RGB, and allocate a destination buffer for the libavcodec PNG writer. If parts of the mplayer window are obscured, the full-window mode wil contain these parts as seen on the screen. Parts of the window that are outside the bounds of the desktop are clipped away. It is not known whether full-window mode works on multi-monitor setups.
* | win32: fix fullscreen not working on Windows 7wm42012-03-171-2/+2
| | | | | | | | | | | | | | | | | | Switching to fullscreen mode on Windows 7 didn't work: the window position and size weren't set to fullscreen. It turns out that merely calling SetWindowLong caused windows to send move/resize messages, which changed the global variables that were supposed to contain the new window size. Move the SetWindowLong call out of the way to guarantee that always the correct values are used.
* | vo_direct3d: fix dealing with uncooperative deviceswm42012-03-171-6/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the Direct3D device is "lost" (e,g, when minimizing mplayer, or when another application uses Direct3D exclusive mode), we free it and try to recrate the device. This can fail, and may fail for an extended period of time, until D3D is available again and the device can be created. So we basically have to provide all VO functionality while d3d_device is NULL. Don't terminate if device creation fails, and re-add the NULL checks that were removed in the commit "vo_direct3d: refactor D3D initialization and reconfigure code". If mplayer calls the VO's config() while the D3D device can not be created, the VO will return an error and mplayer will terminate. config() is typically called when new files are played, when ordered chapter boundaries are crossed, or on other events.
* | vo_direct3d: add hack for using 2 channel textures for 10 bit pixel formatswm42012-03-173-8/+272
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This actually applies to YUV formats with 9-16 bit depths. This hack is disabled by default, and the VO will use 16 bit textures normally. It can be enabled by passing the no16bit-textures option is passed to vo_direct3d. Then the VO will use D3DFMT_A8L8 as texture formats for the YUV plane (instead of D3DFMT_L16), and compute the sampled two color values back into one. In some cases it might be undesireable to use 16 bit texture formats. At least some OpenGL drivers on Linux (Mesa + Intel) round values sampled from 16 bit textures back into 8 bit, which loses 8 from 10 bit color information when playing 10 bit formats. It is unknown whether there are D3D9 drivers which do this, so this commit might be removed later.
* | vo_direct3d: add some debugging optionswm42012-03-171-12/+53
| | | | | | | | | | This is for testing. Most of these make no sense, or even if they do, might not improve anything.
* | 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 form