summaryrefslogtreecommitdiffstats
path: root/player
Commit message (Collapse)AuthorAgeFilesLines
* options: take care of propertly updating options on runtime changeswm42016-09-173-3/+77
| | | | | | | | | | | | | | | | | | | | | | 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.
* command: make window-scale redirect to option if no window createdwm42016-09-171-1/+1
| | | | For consistency with other properties that mirror options.
* options: simplify M_OPT_EXITwm42016-09-171-1/+1
| | | | | | | | | | | | | 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.
* player: don't enter playloop for client API requestswm42016-09-161-2/+0
| | | | | | | | | | | 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.
* 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.
* player: use better way to wait for input and dispatching commandswm42016-09-164-16/+33
| | | | | | | | | | | | | | | | | | | 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-162-0/+4
| | | | | | | 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-1610-18/+46
| | | | | | | | | | | | | 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).
* 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-152-3/+2
| | | | | | | | | | | | | | | | 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.
* player: move builtin profiles to a separate filewm42016-09-151-50/+4
| | | | | | | | | 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-151-7/+0
| | | | | | | 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.
* 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
|
* player: Apply new sub-speed values during playbackVladimir Panteleev2016-09-131-0/+21
|
* ytdl_hook: don't bother adding subtitles if duration isn't knownRicardo Constantino2016-09-131-5/+3
| | | | EDL doesn't work with subtitles with unknown length.
* ytdl_hook: Support playlist entries without subtitlesRicardo Constantino2016-09-131-3/+17
| | | | | | | | | | | | | Fixes missing subtitle tracks if the first entry didn't have any. Previously it just checked for the first entry in the playlist for requested languages and if that entry happened to not have subtitles they also wouldn't show up for the other entries. It will skip languages if the first entry with subs has less or different languages than the others. Unrelated to http_dash_segments.
* command: don't log "ignore" command with -v verbositywm42016-09-111-1/+2
| | | | | It's damn annoying because the mouse move input event is mapped to this by default.
* client API: don't miss property changes after updatesJames Ross-Gowan2016-09-111-5/+3
| | | | | | | | | | | | | | | | | | When update_prop() successfully fetches a changed property value, it sets prop->changed to true. mark_property_changed() only sets prop->need_new_value if prop->changed is false, so this had the effect of ignoring new property values until prop->changed was set back to false in the next call to gen_property_change_event(). This meant that when a property change event was generated for a property that was not observed with MPV_FORMAT_NONE, it would contain the value associated with the earliest property change, rather than the most recent, and the property change event for the most recent change would never be generated. To fix this, mark_property_changed() should unconditionally set prop->changed and prop->need_new_value, which will cause the property value to be re-fetched and a property change event to be generated for the most recent value.
* options: make --h list options according to a pattern passed to itwm42016-09-101-0/+1
| | | | | | Useless feature, but I want it. Won't work on Windows due to missing fnmatch().
* command: do not call mp_switch_track() before proper initializationwm42016-09-101-7/+17
| | | | | | | | | | | This is an awful corner-case party, because we've started to allow the user to send track-switching related commands before stream selection is done in the loading stage. If mp_switch_track() is called before this stream selection, it can behave inconsistently. So if we're in the pre-loading phase, we must set the stream selection options to get streams selected later, instead of calling this function. There seem to be some annoying circumstances that exclude mp_switch_track() from handling this logic too, so do it at all call-sites.
* player: fix average frame duration calculationsda89ha92016-09-091-1/+1
|
* stream, demux, config: remove some dead/unneeded option-related codewm42016-09-093-21/+1
| | | | | | | | | | This has all been made unnecessary recently. The change not to copy the global option struct in particular can be made because now nothing accesses the global options anymore in the demux and stream layers. Some code that was accidentally added/changed in commit 5e30e7a0 is also removed, because it was simply committed accidentally, and was never used.
* client API: fix error code stringwm42016-09-091-1/+1
| | | | Said "audio" instead of "video".
* client API: make mpv_opengl_cb_uninit_gl() behavior slightly nicerwm42016-09-092-1/+9
| | | | | | Instead of deselecting the video stream plainly, use the slightly more robust error_on_track() function. Also give it an error code (although I'm not sure if this one is confusing, it's better than the one before).
* stream_dvd, stream_dvdnav: remove weird option parsing stuffwm42016-09-081-2/+2
| | | | | | Same deal as with stream_bluray. Untested because I don't give a fuck about your shitty DVDs.
* vo: don't access global options unsynchronizedwm42016-09-081-0/+11
| | | | | And since there's no proper fine-grained option change notification mechanism yet, intercept updates to "framedrop" manually.
* atomics: readd some emulationwm42016-09-061-0/+4
| | | | | | | | | | | This time it's emulation that's supposed to work (not just dummied out). Unlike the previous emulation, no mpv code has to be disabled, and everything should work (albeit possibly a bit slowly). On the other hand, it's not possible to implement this kind of emulation without compiler support. We use GNU statement expressions and __typeof__ in this case. This code is inactive if stdatomic.h is available.
* demux: do not access global optionswm42016-09-061-5/+1
| | | | | | | | | | | | | | | | | Don't access MPOpts directly, and always use the new m_config.h functions for accessing them in a thread-safe way. The goal is eventually removing the mpv_global.opts field, and the demuxer/stream-layer specific hack that copies MPOpts to deal with thread-safety issues. This moves around a lot of options. For one, we often change the physical storage location of options to make them more localized, but these changes are not user-visible (or should not be). For shared options on the other hand it's better to do messy direct access, which is worrying as in that somehow renaming an option or changing its type would break code reading them manually, without causing a compilation error.
* audio/out: deprecate "exclusive" sub-optionswm42016-09-051-0/+3
| | | | | | | And introduce a global option which does this. Or more precisely, this deprecates the global wasapi and coreaudio options, and adds a new one that merges their functionality. (Due to the way the sub-option deprecation mechanism works, this is simpler.)
* client API: implement mpv_suspend/resume slightly differentlywm42016-09-043-6/+18
| | | | | | | | Why do these API calls even still exist? I don't know, and maybe they don't make any sense anymore. But whether they should be removed or not is not a decision I want to make now. I want to get rid of mp_dispatch_suspend/resume(), though. So implement the client APIs slightly differently.
* command: try selecting the next track if track switching failswm42016-09-031-3/+4
| | | | | | | | | | | | This affects the "cycle" command. If we switched to the next track, and it failed to initialize, we just deselected everything. Change it so that if initialization fails early (typically decoder selection), we try to continue with the track after that. (Even if nothing can be selected, the loop will terminate when trying to select nothing. Fixes #3446.
* player: remove opengl-es=no flag from opengl-hq profilewm42016-09-031-1/+0
| | | | | | | | This was mistakenly added. It was removed from the vo_opengl_hq defaults at an earlier time, but the documentation was not updated, which is why it made it back into the profile. Fixes #3485.
* config: deprecate ao and vo auto-profileswm42016-09-031-0/+2
| | | | | | | | | These never made any sense. They checked the --vo/--ao option, and applied the profile corresponding to the first entry. So the only way to get any use of those was to use the --ao or --vo option explicitly. You can get the same functionality by making a manual profile, making these force the ao/vo, and then using --profile on command line instead of --vo/--ao.
* command: remove vo-cmdlinewm42016-09-021-13/+0
| | | | | | With the recent vo_opengl changes it doesn't do anything anymore. I don't think a deprecation period is necessary, because the command was always marked as experimental.
* vo_opengl: deprecate sub-options, add them as global optionswm42016-09-022-0/+36
| | | | | | | | | | | | | | | | | | | | | | | | vo_opengl sub-option were always rather annoying to handle. It seems better to make them global options instead. This is simpler and easier to use. The only disadvantage we are aware of is that it's not clear that many/all of these new global options work with vo_opengl only. --vo=opengl-hq is also deprecated. There is extensive compatibility with the old behavior. One exception is that --vo-defaults will not apply to opengl-hq (though with opengl it still works). vo-cmdline is also dysfunctional and will be removed in a following commit. These changes also affect opengl-cb. The update mechanism is still rather inefficient: it requires syncing with the VO after each option change, rather than batching updates. There's also no granularity (video.c just updates "everything", and if auto-ICC profiles are enabled, vo_opengl.c will fetch them on each update). Most of the manpage changes were done by Niklas Haas <git@haasn.xyz>.
* m_config: introduce basic mechanism to synchronize global option updateswm42016-09-022-0/+2
| | | | | | | | | | | | | | | | | | The way option runtime changes are handled is pretty bad in the current codebase. There's a big option struct (MPOpts), which contains almost everything, and for which no synchronization mechanism exists. This was handled by either making some options read-only after initialization, duplicating the option struct, using sub-options (in the VO), and so on. Introduce a mechanism that creates a copy of the global options (or parts of it), and provides a well-defined way to update them in a thread-safe way. Most code can remain the same, just that all the component glue code has to explicitly make use of it first. There is still lots of room for improvement. For example, the update mechanism could be better.
* player: don't send win32 taskbar update before window is createdwm42016-09-021-1/+1
| | | | | | | | | | | | | | | | | | If the win32 taskbar progress update is sent before the VO window is created, then w32_common.c will ignore it because the actual taskbar object was not created yet. (At least this is what I suspect happens. The window is already created at this point, but not mapped.) Hopefully fix this is fixed by creating until after the window is created, i.e. the VO has been configured at least once. Untested (who wants to boot into Windows just to wait until it has applied all of its stupid updates). Also not explicit is whether update_vo_playback_state() will actually be called soon enough in all cases. It probably is. Probably fixes #3482.
* command: deprecate "cache" property, replace with "cache-percent"wm42016-09-021-2/+4
| | | | | | The --cache option and cache property conflict, so one of them has to be renamed. The option is probably used frequently, so initiate deprecation/rename of the property.
* client API: create core thread at an earlier timewm42016-09-012-54/+47
| | | | | | | | | | | | | Create the core thread right in mpv_create(), and reduce what mpv_initialize() does further. This is simpler, and allows the API user to do more before calling mpv_initialize(). The latter is not the real goal, rather we'd like mpv_intialize() reduced to do almost nothing. It still does a lot, but nothing truly special anymore that is absolutely required for basic mpv workings. One thing we want the user to be able to do is changing properties before mpv_initialize() to reduce the special status of mpv_set_option().
* command: fix or document some property/option consistency issueswm42016-09-012-20/+17
| | | | | | | | | | | | | Make some existing properties behave more like options. This mostly means they don't deny access if the associated component is not active, but redirects to the option. One kind of fishy change is that we apply --brightness etc. only if they're not set to the default value. This won't necessarily work with --vo=xv, but affects only cases where 1. the Xv adapter has been changed to non-defaults, and 2. the user tries to reset them with mpv by passing e.g. --brightness=0. We don't care about Xv, and the noted use-case is dumb, so this change is acceptable.
* command: remove 2 deprecated propertieswm42016-09-011-50/+0
| | | | | They were delcared to be removed in mpv 0.20.0, and the next release will be 0.21.0.
* command: rename/deprecate some conflicting property nameswm42016-09-011-3/+7
| | | | | | These conflict with options of the same name, and prevent a "full" unification. Not addressed is the "cache" property, and possibly a few properties that behave differently from their equivalent options.
* command: add options to property listwm42016-09-014-40/+101
| | | | | | | | | | | Now options are accessible through the property list as well, which unifies them to a degree. Not all options support runtime changes (meaning affected components need to be restarted for the options to take effects). Remove from the manpage those properties which are cleanly mapped to options anyway. From the user-perspective they're just options available through the property interface.
* vo: change messy handling of fullscreen and other flagswm42016-08-301-10/+5
| | | | | | | | | | | | | | Before this commit, all VOs had to toggle the option flag themselves, now command.c does it. I can't really comprehend why it required every VO to do this manually. Maybe it was for rejecting the property/option change if the VO didn't support a specific capability. But then it could have checked the VOCTRL result. In any case, I don't care, and successfully changing the property without doing anything (With some VOs) is fine too. Many things work this way now, and it's simpler overall. This change will be useful for cleaning up VO option handling.
* options: make mp_vo_opts options an actual sub-option groupwm42016-08-304-12/+12
| | | | | | | | | | | Just a minor refactor along the planned option change. This commit will make it easier to update (i.e. copy) the VO options without copying _all_ options. For now, behavior should be equivalent, though. (The VO options were put into a separate struct quite early - when all global variables were removed from the source code. It wasn't clear whether the separate struct would have any actual purpose, but it seems it will now. Awesome, huh.)
* command: cosmetics: fix some minor whitespace mistakeswm42016-08-301-2/+2
|
* player: make --force-window work with opengl-cbwm42016-08-301-0/+1
| | | | | No reason not to? This probably avoids surprises if someone really tries to combine them.
* player: slightly adjust framerate guessing heuristicwm42016-08-291-6/+8
| | | | | | | | | | | | | | | | | | | | | | Some files not only use rounded timestamps, but they also do it incorrectly. They may jitter between up to 4 specific frame durations. In this case, I found a file that mostly used 41ms and 42ms, but also had 40ms and 43ms outliers (often but not always following each other). This breaks the assumption of the framerate estimation code that the frame duration can deviate up to 1ms. If it jitters around 4 possible frame durations, the maximum deviation is 3ms. Increase it accordingly. The change might make playback of "true VFR" video via display-sync mode worse, but it's not like it was particularly good in the first place. Also, the check whether to usen the container FPS needs to be stricter. In the worst case, num_dur is 1, which doesn't really indicate any evidence that the framerate is correct. Only if there are "enough" frames the deviation check will become meaningful. 16 is an arbitrary value that has been designated "enough" by myself. Also otuput the frame duration values for --dump-stats.
* command: export profile list as a propertywm42016-08-281-0/+17
| | | | | | | Targeted at scripts, which can do whatever they want with it. This comes with the promise that they could get randomly broken any time. See #977.
* player: add option to disable video OSDwm42016-08-281-4/+9
| | | | | | | | | | | | | | Normally, OSD can be disabled with --osd-level=0. But this also disables terminal OSD, and some users want _only_ the terminal OSD. Add --video-osd=no, which