summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* x11: listen to xrandr eventswm42014-08-174-2/+20
| | | | | | | | | | | If the Xrandr configuration changes, re-read it. So if you change display modes or screen configuration, it will update the framedrop refresh rate accordingly. This passes the rootwin to XRRSelectInput(), which may or may not be allowed. But it works, and the documentation (which is worse than used toilet paper, great job Xorg) doesn't forbid it, or in fact say anything about what the window parameter is even used for.
* TOOLS/zsh.pl: protect global environmentPhilip Sequeira2014-08-171-0/+4
|
* TOOLS/zsh.pl: fix a ret that hadn't been changed to rcPhilip Sequeira2014-08-171-1/+1
|
* TOOLS/zsh.pl: complete profilesPhilip Sequeira2014-08-171-0/+36
| | | | Implemented in shell, because it has to be done at runtime.
* x11: fix xrandr conditional compilationwm42014-08-171-1/+1
| | | | | | Oops. Fixes #1020.
* af_lavrresample: minor cosmeticswm42014-08-171-4/+2
|
* video: make vo_opengl the default over vo_vdpauwm42014-08-171-3/+3
| | | | | | | | | | | | | Nvidia's vdpau implementation is pretty good, but other factors make it much less attractive for use as default VO. For example, Mesa often has low quality drivers (mess up things with the presentation queue and the vdpau API time source). Intel ruins things completely, and we're likely to run on emulation via OpenGL. Compositing has unknown effects (to me anyway), but appears to reduce the vdpau advantages. One important reason to prefer vo_vdpau was that it could do proper framedropping. Framedropping got fixed for the other VOs, so this reason is going away.
* video: enable framedropping by defaultwm42014-08-172-4/+5
|
* video: take refresh rate changes into accountwm42014-08-173-28/+37
| | | | | | | | | | | | | | | This works only on X11, and only if the refresh rate changes due to the window being moved to another screen (detected by us). It doesn't include system screen reconfiguration yet. This calls VOCTRL_GET_DISPLAY_FPS on every frame, which makes me uneasy. It means extra thread communication with the win32 and Cocoa backends. On the other hand, a frame doesn't happen _that_ often, and the communication should still be pretty cheap and fast, so it's probably ok. Also needs some extra fuzz for vo_vdpau.c, because that does everything differently.
* x11: fix memory leakswm42014-08-171-3/+9
| | | | Oh, we have to free this stuff. OK.
* build: use pkg-config for xscreensaverwm42014-08-161-2/+1
|
* build: drop check for XF86keysym.hwm42014-08-164-23/+1
| | | | | | This is always included in the Xorg development headers. Strictly speaking it's not necessarily available with other X implementations, but these are hopefully all dead.
* x11: use xrandr to retrieve display refresh ratewm42014-08-166-40/+83
| | | | | | | | | | | | | | | | | Drop use of the ancient XF86VM, and use the slightly less ancient Xrandr extension to retrieve the refresh rate. Xrandr has the advantage that it supports multiple monitors (at least the modern version of it). For now, we don't attempt any dynamic reconfiguration. We don't request and listen to Xrandr events, and we don't notify the VO code of changes in the refresh rate. (The later works by assuming that X coordinates map directly to Xrandr coordinates, which probably is wrong with compositing window manager, at least if these use complicated transformations. But I know of no API to handle this.) It would be nice to drop use of the Xinerama extension too, but unfortunately, at least one EWMH feature uses Xinerama screen numbers, and I don't know how that maps to Xrandr outputs.
* demux: enable thread by defaultwm42014-08-163-9/+6
| | | | And change the defaults for the other queue options to reduce latency.
* demux: add option to control the readahead buffer by a duration valuewm42014-08-164-4/+35
| | | | | | | | | | | | | --demuxer-readahead-secs now controls how much the demuxer should readahead by an amount of seconds. This is based on the raw packet timestamps. It's not always very exact. For example, h264 in Matroska does not store any linear timestamps (only PTS values which are going to be reordered by the decoder), so this heuristic is usually off by several hundred milliseconds. The decision whether to readahead is basically OR-ed with the other --demuxer-readahead-packets options. Change the manpage descriptions to subtly convey these semantics.
* demux: remove unused functionwm42014-08-162-13/+0
|
* player: cosmetics: make code more compactwm42014-08-161-5/+2
|
* vo_wayland: fix redrawing logicwm42014-08-161-8/+8
| | | | | | I must have broken it some time ago. The error case dealing with an unavailable backbuffer was broken, and didn't handle memory management correctly.
* video: add --display-fps switch to control framedrop FPSwm42014-08-164-3/+17
| | | | | | Since the display FPS is currently detected on X11 only (and even there it's known to be wrong on certain setups), it seems like a good idea to make this user-configurable.
* audio: add a mode to insert silence on severe A/V desyncwm42014-08-155-4/+27
| | | | | | This is probably a stupid idea, but it can't be denied that this actually allows playing video without larger desync, even if video is too slow.
* vo_opengl: optional support for using GLX_SGI_video_syncwm42014-08-152-1/+26
| | | | | | | | | I'm not sure about the merit, though it does print nice numbers if debug output is enabled. Basically, this tries to achieve similar results as the glFinish() business, but again it entirely depends on the drivers whether this does anything meaningful, or whether it's actively harmful.
* gl_common: add SGI_video_sync extensionwm42014-08-152-0/+11
|
* vo_opengl: if glfinish is used, also call it after swapppingwm42014-08-152-1/+6
| | | | | | It seems that at least on nvidia systems with composting disabled, we can get it to block deterministically on the actual vsync event, which should improve framedropping.
* video: add VO framedropping modewm42014-08-1511-40/+187
| | | | | | | | | | | | | | | | | | | | | | | | This mostly uses the same idea as with vo_vdpau.c, but much simplified. On X11, it tries to get the display framerate with XF86VM, and limits the frequency of new video frames against it. Note that this is an old extension, and is confirmed not to work correctly with multi-monitor setups. But we're using it because it was already around (it is also used by vo_vdpau). This attempts to predict the next vsync event by using the time of the last frame and the display FPS. Even if that goes completely wrong, the results are still relatively good. On other systems, or if the X11 code doesn't return a display FPS, a framerate of 1000 is assumed. This is infinite for all practical purposes, and means that only frames which are definitely too late are dropped. This probably has worse results, but is still useful. "--framedrop=yes" is basically replaced with "--framedrop=decoder". The old framedropping mode is kept around, and should perhaps be improved. Dropping on the decoder level is still useful if decoding itself is too slow.
* vo: eliminate a redundant variablewm42014-08-151-10/+5
| | | | | Originally, I probably had plans to allow NULL images to handle things like the last frame case, but that idea was dropped later.
* player: use virtual time for --audio-file with ordered chapterswm42014-08-155-10/+16
| | | | | | | | | Apparently users prefer this behavior. It was used for subtitles too, so move the code to calculate the video offset into a separate function. Seeking also needs to be fixed. Fixes #1018.
* lua: wake up the core when setting OSDwm42014-08-151-0/+1
| | | | | | | | | | The OSD is marked as changed, but the core isn't notified and this doesn't immediately wakeup. (Possibly the OSD code should wakeup the core instead, but maybe that woudl be overkill.) Observed when using "mp.use_suspend = false" in the OSC, and pausing, and moving the mouse pointer out of the window. The last part of the fade remained visible for longer than intended.
* osc: Overhaul (wip)ChrisK22014-08-151-502/+848
| | | | | | | | | | | | Code reorganized to make layouts exchangeable alternative test layout can be tested with layout=slimbox in the OSC config timers are now used to properly animate the fade out when the player is paused duplicate seeks are discarded again
* sub: add option to workaround broken mkv fileswm42014-08-145-2/+13
| | | | See additions to options.rst.
* sub: call sub_reset() on seeks onlywm42014-08-143-13/+3
| | | | | | | | | | | | | | | | | sub_reset() was called on cycling subtitle tracks and on seeking. Since we don't want that subtitles disppear on cycling, sd_lavc.c didn't clear its internal subtitle queue on reset, which meant that seeking with PGS subtitles could leave the subtitle on screen (PGS subtitles usually don't have a duration set). Call it only on seeking, so we can also strictly clear the subtitle queue in sd_lavc. (This still can go very wrong if you disable a subtitle, seek, and enable it again - for example, if used with libavformat that uses "SSA" style demuxed ASS subtitle packets. That shouldn't happen with newer libavformat versions, and the user can "correct" it anyway by executing a seek while the subtitle is selected.)
* client API: directly lock playloopwm42014-08-141-4/+3
| | | | | | | | Until recently, vo_opengl could be accessed from a single thread only, due to the OpenGL API context being thread-specific. This issue doesn't exist anymore, because VOs run on their own thread. This means we can simply lock/unlock the playloop instead of doing something complicated to get the playloop thread to execute our code.
* lua: allow disabling suspendwm42014-08-141-2/+8
| | | | | I'd like to enable this by default, but unfortunately the OSC seems to have some problems with it.
* client API: adjust documentation for mpv_suspend()wm42014-08-141-20/+5
| | | | | | | It's not true anymore that the core will stop replying for 50ms (waiting for video) without calling this function. Simplify the documentation accordingly. Accessing properties that go through the VO still have this problem, though.
* vo: remove unused libavutil includewm42014-08-141-2/+0
|
* vo: fix mingw compilationwm42014-08-141-0/+2
|
* demux_lavf: support new metadata update APIwm42014-08-143-3/+35
| | | | | This Libav-invented API is of course completely different from the FFmpeg-one. (The fun part is that I approved of both.)
* TOOLS/zsh.pl: properly set the return valueAlessandro Ghedini2014-08-131-9/+12
| | | | | | The previous commit made the completion script always return non-zero, even when a match is found. This explicitly sets the return value to zero whenever a match is found but defaults to non-zero in case nothing is matched.
* TOOLS/zsh.pl: properly return non-zero when no matches are foundc_142014-08-131-0/+1
| | | | | | | | Returning a non-zero value signals to the zsh completion system that no matches were added by the script so that it can try the user-defined matchers (e.g. those defined with matcher-list). Fixes #1008.
* wayland: pointer interface is created after themeAlexander Preisinger2014-08-131-13/+8
| | | | | | | | Just always load the theme. It gets freed properly and dosn't bother anyone. Fixes #1012. CC: @mpv-player/stable
* video: reduce non-sense messages when playing coverartwm42014-08-131-11/+14
| | | | Don't print PTS warnings by skipping the normal video path.
* video: don't run new frame processing on every iterationwm42014-08-131-19/+22
| | | | | | | This ran adjust_sync() on every playloop iteration, instead of every newly decoded frame. It seems this was idempotent in the common case, but the code was originally designed to be run once only, so restore that.
* video: move some more code aroundwm42014-08-131-38/+49
| | | | No functional changes.
* video: move some code aroundwm42014-08-131-45/+40
|
* video: exit early when nothing to dowm42014-08-131-7/+7
| | | | | These cases were probably confusing. Exit early, which makes it much clearer what's going on. Should not change anything functionally.
* video: minor simplification of the old framedrop codewm42014-08-131-10/+6
| | | | | No changes in functionality, other than being slightly more correct at stream EOF.
* player: don't quit with --loop-filewm42014-08-131-0/+1
| | | | | | Fixes #1009. CC: @mpv-player/stable
* vdpau: correctly mark invalid mixer as such on vdp_video_mixer_create() failureAlessandro Ghedini2014-08-131-0/+3
| | | | | Otherwise vdp_video_mixer_destroy() would later fail when called on an invalid video mixer handle. With mesa r600 vdpau driver, this would cause a segfault.
* build: fix libmpv build when using system wafJan Palus2014-08-131-1/+3
| | | | | | | Since the 'syms' tool is shipped in waf's extras, when using system waf the default tool overrides our own. Force our syms tool by providing the tooldir. Fixes #1006
* vo_vdpau: fix screenshots with anamorphic videowm42014-08-131-1/+1
| | | | | | Fixes #1007. CC: @mpv-player/stable
* x11: vdpau GLX interop needs X11 threadswm42014-08-131-0/+2
| | | | | | | | | | Xlib is not thread-safe. Or actually it is, but it's an incomprehensible hack that was added later, and which needs to be acitvated manually (this makes no sense). And it appears that the vdpau accesses X from the decoder thread if GLX interop is used (and not in any other situations - this doesn't make too much sense either). So, just call the magic function that enables Xlib thread-safety.
* af_lavcac3enc: lower minimum channel number to 3wm42014-08-122-2/+2
| | | | It seems only stereo PCM should be passed through.
* docs: cocoa example uses wakeup callback APIFRAU KOUJIRO2014-08-121-22/+54
| | | | Also, imitate the qt example somewhat.
* docs: simple cocoa API usage exampleFRAU KOUJIRO2014-08-121-0/+85
|
* af_lavcac3enc: change default bitrate to 640wm42014-08-122-2/+5
| | | | | | | No reason to use less. Since the name "default" is misleading now, replace it with "auto" (still recognize the old name).
* video: fix and simplify video format changes and last frame displaywm42014-08-126-181/+127
| | | | | | | | | | | | | | | | | | | | | | | | | | The previous commit broke these things, and fixing them is separate in this commit in order to reduce the volume of changes. Move the image queue from the VO to the playback core. The image queue is a remnant of the old way how vdpau was implemented, and increasingly became more and more an artifact. In the end, it did only one thing: computing the duration of the current frame. This was done by taking the PTS difference between the current and the future frame. We keep this, but by moving it out of the VO, we don't have to special-case format changes anymore. This simplifies the code a lot. Since we need the queue to compute the duration only, a queue size larger than 2 makes no sense, and we can hardcode that. Also change how the last frame is handled. The last frame is a bit of a problem, because video timing works by showing one frame after another, which makes it a special case. Make the VO provide a function to notify us when the frame is done, instead. The frame duration is used for that. This is not perfect. For example, changing playback speed during the last frame doesn't update the end time. Pausing will not stop the clock that times the last frame. But I don't think this matters for such a corner case.
* video: move display and timing to a separate threadwm42014-08-1219-252/+513
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The VO is run inside its own thread. It also does most of video timing. The playloop hands the image data and a realtime timestamp to the VO, and the VO does the rest. In particular, this allows the playloop to do other things, instead of blocking for video redraw. But if anything accesses the VO during video timing, it will block. This also fixes vo_sdl.c event handling; but that is only a side-effect, since reimplementing the broken way would require more effort. Also drop --softsleep. In theory, this option helps if the kernel's sleeping mechanism is too inaccurate for video timing. In practice, I haven't ever encountered a situation where it helps, and it just burns CPU cycles. On the other hand it's probably actively harmful, because it prevents the libavcodec decoder threads from doing real work. Side note: Originally, I intended that multiple frames can be queued to the VO. But this is not done, due to problems with OSD and other certain features. OSD in particular is simply designed in a way that it can be neither timed nor copied, so you do have to render it into the video frame before you can draw the next frame. (Subtitles have no such restriction. sd_lavc was even updated to fix this.) It seems the right solution to queuing multiple VO frames is rendering on VO-backed framebuffers, like vo_vdpau.c does. This requires VO driver support, and is out of scope of this commit. As consequence, the VO has a queue size of 1. The existing video queue is just needed to compute frame duration, and will be moved out in the next commit.
* DOCS: mark the recent release in client-api-changes.rstwm42014-08-122-0/+3
| | | | | | | Also add instructions to release-policy.md, since this can be easily forgotten. CC: @mpv-player/stable
* input.conf: add some bindings for changing audio-delaywm42014-08-111-0/+2
| | | | | | Requested on: https://github.com/mpv-player/mpv/commit/90ec3334174e80c16f00971886223a3afabc1aca#commitcomment-7331673 Might remove or remap them again later.
* input.conf: make explanatory text more readablewm42014-08-112-30/+16
| | | | | Or at leats this is the intention. It's a bit hard to tell which information is needed, and which not.
* video: don't keep multiple pointers to hwdec info structwm42014-08-117-26/+29
| | | | This makes a certain corner case simpler at a later point.
* vaapi: fix uninitialized value readwm42014-08-111-1/+1
| | | | | | Found with valgrind. This is somewhat terrifying, because the VA-API API function is supposed to fill these values, and we access them only if the API functions return success. So this shouldn't have happened.
* vf_vapoursynth: print more diagnostics on errorwm42014-08-111-3/+9
|
* manpage: update keybindingswm42014-08-111-1/+1
|
* Move status-line.luawm42014-08-111-1/+1
| | | | | Looks like TOOLS/lua/ is now established as dumping ground for random Lua scripts, so DOCS/lua_examples/ is not needed anymore.
* player: remove cache status from video OSDwm42014-08-111-3/+0
|
* demux: reduce log spam if threading is disabledwm42014-08-111-3/+11
|
* video: fix dangling pointer issuewm42014-08-111-1/+1
| | | | | | | | | | | The function video_decode_and_filter(), called between initializing the local vf variable and using it, can actually destroy and recreate the filter. Thus, the vf variable turns into a dangling pointer if that happens. Could be observed with: --hwdec=vda --deinterlace=yes --vf=yadif (Also happens with vdpau/vaapi.)
* vdpau: allocate surfaces by agewm42014-08-112-1/+11
| | | | | Whether this helps is probably questionable and depends on the GPU. But the vaapi code does it too.
* input: fix event wakeupwm42014-08-111-18/+14
| |