summaryrefslogtreecommitdiffstats
path: root/mpvcore
Commit message (Collapse)AuthorAgeFilesLines
* command: when changing volume while muted, show an extra message on OSDwm42013-09-211-1/+2
| | | | | So nobody has to wonder why everything is silent, even if they raise the volume.
* command: when changing a property, allow showing an extra OSD messagewm42013-09-214-33/+50
| | | | | | | | | | This is for properties that normally show a bar, and thus do not show an OSD message (as per classic mplayer behavior). Setting an extra_msg allows showing an OSD message anyway, except if OSD messages are explicitly suppressed. This refactors the whole show_property_osd() function a bit, and replaces the weird sep field with a more general method.
* m_property: add a way to switch on property values in property expansionwm42013-09-201-3/+9
| | | | | | | | | | Allows for example: --status-msg='${?pause==yes:(Paused) } ...' to emulate the normal terminal status line. It's useful in other situations too. I'm a bit worried about extending this mini-DSL, and sure hope nobody will implement a generic formula evaluator at some point in the future. But for now we're probably safe.
* m_property: rearrange codewm42013-09-201-20/+27
|
* command: don't append, but prepend deinterlace filter by defaultwm42013-09-201-1/+1
| | | | | | In most cases, it's better if deinterlacing happens before any other filtering, so prepend the filter to the user's filter list, instead of appending it.
* command: use a list of potential deinterlacer filterswm42013-09-201-13/+22
| | | | | | | | Instead of hardcoding a single filter. This might be helpful for modeling the vaapi deinterlacer as a video filter. The idea is that a software deinterlacer would be tried first, and if that fails (because vaapi hardware decoding uses HW surfaces, which a software deinterlacer does not accept), the vaapi filter would be tried.
* Merge branch 'volume_restore'wm42013-09-205-61/+37
|\
| * mixer: make struct opaquewm42013-09-203-15/+14
| | | | | | | | Also remove stray include statements from ao_alsa and ao_oss.
| * mixer: allow accessing volume and mute property on disabled audiowm42013-09-201-8/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The volume is set as soon as the audio chain is created again. This works only in softvol mode. For system wide volume or otherwise externally user controllable volume, this code is intentionally disabled. It would be extremely weird if changing volume (while audio is not initialized) would do nothing, and then suddenly change it when the audio chain is created. There's another odd corner case: the user-set volume will be thrown away if it's set before the _first_ audio chain initialization. This is because the volume restore logic recognizes a change from nothing to softvol or an AO, and circumventing that would require additional code. Also, we don't even know the start volume before that point. Forcing the volume with --volume will can override the volume set during no-audio mode, depending on the situation.
| * mixer: restore volume with playback resumewm42013-09-204-2/+19
| | | | | | | | | | | | | | | | | | Note that this is intentionally never done if the AO or softvolume is different, or if the current volume control method is thought to control system wide volume (such as ALSA) or otherwise user controllable (such as PulseAudio). The intention is to keep things robust and to avoid messing with the user's audio settings as far as possible, while still providing the ability to resume volume if it makes sense.
| * mixer: refactor, fix some aspects of --volume handlingwm42013-09-192-36/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Refactor how mixer.c does volume/mute restoration and initialization. Move to handling of --volume and --mute to mixer.c. Simplify the implementation of these and hopefully fix bugs/strange behavior related to using them as file-local options (this uses a somewhat dirty trick: the option values are reverted to "auto" after initialization). Put most code related to initialization and volume restoring in probe_softvol() and restore_volume(). Having this code all in one place is less confusing. Instead of trying to detect whether to use softvol at runtime, detect it at initialization time using AOCONTROL_GET_VOLUME (same with mute, AOCONTROL_GET_MUTE). This implies we expect SET_VOLUME/SET_MUTE to work if the GET variants work. Hopefully this is always the case. This is also preparation for being able to change volume/mute settings if audio is disabled, and for allowing restoring value with playback resume.
| * mixer: minor refactoringwm42013-09-191-7/+4
| | | | | | | | | | Let struct mixer access access MPOpts to simplify some things. Rename some variables and functions. There should be no functional changes.
* | mplayer: rename a somewhat misnamed functionwm42013-09-191-2/+2
|/
* Config path functions can return NULLwm42013-09-181-3/+5
| | | | | | | It's quite unlikely, but functions like mp_find_user_config_file() can return NULL, e.g. if $HOME is unset. Fix all the code that didn't check for this correctly yet.
* macosx: move bundle path stuff to path-macosx.mStefano Pigozzi2013-09-181-6/+1
| | | | This makes the code uniform to how stuff was handled for Windows in 1cb55ceb.
* path, win32: redo user configfile path handlingwm42013-09-181-70/+15
| | | | | | | | | | | | | | | | | Remove the ifdef hell from mp_find_user_config_file(). Move the win32 specific code (for MinGW and Cygwin) to path-win.c. The behavior should be about the same, but I can't be sure due to lack of testing and because the old path.c code was hard to follow. (I expect those who care about windows will fix things, should issues pop up - sorry.) One difference is that the new code will always force MPV_HOME. It looks like the old code preferred the mpv config dir in the exe dir if it exists. Also, make sure MP_PATH_MAX has enough space, even if the equivalent wchar_t string is not 0-terminated with PATH_MAX (because apparently the winapi doesn't require this). (Actually, maybe we should just kill all uses of PATH_MAX/MP_PATH_MAX.)
* path: fix undefined behaviorwm42013-09-181-2/+2
| | | | | | | The homepath variable was static, and its value was set to a stack buffer. This means a second invocation of the function would trigger undefined behavior. Moreover the stack buffer always went out of scope before homepath was used.
* mplayer: read subtitle packets as soon as possiblewm42013-09-161-8/+5
| | | | | | | | | | | | | Call update_subtitles() on every iteration of the playloop, so that subtitle packets are read as soon as possible, instead of every time a video frame is displayed. This helps in case the packet queue is swamped with subtitle packets, which can happen with certain insane mkv files. The change will simply cause the subtitle queue to be emptied on each playloop iteration. The timestamps update_subtitles() uses for display are the same before and after this commit. (Important for files which have subtitle packets with timestamps or duration not set.)
* command: force video refresh when changing aspectwm42013-09-151-1/+2
| | | | | Pausing the player and changing the aspect would leave the VO without a frame to display.
* screenshot: change %w format to be more like %twm42013-09-151-8/+4
| | | | | | Instead of containing a format string within %w{...}, simply allow %w to specify one item of a time format string. This is simpler, more like other format specifiers (%t), and probably easier to use too.
* mplayer: attempt to skip playlist entries which can't be playedwm42013-09-154-5/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is for situations when repeated attempts at playing a playlist entry failed, and playlist navigation becomes impossible due to that. For example, it wasn't possible to skip backwards past an unplayable playlist entry: mpv file1.mkv doesntexist.mkv file3.mkv You couldn't skip back to file1.mkv from file3.mkv. When running a single "playlist_prev" command, doesntexist.mkv would be played, which would fail to load. As reaction to the failure to load it, the next file would be played, which is file3.mkv. To make this even worse, the file could successfully load, but run only for a split second. So just loading successfully isn't good enough. Attempt to solve this by marking problematic playlist entries as failed, and by having playlist_prev skip past such playlist entries. We define failure as not being able to play more than 3 seconds (or failing to initialize to begin with). (The 3 seconds are in real time, not file duration.) "playlist_prev force" still exhibits the old behavior. Additionally, use the same mechanism to prevent pointless infinite reloading if none of the files on the playlist exist. (See github issue All in all, this is a heuristic, and later adjustments might be necessary. Note: forward skips (playlist_next) are not affected at all. (Except for the interaction with --loop.)
* screenshot: make it possible to format playback time in various wayswm42013-09-151-0/+17
|
* mp_common: add function which accepts a format string to format playback timewm42013-09-152-11/+50
|
* mplayer: don't run heartbeat command while pausedwm42013-09-151-1/+1
| | | | | | | | This is commonly used to disable the screensaver with broken/non- standard X screensavers. During pause, the screensaver should not be disabled, so not calling this command while paused seems sensible. See github issue #236.
* av_log: show ffmpeg "info" messages with -v onlywm42013-09-151-1/+1
| | | | | | | | | | | | | | | | | They are rarely useful in my opinion. This commit was mainly motivated by this message: Video uses a non-standard and wasteful way to store B-frames ('packed B-frames'). Consider using a tool like VirtualDub or avidemux to fix it. It's what's left over from the "Invalid and inefficient vfw-avi..." warning that used to be printed when playing avi/divx files. Although the new message is much better, it's still rather useless and poses more questions than it answers. Besides, nobody wants to remux a file when playing it, especially not if playback appears to be completely fine. (There are some claims that these files raise CPU usage, but even my old crappy CPU can decode low res avi/divx files at real time at about x35 playback speed.)
* mplayer: m_option: fix clang -Wformat compiler warningStefano Pigozzi2013-09-142-2/+2
| | | | Code was using %d format instead %zd to print size_t data.
* mplayer: print a message when writing watch_later config for resumewm42013-09-131-0/+2
|
* mplayer: change "Playing" message printed before playback startwm42013-09-131-1/+1
| | | | | Change it from "Playing file." to "Playing: file". The idea is that it looks nicer without that trailing dot. (See github issue #229.)
* core: restore user-set video and audio filters with resume functionalitywm42013-09-132-0/+39
| | | | | This requires adding a function that converts the filter list back to a string.
* core: add --deinterlace option, restore it with resume functionalitywm42013-09-135-3/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The --deinterlace option does on playback start what the "deinterlace" property normally does at runtime. You could do this before by using the --vf option or by messing with the vo_vdpau default options, but this new option is supposed to be a "foolproof" way. The main motivation for adding this is so that the deinterlace property can be restored when using the video resume functionality (quit_watch_later command). Implementation-wise, this is a bit messy. The video chain is rebuilt in mpcodecs_reconfig_vo(), where we don't have access to MPContext, so the usual mechanism for enabling deinterlacing can't be used. Further, mpcodecs_reconfig_vo() is called by the video decoder, which doesn't have access to MPContext either. Moving this call to mplayer.c isn't currently possible either (see below). So we just do this before frames are filtered, which potentially means setting the deinterlacing every frame. Fortunately, setting deinterlacing is stable and idempotent, so this is hopefully not a problem. We also add a counter that is incremented on each reconfig to reduce the amount of additional work per frame to nearly zero. The reason we can't move mpcodecs_reconfig_vo() to mplayer.c is because of hardware decoding: we need to check whether the video chain works before we decide that we can use hardware decoding. Changing it so that this can be decided in advance without building a filter chain sounds like a good idea and should be done, but we aren't there yet.
* macosx: always active bundle path lookup if cocoa is activeStefano Pigozzi2013-09-121-2/+2
| | | | | This is not really something you want to disable anyway. If there is no bundle the code already does it's falbacks anyway.
* mpvcore/path: Fix non-MinGW buildsMartin Herkt2013-09-121-2/+5
| | | | Well that was dumb.
* mpvcore/path: Fix config path handling on WindowsMartin Herkt2013-09-121-5/+21
| | | | | | | | | | | | | | | | | | | | | | | | Previously, mpv incorrectly used the %HOME% environment variable on MinGW to determine the current user’s home directory. This is wrong; the correct variable to use would be %HOMEPATH%, which would however still be wrong since application data goes into the application data directory, not the user’s home. This patch makes it use the local AppData path instead of reading an environment variable. This however exposed another problem (which also affected users who actually had the %HOME% variable set): b2c2fe7a3782 (discussed in issue #95) introduced some changes that make mpv load user config files from the executable path on Windows. The problem with this change is that config_dir was still declared static, so once a config file had been found in the executable path, it would set config_dir to an empty string, so mpv would dump e.g. watch_later data straight into the user’s home. This commit also fixes that. One side effect of this is that mpv no longer considers the “mpv” subdirectory in the executable path (that behavior resulted from the homedir variable always being empty), unless it is somehow unable to determine the local AppData path.
* input: fix accidental NULL pointer dereferencewm42013-09-111-2/+2
| | | | | | | This could happen if the input queue was full, and an unmapped key was used, or something like this. Possibly fixes github issue #224.
* input: convert to new msg APIStefano Pigozzi2013-09-103-27/+26
|
* mplayer: remove duplicated mouse autohide checkStefano Pigozzi2013-09-101-2/+0
|
* mplayer: print libquvi results in verbose modewm42013-09-101-0/+31
| | | | Helpful for debugging.
* quvi: restore playback position when switching formatswm42013-09-102-1/+9
| | | | This simply issues a seek after reloading.
* quvi: coerce libquvi 0.4 support into allowing format switchingwm42013-09-103-6/+30
| | | | | | | | | | | | | libquvi 0.4 doesn't allow us listing the formats supported by a streaming site without doing additional network accesses, so switching formats was not supported with it. (It's different with libquvi 0.9.) But the most important case is switching between SD and HD. Usually, --quvi-format=default will get SD, while --quvi-format=best gives HD. Use this, and pretend that an URL supported by libquvi 0.4 supports both of these. "cycle quvi-format" will switch between these. If the user specifies something else via --quvi-format, this is included in the list of switchable formats additionally to "default" and "best".
* command: make title property unavailable if there's no supportwm42013-09-101-3/+3
| | | | | Instead of returning 0 if the stream doesn't have title info, make the property unavailable.
* mplayer: mentioned --list-options in --help outputwm42013-09-101-1/+3
| | | | | | It's annoying for users if you can't get a list of options with --help, but on the other hand, printing all options would be overkill. So just mentioned --list-options.
* demux: retrieve per-chapter metadatawm42013-09-081-2/+15
| | | | | | | | | | Retrieve per-chapter metadata, but don't do much with it. We just make the metadata of the _current_ chapter available as chapter-metadata property. Returning the full chapter list with metadata would be no problem, except that the property interface isn't really good with structured data, so it's not available for now. Not sure if it's worth it, but it was requested via github issue #201.
* demux: refactor tag handlingwm42013-09-081-13/+23
| | | | | Make the code somewhat reuseable, instead of bound to a single demuxer instance. The plan is to add support for per-chapter tags later.
* core: remove a minor memory leakwm42013-09-082-0/+2
|
* mplayer: cosmetics: split some code off of run_playloop()wm42013-09-081-117/+159
| | | | | | run_playloop() is already stuffed enough. This function is still quite big, but all the other code shares various variables, so it's not as easy to split.
* mplayer: add --cursor-autohide-fs-only optionwm42013-09-084-19/+26
| | | | | | | | This option makes the cursor always visible in windowed mode. Apparently, this is what (some?) Windows and OSX users expect. It's disabled by default for now. Restructure the cursor hide logic a bit for this purpose.
* options: remove --(no-)mouseinput optionwm42013-09-082-3/+0
| | | | I have no idea why it exists, as it's redundant to --(no-)mouse-movements.
* options: cosmetics: move cursor_autohide_delay definitionwm42013-09-083-7/+8
| | | | No functional changes.
* input: rearrange codewm42013-09-081-44/+44
| | | | | | Let all key events go through mp_input_feed_key() internally, and also do double click and MP_INPUT_RELEASE_ALL handling there. Move check_autorepeat() to where it's actually used.
* input: don't deliver mouse events if mouse area is not setwm42013-09-082-4/+12
| | | | | | | | | | | | | | | | | | | | | This caused the OSC to be always visible at startup on X11: - EnterNotify event send a mouse event to input.c - OSC has not completely initialized yet, and no mouse area is set - mouse event is dispatched to "showhide" OSC section - OSC becomes visible, regardless of mouse position Fix this by treating the mouse area as empty if it's not set, instead of infinite as it was before this commit. This means an input section must set a mouse area to receive mouse events at all. We also have to change the default section to receive mouse events with the new behavior. Also, if MOUSE_MOVE is unmapped (or mapped to something that doesn't parse), and produces no command, the mouse position wouldn't be updated (because the mouse position is bound to input commands), so we have to generate a dummy command in this case. (This matters only for the OSC, On Screen Controller, which isn't merged yet, so these changes shouldn't have much effect right now.)
* input: merge consecutive mouse move eventswm42013-09-081-0/+14
| | | | Might give better behavior on load.
* input: split queue_add() functionwm42013-09-081-20/+20
| | | | | Split it into queue_add_head() and queue_add_tail(). Gets rid of the weird, rarely used boolean parameter.
* input: redo what input events can be droppedwm42013-09-081-57/+65
| | | | | | | | | | | | | | | | Until now, any command was dropped as soon as the input queue was full, and the command was not an abort command (i.e. a command that exits the player or goes to the next file). This could cause issues with key down events (especially mouse buttons) not being released. Change it so that key up events can never be dropped. This is a bit involved, because we know whether a key maps to an abort command only after interpreting it, and interpreting it changes global state, which in turn requires undoing the event if the input is dropped. Refactor the code a bit to move more functionality into interpret_key() to make this easier.
* input: remove separation between key and control queuewm42013-09-081-16/+10
| | | | | This is actually quite useless. It also allows the control queue to starve the key queue, because the control queue is always checked first.
* mplayer: don't auto-load explicitly loaded subtitle fileswm42013-09-071-1/+7
| | | | | | | | | | | Even if a subtitle was explicitly loaded with -sub, it was still auto- loaded (if auto-loading applied to that file). Fix this by explicitly checking whether a file is already loaded. The check is maximal naive and just compares the filenames as strings. The change in find_subfiles.c is so that "-sub something.ass" happens to work (auto-loading prepended a "./" to it, so the naive filename comparison check didn't work).
* mp_core: fix a commentwm42013-09-071-2/+1
| | | | track.demuxer is never NULL (anymore).
* mplayer: remove unused mp_add_subtitles() parameterwm42013-09-073-6/+6
|
* command: make options writeable in idle modewm42013-09-073-0/+13
| | | | | | | | | | | | Until now, options could be accessed as properties via "options/name", but the access was read-only. Change it so that write access is possible