summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* af_rubberband: default to channels=togetherHector Martin2016-09-191-0/+1
| | | | | | | | For stereo and typical L/R-first channel arrangements, this avoids undesirable phasing artifacts, especially obvious when speed is changed and then reset. Without this, there is a very audible change in the stereo field even when librubberband is no longer actually making any speed changes.
* af_rubberband: add af-command and option to change the pitchHector Martin2016-09-192-2/+38
| | | | | This allows both fixed and dynamic control over the audio pitch using librubberband, which was previously not exposed to the user.
* af_pan: add af-command support to change the matrixHector Martin2016-09-192-19/+38
| | | | | This allows for seamless changes in the downmixing matrix without having to reinitialize the filter chain.
* af_pan: coding style fixesHector Martin2016-09-191-103/+104
|
* command: fix "cycle"/"add" not working on most propertieswm42016-09-181-1/+2
| | | | | | | | Oops, this is kind of important, isn't it? Stopped working for properties which don't implement M_PROPERTY_GET_CONSTRICTED_TYPE directly, as do_action() goes to the property directly, while m_property_do() does a fallback.
* player: more option/property consistency fixeswm42016-09-1810-58/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | | Some properties had a different type from their equivalent options (such as mute, volume, deinterlace, edition). This wasn't really sane, as raw option values should be always within their bounds. On the other hand, these properties use a different type to reflect runtime limits (such as range of available editions), or simply to improve the "UI" (you don't want to cycle throuhg the completely useless "auto" value when cycling the "mute" property). Handle this by making them always return the option type, but also allowing them to provide a "constricted" type, which is used for UI purposes. All M_PROPERTY_GET_CONSTRICTED_TYPE changes are related to this. One consequence is that you can set the volume property to arbitrary high values just like with the --volume option, but using the "add" command it still restricts it to the --volume-max range. Also deprecate --chapter, as it is grossly incompatible to the chapter property. We pondered renaming it to --chapters, or introducing a more powerful --range option, but concluded that --start --end is actually enough. These changes appear to take care of the last gross property/option incompatibilities, although there might still be a few lurking.
* command: fix window-scale option/property inconsistencieswm42016-09-182-7/+7
| | | | | | | | | For some odd reason, value ranges for the window-scale option and property are different, and the property has a more narrow range. Change it to the option range. Also store the window-scale value into the option value when setting the property, so it will be persistent if the window is closed and reopened.
* options: rename/deprecate --playlist-poswm42016-09-185-13/+11
| | | | | | Conflicts with the "playlist-pos" property. They're really a bit too different, and since the --playlist-pos option is relatively new and obscure, just rename it to get this out of the way.
* command: minor fixes to video-aspect propertywm42016-09-181-8/+2
| | | | | | Make the option type exactly the same as the underlying option's one. I think this has no user-visible consequences, but makes more sense for the option-property bridge.
* options: actually deprecate --mute=autowm42016-09-184-5/+10
| | | | Also, make it internally actually an alias to "no".
* command: fix --quiet, --really-quiet optionswm42016-09-181-0/+2
| | | | | | | These are not mapped as property, so the option-property bridge has to skip them. Do this automatically if a property is not found. I know that this affects --quiet and --really-quiet, but in theory there could be more.
* displayconfig: treat a refresh rate of 1 as invalidJames Ross-Gowan2016-09-181-2/+8
| | | | Found in Windows 8.1/VirtualBox.
* stream/stream_lavf: user-agent option is deprecatedRiCON2016-09-181-1/+1
| | | | | | There was both user-agent and user_agent options, the former is deprecated in FFmpeg/FFmpeg@27714b462 master. Libav uses both forms. This avoids constant `[ffmpeg] http: the user-agent option is deprecated, please use user_agent option` warnings using ytdl_hook.
* command: add an apply-profile commandwm42016-09-174-0/+20
| | | | | This will actually update all associated options (which is trivial now with the recent changes).
* options: take care of propertly updating options on runtime changeswm42016-09-177-8/+125
| | | | | | | | | | | | | | | | | | | | | | All option write accesses are now put through the property interface, which means runtime option value verification and runtime updates are applied. This is done even for command line arguments and config files. This has many subtle and not-so-subtle consequences. The potential for unintended and intended subtle or not-subtle behavior changes is very large. Architecturally, this is us literally jumping through hoops. It really should work the other way around, with options being able to have callbacks for value verification and applying runtime updates. But this would require rewriting the entirety of command.c. This change is more practical, and if anything will at least allow incremental changes. Some options are too incompatible for this to work - these are excluded with an explicit blacklist. This change fixes many issues caused by the mismatch between properties and options. For example, this fixes #3281.
* options: fix pseudo-options like -vwm42016-09-171-1/+1
| | | | | | | Some pseudo-options do not have associated storage, which made m_config_set_option_raw() return failure. Regression due to commit d1d5e9dd.
* manpage: document some more property/options inconsistencieswm42016-09-171-0/+27
|
* command: make window-scale redirect to option if no window createdwm42016-09-171-1/+1
| | | | For consistency with other properties that mirror options.
* DOCS: vo/ao auto profiles are deprecatedRiCON2016-09-171-2/+1
| | | Leftovers from removal of references to ao/vo auto profiles.
* options: simplify M_OPT_EXITwm42016-09-178-26/+22
| | | | | | | | | | | | | There were multiple values under M_OPT_EXIT (M_OPT_EXIT-n for n>=0). Somehow M_OPT_EXIT-n either meant error code n (with n==0 no error?), or the number of option valus consumed (0 or 1). The latter is MPlayer legacy, which left it to the option type parsers to determine whether an option took a value or not. All of this was changed in mpv, by requiring the user to use explicit syntax ("--opt=val" instead of "-opt val"). In any case, the n value wasn't even used (anymore), so rip this all out. Now M_OPT_EXIT-1 doesn't mean anything, and could be used by a new error code.
* m_config: make option setting always call m_config_set_option_raw()wm42016-09-171-14/+20
| | | | | | | | | | This makes m_config_set_option_raw() the function that is always called on the lowest level (as leaf function for all other functions). To do this, m_config_parse_option() has to do something special to deal with "impure" options like --vf-add, which work on the previous option value, instead of fully replacing it. m_config_set_option_raw() itself always completely replaced the previous value.
* options: kill M_OPT_GLOBAL flagwm42016-09-173-21/+7
| | | | | | This meant "cannot be used as per-file option" (wrt. playlist items). Doesn't make too much sense anymore, especially given how obscure per-file options are.
* player: don't enter playloop for client API requestswm42016-09-162-2/+4
| | | | | | | | | | | This _actually_ does what commit 8716c2e8 promised, and gives a slight performance improvement for client API users which make a lot of requests (like reading properties). The main issue was that mp_dispatch_lock() (which client.c uses to get exclusive access to the core) still called the wakeup callback, which made mp_dispatch_queue_process() exit. So the playloop got executed again, and since it does a lot of stuff, performance could be reduced.
* osd: fix OSD getting stuck with --blend-subtitles=yeswm42016-09-163-19/+18
| | | | | | | | | | | | | If --blend-subtitles=yes is given, vo_opengl will call osd_draw() multiple times, once for subtitles, and once for OSD. This meant that the want_redraw flag was reset before the OSD was rendered, which in turn meant that update_osd() was never called. It seems like removing the per-OSD object want_redraw wasn't such a good idea. Fix it by reintroducing such a flag for OSDTYPE_OSD only. Also, the want_redraw flag is now unused, so kill it. Another regression caused by commit 9c9cf125. Fixes #3535.
* dispatch: fix a race condition triggering an assert()wm42016-09-161-1/+1
| | | | | | | | | | | If we were waiting, and then exiting due to timeout, we still have to recheck the condition protected by the condition variable/mutex in order to get back to a consistent state. In this case, the queue was locked with mp_dispatch_lock(), and mp_dispatch_queue_process() got to return without waiting for unlock. Also caused commit 8716c2e8. Probably an argument for replacing the dispatch queue by a simple mutex.
* player: fix a missed wakeupwm42016-09-161-0/+1
| | | | | ytdl.lua stopped working after commit 8716c2e8, because finishing the hook did not wakeup the playloop correctly.
* vo_opengl: don't pass negative height to overlay_adjust()wm42016-09-161-1/+1
| | | | | | Negative height is used to signal a flipped framebuffer. There's absolutely no reason to pass this down to overlay_adjust(), and only requires implementers to deal with an additional special-case.
* player: use better way to wait for input and dispatching commandswm42016-09-169-57/+80
| | | | | | | | | | | | | | | | | | | Instead of using input_ctx for waiting, use the dispatch queue directly. One big change is that the dispatch queue will just process commands that come in (e.g. from client API) without returning. This should reduce unnecessary playloop excutions (which is good since the playloop got a bit fat from rechecking a lot of conditions every iteration). Since this doesn't force a new playloop iteration on every access, this has to be enforced manually in some cases. Normal input (via terminal or VO window) still wakes up the playloop every time, though that's not too important. It makes testing this harder, though. If there are missing wakeup calls, it will be noticed only when using the client API in some form. At this point we could probably use a normal lock instead of the dispatch queue stuff.
* client API: declare mpv_suspend/mpv_resume deprecatedwm42016-09-168-10/+22
| | | | | | | They're useless, and I have no idea what they're actually supposed to do (wrt. pending input processing changes). Also remove their implicit uses from the IPC handlers.
* player: litter code with explicit wakeup callswm42016-09-169-39/+76
| | | | | | | | | | | | | This does 3 kinds of changes: - change sleeptime=x to mp_set_timeout() - change sleeptime=0 to mp_wakeup_core() calls (to be more explicit) - change commands etc. to call mp_wakeup_core() if they do changes that require the playloop to be rerun This is preparation for the following changes. The goal is to process client API requests without having to rerun the playloop every time. As of this commit, the changes should not change behavior. In particular, the playloop is still implicitly woken up on every command.
* player, ao, vo: don't call mp_input_wakeup() directlywm42016-09-1617-47/+97
| | | | | | | | | | | | | Currently, calling mp_input_wakeup() will wake up the core thread (also called the playloop). This seems odd, but currently the core indeed calls mp_input_wait() when it has nothing more to do. It's done this way because MPlayer used input_ctx as central "mainloop". This is probably going to change. Remove direct calls to this function, and replace it with mp_wakeup_core() calls. ao and vo are changed to use opaque callbacks and not use input_ctx for this purpose. Other code already uses opaque callbacks, or has legitimate reasons to use input_ctx directly (such as sending actual user input).
* osd: fix subtitle/overlay update problemswm42016-09-161-2/+6
| | | | | | | | | | | This could in theory lead to missed updates if subtitles were switched or external OSD overlays (via overlay-add) were updated. While the change IDs of each of those were consistent, switching between two separate OSD sources is not, and we have to explicitly trigger a change. Regression since commit 9c9cf125. The new code is actually better, because we do exactly what is needed, and don't just mess with the update ID for libass-based OSD.
* hwdec_cuda: Rename config variable to be more consistentPhilip Langdale2016-09-165-8/+8
| | | | | | 'cuda-gl' isn't right - you can turn this on without any GL and get some non-zero benefit (with the cuda-copy hwaccel). So 'cuda-hwaccel' seems more consistent with everything else.
* vo_opengl: rpi: cosmetic changewm42016-09-151-2/+2
| | | | I almost feel sorry wasting a commit on this.
* audio: fix missed wakeup when changing audio output devicewm42016-09-151-1/+1
| | | | | | | | When playing audio-only, and changing the audio output device, playback froze until the next time the playback core happened to wakeup (like moving the mouse, or OSD redrawing). This is probably because of the awful statemachine in fill_audio_out_buffers() - just make it recreate the AO directly instead.
* osd: slightly simplify update logicwm42016-09-156-30/+21
| | | | | | | | | | | | | | | | Remove the per-part force_redraw flags, and instead make the difference between flagging dirty state and returning it to the player frontend more explicit. The big issue is that 1. the OSD needs to know the dirty state, and it should be cleared strictly when it is re-rendered (force_redraw flag), and 2. the player core needs to be notified once, and the notification must be reset (want_redraw flag). The call in loadfile.c is replaced by making osd_set_sub() set the change flag. Increasing the change flag on dirty state (the force_redraw check in render_object()) should not be needed, because OSD part renderers set it correctly (at least now). Doing this just because someone pointed this out.
* options: add --hwdec=yes as alias for --hwdec=autowm42016-09-152-2/+4
| | | | | | This also lets you just do "mpv --hwdec file.mkv", with the minor caveat that the legacy syntax "--hwdec val" or "-hwdec val" (without "=") does not work as expected anymore.
* etc/builtin.conf: minor editswm42016-09-151-2/+6
| | | | | | | | The previous commit merely copied the profile string to a file (plus changing how RPI-specific defaults are initialized), now make some changes on top of it. In particular, remove the --input-lirc option, which was removed a long time ago, but forgotten from the libmpv profile.
* player: move builtin profiles to a separate filewm42016-09-155-50/+51
| | | | | | | | | Move the embedded string with the builtin profiles to a separate builtin.conf file. This makes it easier to read and edit, and you can also check it for errors with --include=etc/builtin.conf. (Normally errors are hidden intentionally, because there's no way to output error messages this early, and because some options might not be present on all platforms or with all configurations.)
* player: remove unintended !mingw ifdef for IPC uninitwm42016-09-151-2/+0
| | | | | | | | Just wow. This function is implemented in ipc-win.c, and was surely be meant to be called. But it wasn't called. This could in theory cause crashes during exit if IPC clients were active. Untested whether it really works.
* client API: remove SIGPIPE overriding codewm42016-09-154-11/+8
| | | | | | | This workaround prevented that libmpv users could accidentally crash when the SIGPIPE signal was triggered by FFmpeg's OpenSSL/GnuTLS usage. But it also modifies the global signal handler state, so remove it now that this workaround is not required anymore.
* manpage: explain "speed-adjusted" FPS for --interpolation-thresholdwm42016-09-151-2/+5
| | | | Fixes #3528.
* vo_opengl: fix OSD with icc-profile after previous commitwm42016-09-141-0/+2
| | | | | | This happened to break because the texture unit wasn't reset to 0, which some code expects. The OSD code in particular set the OSD texture on the wrong texture unit, with the result that OSD/OSC was not visible.
* vo_opengl: dynamically manage texture unitswm42016-09-145-30/+54
| | | | | | | | | | | | | | | | | | | | | A minor cleanup that makes the code simpler, and guarantees that we cleanup the GL state properly at any point. We do this by reusing the uniform caching, and assigning each sampler uniform its own texture unit by incrementing a counter. This has various subtle consequences for the GL driver, which hopefully don't matter. For example, it will bind fewer textures at a time, but also rebind them more often. For some reason we keep TEXUNIT_VIDEO_NUM, because it limits the number of hook passes that can be bound at the same time. OSD rendering is an exception: we do many passes with the same shader, and rebinding the texture each pass. For now, this is handled in an unclean way, and we make the shader cache reserve texture unit 0 for the OSD texture. At a later point, we should allocate that one dynamically too, and just pass the texture unit to the OSD rendering code. Right now I feel like vo_rpi.c (may it rot in hell) is in the way.
* vo_opengl: require explicit reset on shader cache after renderingwm42016-09-144-8/+30
| | | | | | | | | The caller now has to call gl_sc_reset(), and _after_ rendering. This way we can unset OpenGL state that was setup for rendering. This affects the shader program, for example. The next commit uses this to automatically manage texture units via the shader cache. vo_rpi.c changes untested.
* vo_opengl: remove a redundant glActiveTexture() callwm42016-09-141-2/+2
| | | | | This bound video textures to individual texture units - this is how it used to work long ago, but now is pointless, and maybe even dangerous.
* vo_opengl: make the number of PBOs tunableNiklas Haas2016-09-142-5/+7
| | | | | Also set the number of PBOs from 2 to 3, which should be better for pipelining. This makes it easier to add more in the future.
* vo_opengl: drm: use new EGL context creation codewm42016-09-142-43/+8
|
* vo_opengl: wayland: use new EGL context creation codewm42016-09-142-50/+9
|
* vo_opengl: EGL: dump some version infowm42016-09-141-0/+8
|
* vo_opengl: EGL: better desktop-GL context creationwm42016-09-141-19/+65
| | | | | | | | | | | | Stops Mesa from restricting us to OpenGL 3.0. It also tries to create GLES 3 contexts for drivers which do not just return a higher context when requesting GLES 2. I don't know whether this code is a good or bad idea. A not-so-good aspect is that we don't check for EGL 1.5 (or 1.4 extensions) for some of the more advanced context attributes. But EGL implementations should be able to tolerate it and return an error, and then we'd use the fallback.
* vo_opengl: EGL: silence eglBindAPI() error messagewm42016-09-131-1/+1
| | | | | It's not helpful and will be printed with EGL implementations that don't support OpenGL at all. Just shut it up.
* vo_rpi, vo_opengl: separate RPI/EGL-specific code for both VOswm42016-09-133-220/+200
| | | | | | | | | This used to be shared, but since vo_rpi is going to be removed, untangle them. There was barely any actual code shared since the recent changes anyway. As a subtle change, we also stop opening libGLESv2.so explicitly in the vo_opengl backend, and use RTLD_DEFAULT instead.
* vo_opengl: rpi: use new egl context creation helper functionwm42016-09-132-27/+14
| | | | Only for the "new" vo_opengl backend code.
* vo_x11: fix some ifdefferywm42016-09-131-2/+2
| | | | This failed to compile when xext was not available.
* vo_opengl: mali fbdev supportwm42016-09-135-3/+188
| | | | | | | | | | | | Minimal support just for testing. Only the window surface creation (including size determination) is really platform specific, so this could be some generic thing with platform-specific support as some sort of sub-driver, but on the other hand I don't see much of a need for such a thing. While most of the fbdev usage is done by the EGL driver, using this fbdev ioctl is apparently the only way to get the display resolution.
* vo_opengl: factor some EGL context creation codewm42016-09-135-74/+122
| | | | | | | Add a function to egl_helpers.c for creating an EGL context and make context_x11egl.c use it. This is meant to be generic, and should work with other windowing APIs as well. The other EGL-using code in mpv can be switched to it.
* DOCS/interface-changes.rst: minor cleanupwm42016-09-131-19/+16
| | | | | | | Edit the 0.21.0 section: remove the redundant vo_opengl items, move some up. Move the additions (which are less important and which aren't documented completely anyway) below the incompatible changes/deprecations.
* manpage: vo_rpi -> vo_openglwm42016-09-131-1/+1
|
* vo_opengl: fix typo in bt.601 auto-guessing logicNiklas Haas2016-09-131-1/+1
| | | | | | | The wrong enum got copied here, so it was essentially using the transfer characteristics as the primaries (instead of the primaries), which accidentally worked fine most of the time (since the two usually coincided), but broke on weird/mistagged files.
* player: Save sub-speed value when resuming playbackVladimir Panteleev2016-09-131-0/+1
|
* player: Improve OSD formatting of sub-speed optionVladimir Panteleev2016-09-131-0/+4