summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* Add more constwm42014-06-1113-71/+67
| | | | | | | While I'm not very fond of "const", it's important for declarations (it decides whether a symbol is emitted in a read-only or read/write section). Fix all these cases, so we have writeable global data only when we really need.
* vo_caca: remove global variableswm42014-06-111-68/+84
| | | | The shit I put up with...
* options: remove global variables for swscale options; rename themwm42014-06-117-31/+51
| | | | | | Additionally to removing the global variables, this makes the options more uniform. --ssf-... becomes --sws-..., and --sws becomes --sws- scaler. For --sws-scaler, use choices instead of magic integer values.
* video: fix another cover art corner casewm42014-06-091-1/+1
| | | | | | | Playing a video and then an audio file with cover art kept displaying the last frame of the video. This was because the hasframe flag was set, perhaps due to redrawing the last video frame before the cover art image is decoded.
* x11: cleanup motif hints handlingwm42014-06-062-38/+17
| | | | | | | | It seems we can't really get rid of this. There are no other hints to remove decorations that work across all reasonable WMs, so we're stuck with the ugly motif stuff. But at least we can make the code for it less ugly.
* filter_kernels: fix nearest scalerwm42014-06-041-1/+1
| | | | | | | | | | The previous commit assumed the filter would be 1x1 (then constant weight is correct) - but our code in fact uses at least a 2x2 filter. A 1x1 filter would generally be useless, except for nearest scaling - so it didn't exist. Insteasd of adding such a 1x1 filter, just turn the nearest weight function into a scare function, which should take care of the issue.
* filter_kernels: add nearest neighbour scalinglucy2014-06-031-0/+6
| | | | | | This is useful for playing content containing pixel art that hasn't been pre-scaled, such as TASVideos' high quality encodes. The implementation is lifted from <https://code.google.com/p/glumpy/source/browse/glumpy/image/filter.py#413>.
* wayland: remove stub for unimplemented functionwm42014-06-021-15/+0
|
* vo: correctly initialize parameters in corner caseswm42014-06-011-1/+4
|
* player: hide audio/video codec and file format messageswm42014-05-311-2/+1
| | | | | None of these are very important usually. For error analysis, the plain log is useless anyway, and this information is still printed with "-v".
* gl_common: remove dlsym() fallbackwm42014-05-311-21/+1
| | | | See previous commits.
* gl_wayland: remove probably unneeded workaroundwm42014-05-311-2/+0
| | | | | | | | This would imply eglGetProcAddress() doesn't work correctly, but using dlsym() does. For now get rid of it - it won't work in libmpv, and we'll probably need a better workaround if it's still broken. This code was in the initial wayland commit.
* gl_x11: remove workaround for PPC OSX 10.4wm42014-05-311-7/+0
| | | | | Added in 2010 with commit 4a8486f8 (svn commit 30994). I doubt anyone still uses X11 on OSX, and we probably don't support 10.4 either.
* gl_x11: always require some GLX API functions, avoid dlsym()wm42014-05-313-20/+6
| | | | | | | | | | | | | | The functions glXGetProcAddressARB() and glXQueryExtensionsString() were loaded using dlsym(). This could fail when compiling to libmpv, because then dlopen(NULL, ...) will look in the main program's list of libraries, and the libGL linked to libmpv is never considered. (Don't know if this somehow could be worked around.) The result is that using vo_opengl with libmpv can fail. Avoid this by not using dlsym(). glXGetProcAddressARB() was already used directly in the same file, and that never caused any problems. (Still add it to the configure test.) glXQueryExtensionsString() is documented as added in GLX 1.1 - that's ancient.
* vd_lavc: set video bitrate if availableMarcoen Hirschberg2014-05-281-0/+5
| | | | Set the bitrate of dec_video if it is available in avcodec.
* audio: rename i_bps to 'bitrate' to avoid confusionMarcoen Hirschberg2014-05-282-3/+3
| | | | Since i_bps now contains bits/sec, rename it to reflect this change.
* audio: change values from bytes-per-second to bits-per-secondMarcoen Hirschberg2014-05-282-3/+3
| | | | | | | The i_bps members of the sh_audio and dev_video structs are mostly used for displaying the average audio and video bitrates. Keeping them in bits-per-second avoids truncating them to bytes-per-second and changing them back lateron.
* vaapi: fix destruction with --hwdec=haapi-copywm42014-05-281-2/+6
| | | | | | | This is incomplete; the video chain will still hold some vaapi objects after destroying the decoder and thus the vaapi context. This is very bad. Fixing it would require something like refcounting the vaapi context, but I don't really want to.
* video: warn if an emulated hwdec API is usedwm42014-05-2811-4/+48
| | | | | | | | | | | | | | | | mpv supports two hardware decoding APIs on Linux: vdpau and vaapi. Each of these has emulation wrappers. The wrappers are usually slower and have fewer features than their native opposites. In particular the libva vdpau driver is practically unmaintained. Check the vendor string and print a warning if emulation is detected. Checking vendor strings is a very stupid thing to do, but I find the thought of people using an emulated API for no reason worse. Also, make --hwdec=auto never use an API that is detected as emulated. This doesn't work quite right yet, because once one API is loaded, vo_opengl doesn't unload it, so no hardware decoding will be used if the first probed API (usually vdpau) is rejected. But good enough.
* vo_vaapi: cleanup error handling on initwm42014-05-282-4/+10
| | | | Close the X connection if initializing vaapi fails.
* video: better handling for (very) broken timestampswm42014-05-271-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Sometimes, Matroska files store monotonic PTS for h264 tracks with b-frames, which means the decoder actually returns non-monotonic PTS. Handle this with an evil trick: if DTS is missing, set it to the PTS. Then the existing logic, which deals with falling back to DTS if PTS is broken. Actually, this trick is not so evil at all, because usually, PTS has no errors, and DTS is either always set, or always unset. So this _should_ provoke no regressions (famous last words). libavformat actually does something similar: it derives DTS from PTS in ways unknown to me. The result is very broken, but it causes the DTS fallback to become active, and thus happens to work. Also, prevent the heuristic from being active if PTS is merely monotonic instead of strictly-monotonic. Non-unique PTS is broken, but we can't fallback to DTS anyway in these cases. The specific mkv file that is fixed with this commit had the following fields set: Muxing application: libebml v1.3.0 + libmatroska v1.4.1 Writing application: mkvmerge v6.7.0 ('Back to the Ground') [...] But I know that this should also fix playback of mencoder produced mkv files.
* gl_common: minor cosmetic changeswm42014-05-261-10/+9
| | | | Why are you reading this message.
* gl_common: correct a typewm42014-05-261-1/+1
| | | | | | | We pass a pointer to a GLint to sscanf, using the %d format. That format _always_ takes int, and not GLint (whatever the heck that is). If GLint is always int, then it doesn't make a difference, but is still better because it doesn't play russian roulette with pointers.
* gl_w32: remove some non-sensewm42014-05-261-3/+1
| | | | Really now...
* vo_opengl: always dynamically load OpenGL symbolswm42014-05-261-64/+59
| | | | | | | | | | | | | | Don't emit "hard" references to OpenGL functions. Always use the platform specific function to lookup OpenGL functions, such as glXGetProcAddress() with GLX (x11). This actually fixes the build if only Wayland is enabled (e.g. using --disable-gl-x11 on Linux). Note that some sources claim that wglGetProcAddress() (win32) does not return function pointers for OpenGL 1.1 functions (even if they are valid and necessary in OpenGL 3.0). But if that happens, the fallback employed in gl_w32.c/w32gpa() should catch this.
* x11: fix restoring position when leaving fullscreenwm42014-05-261-1/+2
| | | | Accidentally broken in commit 7163bf7d by inverting the condition.
* x11: fix datatype for _NET_WM_PIDwm42014-05-261-1/+1
| | | | | | | | | | Setting this property was added 12 years ago, and the code was always incorrect. The underlying data type is "long", not "pid_t". It's well possible that the data types are different, and the pointer to the pid variable is directly passed to XChangeProperty, possibly invoking undefined behavior. It's funny, because in theory using pid_t for PIDs sounds more correct.
* vf_vdpaupp: cosmetics: rename functionwm42014-05-251-5/+5
|
* video: add --video-rotate option for controlling auto-rotationwm42014-05-241-0/+7
|
* x11: un-inline GNOME layer stuffwm42014-05-232-17/+12
| | | | | | Having it as separate function is not useful. Also remove the useless vo_window parameter.
* x11: prefer NetWM hints over _WIN_LAYER for --ontopwm42014-05-231-11/+11
| | | | | | | _WIN_LAYER is apparently an old GNOME thing (also explains why there is a function vo_x11_get_gnome_layer() involved in this code). Prefer the NetWM hints over this. This just moves the NetWM case if-body over the _WIN_LAYER one.
* x11: rename identifiers using reserved namespacewm42014-05-231-8/+6
| | | | | | | You can't use identifiers starting with "_" and an uppercase letter in application programs. They are reserved by the C standard. Unrelated change: drop unused/misleading vo_wm_NETWM define.
* x11: fix NetWM ontop settingwm42014-05-231-23/+13
| | | | | | | I can only assume the old code was wrong. EWMH does not document anything with _WIN_LAYER. Instead, you have to toggle the state using a client message. We also remove these weird non-sense fallbacks, like using _NET_WM_STATE_BELOW - what the hell?
* x11: add a generic function for NetWM state settingwm42014-05-231-23/+11
| | | | And use it for fullscreening. It will also be used for fixing --ontop.
* vdpau: move RGB surface management out of the VOwm42014-05-225-113/+123
| | | | | | | | | | Integrate it with the existing surface allocator in vdpau.c. The changes are a bit violent, because the vdpau API is so non-orthogonal: compared to video surfaces, output surfaces use a different ID type, different format types, and different API functions. Also, introduce IMGFMT_VDPAU_OUTPUT for VdpOutputSurfaces wrapped in mp_image, rather than hacking it. This is a bit cleaner.
* vo_vdpau: always allocate the black pixelwm42014-05-221-0/+3
| | | | | | black_pixel is an (apparently necessary) 1x1 black surface used for clearing the screen. It was allocated in RGB mode only, but is sometimes used in YUV mode too.
* x11: fix a warning with --disable-xextJerome Leclanche2014-05-221-1/+1
| | | | Signed-off-by: wm4 <wm4@nowhere>
* vo: minor simplificationswm42014-05-221-11/+3
|
* vo: remove config_ok check from vo_check_events()wm42014-05-221-3/+1
| | | | This should be ok now after the x11 code was adjusted.
* vo_vaapi: don't redraw twicewm42014-05-221-7/+1
| | | | | After VOCTRL_REDRAW_FRAME, flip_page is called, which renders the frame. The current code rendered the frame twice; drop the redundant call.
* x11: unbreak build without xineramawm42014-05-191-0/+2
|
* x11: leaving fullscreen -> reset WM hints only if neededwm42014-05-191-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | This works around an issue in OpenBox: OpenBox apparently sizes the normal window incorrectly if aspect ratio hints are set, and the window size is off by 1 pixel. Then, when going fullscreen and leaving fullscreen again, mpv sets the hints based on OpenBox' broken window size, and as result, OpenBox sizes the window incorrectly and is off by 1 pixel again - so it's 2 pixels off in total. The error gets more visible, the more often you toggle fullscreen mode. Work this around by not setting the window hints if we don't need to. Actually we only need to do this when the video is resized during fullscreen, which happens rarely. Under normal circumstances, leaving fullscreen mode requires that the WM restores the old state. As such, this commit is not only a workaround, but actually a cleanup. Note that we do need to set the hints when leaving fullscreen if the window has resized: even though we set the hints in vo_x11_highlevel_resize (called by vo_x11_config_vo_window), this doesn't seem to have an effect (at least on IceWM), so we have to do it after that. Side note: ot seems commit 625ad57a strangely triggered the OpenBox issue according to user reports; I'm not sure why.
* x11: always check whether a window existswm42014-05-191-7/+20
| | | | | So any VOCTRL can be called at any time. Working towards removing all these config_ok checks in vo.c.
* x11: request and handle resize events of parent windows with --widwm42014-05-191-8/+10
| | | | | | | Before this commit, this was somehow polled (i.e. not the right way). Also, selects the correct window when doing --wid=0 (which is another weird special-case).
* x11: remove a duplicated linewm42014-05-181-1/+0
|
* x11: never enable DPMS if we didn't disable itwm42014-05-182-0/+4
| | | | | | | | | Enabling DPMS even though you disabled it globally is pretty unfriendly, so don't do it. Instead, we only disable DPMS if it was enabled, and only enable it if we disabled it ourselves. The other way should never happen (disabling DPMS permanently), unless mpv crashes during playback.
* vdpau: don't fallback to software decoding on preemptionwm42014-05-181-7/+12
| | | | | This was requested by someone. Not sure if it's a good idea; it seems more can go wrong than right.
* x11: make screensaver code more compact, change DPMS handlingwm42014-05-172-55/+24
| | | | | | | | Reduces some code-duplication. Just call DPMSEnable/DPMSDisable, instead of DPMSForceLevel when reenabling DPMS. "Force" sounds evil, and messing with DPMS is already pretty evil. I'm not even sure that we should.
* x11: add wrapper for EWMH XSendEvent callswm42014-05-171-90/+49
|
* x11: fix Drag & Dropwm42014-05-171-1/+1
| | | | Accidentally broken in commit 95462747.
* x11: add a wrapper for XGetWindowPropertywm42014-05-171-70/+77
| | | | | | XGetWindowProperty is a really bad API, almost as if the NSA designed it. The wrapper takes care of verifying the return values and handle corner cases.
* x11: comment about gravitywm42014-05-171-0/+4
| | | | | | | | | | | | | | | | The window "gravity" influences how placement interacts with WM added borders (i.e. from decorations). This is probably what the code removed in commit c14721c8 was about. In theory, we'd probably want to set the gravity depending on the relative placement requested by the user (so that it's possible to line up the top/left video pixel with the monitor corner, as well as the bottom/right pixel - but that would be too complicated, and who cares after all?). I'm also not sure whether CenterGravity really uses the top/left corner as reference point (instead of making coordinates relative to the window center), but empirically it's correct.
* x11: replace x/y/w/h with mp_rectwm42014-05-172-102/+76
|
* x11: remove some unused fieldswm42014-05-171-3/+0
|
* x11: don't set PBaseSizewm42014-05-171-7/+0
| | | | There's apparently no reason why we should set a bogus size.
* x11: remove vo_hint memberwm42014-05-172-23/+26
| | | | | Now it's always recreated in vo_x11_sizehint(). Also, the Xlib manual says you must use XAllocSizeHints() (for ABI reasons), so do that.
* x11: always raise layer in fullscreen mode without NetWMwm42014-05-171-4/+1
|
* x11: implement --fs-screen properly, separate old code pathwm42014-05-171-65/+88
| | | | | | | Try to get the "new" code path (using NetWM/EWMH) free of hacks done for the sake of old WMs or the no-WM case. Implement --fs-screen using _NET_WM_FULLSCREEN_MONITORS.
* x11: use CenterGravity by defaultwm42014-05-171-1/+1
| | | | | | Keeps the window centered on resize. Seems nicer. (Although it's worse if 1. the default placement of the WM puts it into a monitor corner, and 2. you switch to a larger video.)
* x11: remove gravity restore codewm42014-05-172-10/+0
| | | | | | | | | | It was added with 3813c685 in 2004. I'm not really sure why this gravity stuff would be needed; apparently it has to do with misplacements with broken WMs and had to be changed on fullscreen. Just get rid of it; it works perfectly fine without on modern WMs. The thread discussing this is here: http://mplayerhq.hu/pipermail/mplayer-dev-eng/2004-July/027674.html
* x11: don't cache X Atoms manuallywm42014-05-162-108/+45
| | | | | XInternAtom() already caches lookups. Even if calling XInternAtom would be always inefficient, it wouldn't matter much during normal playback.
* x11: inline a functionwm42014-05-161-9/+3
| | | | Keeping it separate seems less readable.
* x11: replace--[x11-]fstype option with --x11-netwmwm42014-05-162-109/+20
| | | | | Simplifies the code a lot. You can still use --x11-netwm=no to disable NetWM for whatever reasons.
* x11: remove a MWM hackwm42014-05-161-11/+0
| | | | This was for Motif Window Manager. No, I don't care about Motif.
* x11: remove unused stuffwm42014-05-161-18/+0
| | | | | Unfortunately, it looks like some Motif functionality is still needed to allow for --no-border.
* x11: set the fullscreen state before mapping the windowwm42014-05-151-0/+11
| | | | | | | This should get rid of some flickering. Since this actually skips all the wacky fullscreening code on startup, this might lead to certain wacky features to stop working. In this case, you'll have to use the --x11-fstype option, and disable _NETWM_STATE_FULLSCREEN usage.
* x11: clear window on mapwm42014-05-151-1/+1
| | | | | | | | | | | | | | | | vo_x11_map_window() was attempting to clear the window on map. However, it did so immediately after the map request. It probably assumed that the drawing calls for clearing the window would be queued along with the map request, and then executed in the right order. However, this assumption was wrong - the map request first has to go to the window manager (I guess?), so a lot of things happen before the window is even mapped. Fix this by moving the call to the MapNotify message handler, when the window (apparently) becomes really visible. I also tried to set CWBackPixel to black instead, but this seemed to result in flickering on manual resizing.
* x11: wait until the window is mappedwm42014-05-151-0/+11
| | | | | | | | | | | This blocks everything, until the window is actually reported as mapped. This fixes the race condition between VO initialization and mapping the window, which resulted in possibly different window sizes, leading to an immediate redraw, visible as flashing. Note that if the map event never comes for some reason, we're out of luck and will block forever.
* vf_dlopen: update usage message to new-style argsKevin Mitchell2014-05-151-1/+1
|