summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* 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
|
* etc/input.conf: add example how to change window size by key bindingwm42014-05-182-0/+3
| | | | Also drop a vague hint how to do it in the manpage.
* 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.
* timer: account for negative time valueswm42014-05-181-2/+6
| | | | | | | | It can easily happen that mp_time_us_to_timespec() gets a time in the past, and then the time difference will be negative. Regression introduced in commit f47a4fc3. Also fix an underflow check in mp_add_timeout().
* compat/libav: remove unneeded thingswm42014-05-181-8/+1
| | | | | | Currently, it's unused. Still keep the file, because it's not unlikely we'll need it again, and removing/readding the include statements for this file is too annoying.
* 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.
* client API: add mpv_load_config_file()wm42014-05-182-0/+39
| | | | | | | This is probably a good idea, because it would make it easier for software embedding mpv to configure the mpv parts, without requiring the host program to provide explicit mechanisms for this (other than calling mpv_load_config_file()).
* options: unify code for setting string and "raw" optionswm42014-05-184-90/+138
| | | | | | | | | The code paths for setting options by string and by direct "raw" value were too different, which resulted in some weird code. Make the code paths closer to each other. Also, use this to remove the weirdness in the mpv_set_option() implementation.
* threads: use mpv time for mpthread_cond_timedwait wrapperwm42014-05-188-62/+98
| | | | | | Use the time as returned by mp_time_us() for mpthread_cond_timedwait(), instead of calculating the struct timespec value based on a timeout. This (probably) makes it easier to wait for a specific deadline.
* manpage: fix a minor aspect of the discnav commandwm42014-05-181-2/+1
| | | | | "menu" is in fact understood by stream_bluray.c, so just drop that sentence.
* player: increase seek accuracy when refreshing display on filter changewm42014-05-181-1/+1
| | | | | | | | | When the player is paused, and video filters are changed, an exact seek is executed to refresh the display. Increase the exactness of the seek in this case; this reuses the code used for frame backstepping. It might help in cases where seeking is very imprecise, such as with transport streams.
* manpage: document discnav commandwm42014-05-181-0/+14
|
* command: add a disc-menu-active propertywm42014-05-184-0/+36
| | | | Returns whether a DVD/BD menu is active. As requested by #788.
* client API: fix "missed" property notificationswm42014-05-181-19/+25
| | | | | | | | | | | | | | | | | | If a property is notified as changed, and then again (before the change notification is returned to the client), and the second change is a sporadic change (i.e. nothing actually changed) and the change notification was associated with with a data type, it could happen that a change was "overlooked", because it would detect no change on the second notification. This is actually a pretty annoying corner case, due to the annoying way we do things, so just store both the previously returned _and_ the newly obtained property value. then we always compare with the user value to check for a change, excluding any possibility of a missed change. Note that we don't (can't/shouldn't) care if a value changes, and then changes back; it's fine if that doesn't generate a notification. This is due to how property notifications are supposed to be coalesced.
* 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-172-69/+90
| | | | | | | 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.
* encoding: No error when the output format doesn't support a stream type at all.Rudolf Polzer2014-05-161-8/+20
| | | | | | | | When writing a video to foo.mp3, the user's intention is clearly to drop the video stream, and similarly, when writing to foo-%d.png, the intention is clearly to drop the audio stream. Now, explicit specification of --no-audio or --no-video is no longer necessary in these cases.
* etc/example.conf: add example options for multichannel audiowm42014-05-161-1/+9
|
* etc/example.conf: minor adjustmentswm42014-05-161-2/+3
|
* etc/example.conf: remove spaces between key and valuewm42014-05-161-9/+9
| | | | | Currently, they are allowed, but only because MPlayer happened to do that. This might or might not be changed in the future.
* x11: replace--[x11-]fstype option with --x11-netwmwm42014-05-167-161/+36
| | | | | 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.
* TOOLS/vf_dlopen: use new pixelformats, fix usage for newstyle argsKevin Mitchell2014-05-156-13/+13
|
* vf_dlopen: update usage message to new-style argsKevin Mitchell2014-05-151-1/+1
|
* vf_dlopen: remove buggy private name -> imgfmt conversionKevin Mitchell2014-05-152-34/+18
| | | | | This was presumably for backward compatibility, but it was preventing the use of the new names.
* vf_vapoursynth: fix debug outputwm42014-05-151-1/+4
|
* vf_vapoursynth: add more debug outputwm42014-05-151-18/+21
| | | | | Also, move num_requested() to where it's used. Remove newlines from VS error messages. Remove an assert(0) on an error path.
* manpage: changes.rst: minor fixupswm42014-05-151-5/+5
|
* vf_vapoursynth: avoid unnecessary waitingwm42014-05-141-1/+1
| | | | | | | It could in theory happen that the filter loop will enter a blocking wait, even though it could make progress by emptying the list of already-filtered images. I'm not quite sure if this could actually cause a real issue - probably not.
* TOOLS/mpv_identify.sh: unbreakwm42014-05-141-1/+1
|
* vf_vapoursynth: allow parallel processingwm42014-05-142-45/+101
| | | | | | | | VapourSynth won't just filter multiple frames at once on its own. You have to request multiple frames at once manually. This is what this commit introduces: a sub-option controls how many frames will be requested at once. This also changes the semantics of the maxbuffer sub- option, now renamed to buffered-frames.
* manpage: updates changes.rstwm42014-05-141-46/+59
| | | | | | | | | | | | | The situation has changed a bit since the days of mplayer2, so we can use more/less diplomatic wording. Merge the two sections listing changes from MPlayer and mplayer2. Mention the client API and Lua scripting as alternatives to slave mode. I'm calling MPlayer code "horrible". This is not meant as an offense, but after turning around almost every line of MPlayer code, I believe I have a right to say this. Sorry. I would say that MPlayer has a surprisingly sane and simple architecture (for what it is), but much of it drowned under a load of evil hacks or not-cleaned-up-yet code.
* old-build: accidental rewritewm42014-05-142-2058/+484
| | | | | | | | | | | | | This started as a bunch of smaller changes to make the old configure script maintainable with minimum effort. It ended up as complete rewrite, because at once point I started to like shell programming (I hope this sickness is curable), and I wanted to see how small I can make the configure script. The typical configure test is now 1 or 2 lines big, located in 1 or 2 places, instead of >15 lines and being spread over 5 or 6 places. The main "trick" is factoring the tests into a few generic, commonly needed tests, instead of writing everything manually.
* old-build: drop support for anything but Linux, simplifywm42014-05-142-849/+58
| | | | | | | | | | | | | A lot of effort was spent on making the waf based build-system work properly on all supported platforms, while the old configure script was neglected. It seems that nobody maintains the non-Linux parts of the configure script anymore, and all improvements go into the waf scripts. Thus it makes no sense anymore to maintain the non-Linux parts. They're just dead weight. Remove them completely. Also apply some additional simplifications. For example, listing enabled/disabled VO modules seems like a waste of effort.
* build: add some warning cflagswm42014-05-141-1/+3
| | | | | | | | | These were in the old configure script too. Two flags are explicitly tested, because I have no idea how widespread support for them is, and testing them is just easier than trying to look them up in various gcc/clang manuals. There are people using gcc 4.2 out there, so some caution is warranted.
* wayland: fix typoAlexander Preisinger2014-05-141-14/+14
| | | | So long in the code without me noticing. Embarassing!
* player: reorganize how lua scripts are loadedwm42014-05-1311-130/+209
| | | | | | Make loading of scripts independent of Lua. Move some of the loading code from lua.c to scripting.c, and make it easier to add new scripting backends.
* old-build: define a new symbolwm42014-05-131-0/+1
| | | | | | | waf has a proper test, but no test was added to old-configure. This means that on OSX, old-configure is not supposed to work anymore. But still allow it to compile cleanly on OSX.
* stream_smb: increase to 128k read_chuuk from default 8kKevin Mitchell2014-05-121-0/+1
| | | | | | | | | | | | | | | | | Previous to this commit, read_chunk was not set in stream_smb. The cache was therefore filled in small 8K chunks. This resulted in poor performance when compared to, for example, smbnetfs on the same network. The value of 128k is chosen both because it is emperically the "levelling off point" for throughput into mpv's cache, and because it is the value chosen by smbnetfs when serving smb shares to mpv. Note that this change has no effect unless --cache is explicitly specified as smb:// streams do not activate cache by default. This is because the default cache size of 320K is so small it actually makes smb:// perfomance worse. For best results use at least --cache=1024.
* player: disable hr-seek framedropping during backsteppingwm42014-05-121-2/+3
|
* build: fix OpenBSD DVD/CDROM device nameswm42014-05-121-2/+2
| | | | Closes #781.
* vda: Hwaccel 1.2 supportLuca Barbato2014-05-123-34/+81
| | | | Use the new context and the default functions provided.
* vda: Simplify codec selectionLuca Barbato2014-05-121-28/+2
| | | | VDA supports h264 only.
* vd_lavc: Support hwaccel 1.2 and laterLuca Barbato2014-05-121-4/+4
| | | | | Hwaccel 1.2 populates only the third data field and assumes that the AVCodecContext is available to the dealloc function.
* audio/out: fix previous commitwm42014-05-111-9/+11
| | | | | | | | | This didn't quite work. The main issue was that get_space tries to be clever to reduce overall buffering, so it will cause the playloop to decode and queue only as much audio as is needed to refill the AO in reasonable time. Also, even if ignoring the problem, the logic of the previous commit was slightly broken. (This required a few retries, because I couldn't reproduce the issue on my own machine.)
* audio/out: avoid wakeup feedback loopwm42014-05-111-2/+7
| | | | | | | | | | | | | When the audio buffer went low, but could not be refilled yet, it could happen that the AO playback thread and the decode thread could enter a wakeup feedback loop, causing up to 100% CPU usage doing nothing. This happened because the decoder thread would wake up the AO thread when writing 0 bytes of newly decoded data, and the AO thread in reaction wakes up the decoder thread after writing 0 bytes to the AO buffer. Fix this by waking up the decoder thread only if data was actually played or queued. (This will still cause some redundant wakeups, but will eventually settle down, reducing CPU usage close to ideal.)
* TOOLS/stats-conv: don't crash on empty lineswm42014-05-111-0/+3
|
* TOOLS/stats-conv: draw playloop and AO thread events separatelywm42014-05-111-0/+5
| | | | | Use for all AO thread events y=0.5, while playloop events remain at y=1. This makes the graph easier to read.
* manpage: update --playlist entrywm42014-05-111-5/+10
|
* mixer: make code more readablewm42014-05-111-7/+3
| | | | | You wouldn't have guessed that the bottom-most "level[i] = 0.f;" line was actually required. It even confused cppcheck.
* audio/out: more debugging info for --dump-statswm42014-05-111-1/+5
|
* wayland: fix unchecked malloc usagewm42014-05-111-3/+9
| | | | | | | Found by cppcheck. Actually untested. (This is the file drag&drop code, I don't even know which wayland clients support this.)
* player: don't assign "false" to pointerwm42014-05-111-1/+1
| | | | | | | This is legal in theory. "false" expand to 0, and 0 is a valid pointer value. But I guess this was not really intended. Found by cppcheck.
* build: removed undefined behavior from PVR checkwm42014-05-111-1/+1
| | | | | |