summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* libmpcodecs: rename IMGFMT_GBR24P to IMGFMT_GBRPwm42012-03-257-11/+11
| | | | This is more in line with the ffmpeg/libav names.
* vf_scale: prefer converting GBR24P to other 8 bit per component RGB formatsreimar2012-03-251-0/+4
| | | | | | | | Compared to converting to Y444 this should be faster and lossless. Based on patch by Hans-Kristian Arntzen [maister archlinux us] git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34317 b3059339-0415-0410-9bf9-f77b7e298cf2
* libmpcodecs: support planar GBR24 decodingcehoyos2012-03-257-1/+13
| | | | | | | | | git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34245 b3059339-0415-0410-9bf9-f77b7e298cf2 Note: ffmpeg first introduced PIX_FMT_GBR24P, which was used in this commit. Later, it was renamed to PIX_FMT_GBRP in ffmpeg and libav. This was updated in revision 34492 in mplayer, but the mplayer specific names (such as IMGFMT_GBR24) were left unchanged.
* mixer: remove useless includeswm42012-03-191-6/+1
| | | | These have been unneeded ever since 2004.
* ao_openal: allow setting the OpenAL sub-devicewm42012-03-171-2/+28
| | | | | | | | Now "-ao openal:device=<subdevice>" will pass <subdevice> as device to OpenAL. This allows selecting both the OpenAL backend (OS-level audio API) and the physical output device. The available devices can be listed with "-ao openal:device=help".
* ao_dsound: fix volume controlswm42012-03-171-5/+7
| | | | | | | | | | | | The recent changes in mixer.c require the AO to return a volume of exactly 0 when audio has been muted. Rather than adding just another special case to mixer.c, fix ao_dsound.c to return previously set volumes exactly. Because DirectSound volume control is not connected with the system mixer, which could change the volume without mplayer knowing, reading the volume back from DirectSound is pointless. Also, the code tried to calculate log10(0). Clip the volume to 1, which results in -10000, DirectSound's definition of silence.
* ao_dsound: don't repeat parts of the audio buffer when playback endswm42012-03-171-24/+34
| | | | | | | | | When layback of a file ends, the audio output doesn't receive new audio data, but the rest of the data must be played properly. ao_dsound.c doesn't handle this properly: DirectSound will continue to play the ringbuffer, even if mplayer doesn't write any data. There's no explicit way to prevent such a buffer underrun. Try to detect it and stop playback.
* 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 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.
* windows support: use UTF-8 for screenshot filenameswm42012-03-171-0/+2
|
* 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-1661-550/+747
|\ | | | | | | | | | | | | | | 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.
| * configure: fix --enable-staticUoti Urpala2012-03-091-3/+2
| | | | | | | | | | Hack around shell programming breakage that made Libav check fail with --enable-static.
| * configure: disable live555 by defaultUoti Urpala2012-03-091-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Latest liblivemedia version disables APIs we need. The code still exists in the library and the changelog says the old interface can be enabled with "#define RTSPCLIENT_SYNCHRONOUS_INTERFACE". However, the code on the library side is disabled by default too, and seems to be disabled in distro packages, so defining that in the player does not help (just delays the failure until link time). It's possible the distro packages will be changed to enable this, but since dropping live555 support is desirable anyway, change configure to disable support by default at least for now. The live555 code is the only part of the source that's in C++. Including C headers in code compiled as C++ has caused issues at times, so deleting this code would have a maintenance benefit. Reportedly the rtsp support in Libav has improved, so there should be less need for live555.
| * core: remove old EDL mode (--edl option)Uoti Urpala2012-03-098-295/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove the old EDL implementation that was activated with the --edl option. It is mostly redundant and inferior compared to the newer demux_edl support, though currently there's no support for using the same EDL files with the new implementation and the mute functionality of the old implementation is not supported. The main reason to remove the old implementation at this point is that the mute functionality would conflict with following audio volume handling changes, and working on the old code would be a wasted effort in the long run as at some point it would be removed anyway. The --edlout functionality is kept for now, even though after this commit there is no code that could directly read its output.
| * af: fix crash when trying to use volume controls with AC3 pass-throughwm42012-03-091-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Changing the volume when softvol is enabled or if the audio output driver doesn't support volume controls causes insertion of the "volume" filter. This fails with AC3. Since the filter wasn't removed after that, and the filter chain was in a bogus state, random crashes occured past this point. Fix it by reinitializing the filter chain completely on failure. Volume controls simply won't work. (This can't be fixed, because AC3 is a compressed format, and would require additional decoding/encoding passes in order to support arbitrary volume changes.) This also affects balance controls.
| * af: print audio filter chain in verbose modewm42012-03-091-0/+35
| | | | | | | | The string format used in print_fmt() is taken from init_audio_filters().
| * windows: terminal: unicode, --msgcolor, size changeMartin Herkt2012-03-094-27/+163
| | | | | | | | | | | | | | Make mp_msg() support unicode output, --msgcolor and variable screen sizes.