summaryrefslogtreecommitdiffstats
path: root/mpvcore
Commit message (Collapse)AuthorAgeFilesLines
* options: fix --volume option range, add some explanations to manpagewm42013-09-071-1/+1
| | | | | | | | The --volume option accepted values up to 10000, but internally, the value is always clipped to 0-100 range. What makes this even worse is that --softvol-max suggests that it extends the range of --volume, which is not the case. (And passing a volume larger than 100 to --volume didn't even print a warning.)
* input: don't print warning if certain internal keys are not boundwm42013-09-061-2/+5
| | | | | | | | | | | This affects MOUSE_MOVE and MOUSE_LEAVE. Both are needed internally (such as for the OSC), but not really useful for input.conf. Since the warning has the purpose of notifying the user that a key is unmapped and what key name to use for setting up a binding in input.conf, the warning is rather useless in this case. It's also annoying in combination with the --no-input-default-bindings option, since that removes the default bindings to "ignore" for these keys.
* mplayer: try to resume playback only if a resume file actually existswm42013-09-051-1/+1
| | | | | Well, this was dumb. The resume message was printed for every file, whether a resume config file existed or not.
* mpvcore/input: Fix build without pthreadsMartin Herkt2013-09-051-3/+5
|
* mplayer: print informative message when resuming playbackwm42013-09-041-0/+2
| | | | In particular, this informs the user how to disable this.
* mplayer: make --save-position-on-quit save only on quitwm42013-09-041-2/+1
| | | | | | | | | | | | When enabling --save-position-on-quit, playback position stored not only on quit, but in any case playback of a file was stopped. This includes going to the next file with playlist navigation commands. After some discussion on IRC, it turned out that nobody thought this was good behavior. Disable it, and really make it save only on quit. Maybe the option is useless now, as the user could remap the CLOSE_WIN key binding. On the other hand, CLOSE_WIN sounds and _is_ a bit obscure.
* mplayer: always write playback resume info, even at start/end of filewm42013-09-041-3/+3
| | | | | | | | | | | | | | | | | | Before this commit, the player didn't write resume info if the playback position was within the first or last percent of the file. This was sometimes annoying, and with playlist resume can lead to unintuitive behavior. (It wouldn't resume the playlist if the currently played file was at 0-1% or 99-100%, even if you were in the middle of a playlist.) Moreover, the "percent > 99" check is a bit bogus anyway, because 100 (in integer) is rarely reached. Drop the check, and make sure using --save-position-on-quit won't write resume info when reaching EOF. The latter check is needed to make sure playback of the file starts at beginning when playing it again after EOF.
* path: better check for mp_is_url()wm42013-09-041-3/+11
| | | | | | | | | | | The previous check just searched for a "://" substring. This was quite bad, because "://" can be a valid part of a path. Later, I added special handling for filenames starting with "." and "/", so that you could reliably pass arbitrary filenames to mpv, no matter how messed up they were. Even though it doesn't really matter in practise anymore, this is still crap, so add a more reliable check instead.
* mplayer: allow resuming from playlistwm42013-09-043-3/+26
| | | | | | | | | | | | | | | | | | This includes the case of passing multiple files to command line (internally this is the same as loading a playlist). Resuming works by finding the first playlist entry that can be resumed. Alternative implementations would be possible, such as hashing the playlist contents. But this implementation is simpler, and doesn't have the disadvantage that changes to the playlist (like appending entries) will throw away the resume point. This makes loading large playlists a bit slower, because it has to look into ~/.mpv/watch_later/ for every entry. Loading a 15000 entries playlist now increases from 150ms to 400ms. Considering you rarely load playlists this big with mpv (because it's impractical considering the terminal and non-GUI nature of the player), this is probably ok.
* command: unescape URLs for ${filename} and ${media-title}wm42013-09-041-2/+7
| | | | | | | | | | | Undo URL percent encoding if the filename appears to be an URL. This will fix display of the actual filename in some cases. We don't put any effort into checking whether the URL is really percent encoded, because we don't really know how the protocol handler is going to interpret the URL. For stream_lavf, we probably can't know. Still, from the perspective of this commit, it seems to make sense to assume they are percent encoded.
* path: add a common mp_is_url() functionwm42013-09-044-12/+14
| | | | Remove the duplicated code.
* mplayer: handle --reset-on-next-file=""wm42013-09-041-4/+6
| | | | | | | The option list contains an empty string member with this option value, so ignore that. I'm not sure whether the option list should maybe be empty in this case, but it could be the wrong thing in case of other options.
* mplayer: don't let playback resume force options that are file localwm42013-09-041-11/+11
| | | | | | | | This happens by default with pausing: if a file was paused when doing quit_watch_later, then resume and unpause, then the file played after that would start in paused mode. This is because the pause option is backed up at thr wrong place, so it backs up the state from resuming, instead of whatever it was set to before that.
* mplayer: fix race condition on uninit with CocoaStefano Pigozzi2013-09-011-0/+4
| | | | NULL out Cocoa's reference to mplayer's input context before deallocating it
* input: unlock playloop thread during selectStefano Pigozzi2013-09-011-0/+2
| | | | | | This allows other threads to use mp_input_put_key without blocking if the playloop is doing the 500ms select call (i.e.: during pause). Makes Cocoa GUI responsive again (regression since 2d363c3).
* osx: use MP_KEY_* instead of MK_* for media keysStefano Pigozzi2013-09-012-10/+0
| | | | | In 213ad5d6c I added `MK_*` key bindings overlooking the fact that mpv already has `MP_KEY_*` for media keys.
* input: allow window dragging even if mouse is in a mouse areawm42013-09-012-4/+13
| | | | | | If the input section is enabled with MP_INPUT_ALLOW_VO_DRAGGING, then the VO will be allowed to drag the window with mouse button down + mouse move even if the mouse is inside the section's mouse area.
* input: deal with spurious X11 LeaveNotify eventswm42013-09-011-6/+0
| | | | | | | | | | | | | | | | | | | | | If the mpv window is unfocus, clicking on the OSC should focus the window (done by the window manager) and allow interaction with the OSC. But somehow X sends a spurious LeaveNotify event, immediately followed by an EnterNotify event. This happens at least with IceWM. The result is that the OSC will disappear (due to receiving MOUSE_LEAVE). The OSC will stay invisible, because EnterNotify isn't handled, and there's nothing that could make the OSC appear again. Solve this by handling EnterNotify. We cause a redundant MOUSE_MOVE event to be sent, which triggers the code to make the OSC visible. We have to remove the code from input.c, which ignores redundant mouse move events. Since the code ignoring redundant mouse move events is still needed on Windows, move that code to w32_common.c. The need for this is documented in the code, also see commit 03fd2fe. (The original idea was to save some code by having this code in the core, but now it turns out that this didn't quite work out.)
* input: print more debug infos, raise loglevelwm42013-09-012-2/+23
|
* input: stay in current input section if mouse button is downwm42013-09-011-28/+63
| | | | | | | | | | | | | | | | | Normally, moving the mouse outside of the mouse area of an input section will send mouse events somewhere else (because input section mouse areas are similar to windows/widgets in real GUI toolkits). This was done even if a mouse button was held down. This is quite different from how GUI toolkits behave. Change the code so that if a mouse button is down, the mouse area of the current input section can't be left. Releasing the mouse button (while the mouse pointer is outside of the mouse area) will actually leave the mouse area. As a side-effect, this commit also tests more often whether the current mouse input section is valid. This is needed to make releasing a mouse button trigger the mouse input section change.
* input: add some more X11 multimedia/internet keyswm42013-09-012-1/+13
| | | | | | | | These keys can be found on various "multimedia" and "internet" keyboard. X defines many keycodes, so I'm not adding all, just what I found on my own keyboard. Other key codes can be added on request.
* keycodes: cosmetics: align indentationwm42013-09-011-113/+113
|
* input: comment all default bindings in input.confwm42013-09-011-1/+9
| | | | | | | | | | | | | | I suspect most users will just copy etc/input.conf when they want to remap some default bindings. But usually this means the user even copies bindings he doesn't care about, and it's better if the user maps only the bindings in his input.conf the user intends to remap. Comment all bindings in etc/input.conf. Since this file also defines the builtin defaults and is baked into the mpv binary, we have to do something to get them anyway, even though they are commented. Do this by having input.c "uncomment" the bindings in the baked in input.conf. (Of course this is done only for the builtin config, not configs loaded from disk.)
* input: lock for accessing struct input_ctxStefano Pigozzi2013-09-011-67/+114
| | | | | | | | | | | | | | The previous code was locking only the input queue. That was too weak since it didn't protect the input_ctx data structure. So remove the locking on the queue and lock all the public functions that interact with the input_ctx. The private functions and public functions that do not act on the input_ctx (there are quite some functions doing mp_cmd manipulations for instance) are not locked. Some changes by wm4. Use a recursive mutex, and restructure some code to be less annoying with locks, such as converting code to single return, or making use of the recursive mutex.
* video: add unscaled mode with --video-unscaledwm42013-09-013-0/+3
|
* input: fix --no-input-default-bindingswm42013-08-291-0/+2
| | | | The option did nothing. This was probably broken with 5b38a52.
* demux_playlist: port ini reference playlist parserwm42013-08-281-36/+0
| | | | | | | | | | Port it from playlist_parser.c to demux_playlist.c. Also, change the m3u parser to drop whitespace from the trailing part of the line (will make it work properly with windows line endings). (I hoped that this would make MMS URIs with http instead of mmsh prefixes work, but it doesn't. Instead, it leads to a playlist loop. So solving this issue would require a change in ffmpeg, probably.)
* core: add a playlist demuxerwm42013-08-269-87/+59
| | | | | | | | | Modeled after the old playlist_parser.c, but actually new code, and it works a bit differently. Demuxers (and sometimes streams) are the component that should be used to open files and to determine the file format. This was already done for subtitles, but playlists still use a separate code path.
* audio: make internal audio format 0 an invalid formatwm42013-08-262-2/+2
| | | | | | | | | | | | Having to use -1 for that is generally quite annoying. Audio formats are created from bitmasks, and it can't be excluded that 0 is not a valid format. Fix this by adjusting AF_FORMAT_I so that it is never 0. Along with AF_FORMAT_F and the special formats, all valid formats are covered and guaranteed to be non-0. It's possible that this commit will cause some regressions, as the check for invalid audio formats changes a bit.
* video: handle video output levels with mp_image_paramswm42013-08-242-18/+11
| | | | | | | | | | | | Until now, video output levels (obscure feature, like using TV screens that require RGB output in limited range, similar to YUY) still required handling of VOCTRL_SET_YUV_COLORSPACE. Simplify this, and use the new mp_image_params code. This gets rid of some code. VOCTRL_SET_YUV_COLORSPACE is not needed at all anymore in VOs that use the reconfig callback. The result of VOCTRL_GET_YUV_COLORSPACE is now used only used for the colormatrix related properties (basically, for display on OSD). For other VOs, VOCTRL_SET_YUV_COLORSPACE will be sent only once after config instead of twice.
* video/out: don't require VOs to handle screenshot aspect speciallywm42013-08-241-0/+1
| | | | | | | | | | | | | | | | This affects VOs which just reuse the mp_image from draw_image() to return screenshots. The aspect of these images is never different from the aspect the screenshots should be, so there's no reason to adjust the aspect in these cases. Other VOs still need it in order to restore the original image attributes. This requires some changes to the video filter code to make sure that the aspect in the passed mp_images is consistent. The changes in mplayer.c and vd_lavc.c are (probably) not strictly needed for this commit, but contribute to consistency.
* Some more mp_msg conversionswm42013-08-231-1/+1
| | | | | Also add a note to mp_msg.h, since it might be not clear which of the two mechanisms is preferred.
* demux: remove unused audio_delay parameter from demux_seek()wm42013-08-221-6/+4
| | | | Used to be needed by demux_avi.
* mp_msg: fix typo in message level for new msg API macrosStefano Pigozzi2013-08-221-2/+2
|
* mplayer: replace "D:" in status line with "Late:"wm42013-08-211-1/+1
| | | | | | | | | | Too many people thought "D:" really meant number of dropped frames. But it's actually the number of frames where the playloop thought it'd be a good idea to drop them. Of course this does nothing if frame dropping is disabled, but even with normal frame dropping, this doesn't indicate whether a frame was _really_ dropped. (Looks like libavcodec doesn't even give us this information reliably? The decode function can return no frame in case of codec delay due to threading and such.)
* options: replace --edition=-1 with --edition=autowm42013-08-211-1/+2
| | | | | | Originally, the objective of this commit was changing --edition to be 1-based, but this was cancelled. I'm still leaving the change to demux_mkv.c though, which is now only of cosmetic nature.
* mplayer: start track IDs from 1 rather than 0wm42013-08-212-2/+2
| | | | | | Completely pointless, but makes ChrisK happy for some reason. Track ID 0 is now rejected by the option parser itself.
* command: simplify video brightness/gamma/etc. handling a bitwm42013-08-201-44/+17
| | | | | | | | | | | | | We don't need to store the offsets of the options corresponding to the properties, because the option-property bridge knows about this already. The check against 1000 was for the case if e.g. the --brightness option is not used. Always overwrite the option value instead, both when querying and setting the property. (This is needed to make the settings persistent even if vf_eq is used and the video chain is reinitialized.) This commit assumes that VFCTRL_SET_EQUALIZER is always paired with VFCTRL_GET_EQUALIZER (likewise for VOCTRL), which is the case.
* m_option: make "add speed 0.1" command workwm42013-08-191-0/+1
| | | | Was broken since the speed property was switched from float to double.
* mp_core: declare seek_type enum outside of nested structwm42013-08-191-3/+8
| | | | cosmetic change. See previous commit.
* m_option: rename struct member named "new"wm42013-08-192-5/+5
| | | | | | Cosmetic change to allow C++ code to include this header. See github issue #195.
* video: make it possible to scale/pan the video by arbitrary amountswm42013-08-193-4/+17
| | | | | | | | | | | Add --video-align-x/y, --video-pan-x/y, --video-scale options and properties. See the additions to the manpage for description and semantics. These transformations are intentionally done on top of panscan. Unlike the (now removed) --panscanrange option, this doesn't affect the default panscan behavior. (Although panscan itself becomes kind of useless if the new options are used.)
* options: remove --panscanrange optionwm42013-08-192-3/+0
| | | | | | This option allowed you to extend the range of the panscan controls, so that you could essentially use it to scale the video. This will be replaced by a separate option to set the zoom factor directly.
* mplayer: reshuffle on every loop if --loop and --shuffle are usedwm42013-08-194-23/+7
| | | | | | | | | | See github issue #194. Unfortunately, this breaks the property that going back in the playlist always works as expected. This changes, because the playlist_prev command will work on the reshuffled playlist, instead of loading the previously played files in order. If this ever becomes an issue, I might revert this commit.
* mplayer: don't make restored options from quit_watch_later per-file localwm42013-08-171-6/+8
| | | | | | | | | | | | | | | Consider: mpv file1.mkv file2.mkv and file1.mkv is restored from an earlier session when quit_watch_later was used. Then all restored options were reset when file2.mkv is played, even if the user changed them during playback. This affects for example the fullscreen setting. Make it so that after finishing a resumed file, the previously restored settings are not reset again. (Which means only resuming will forcefully overwrite the settings.)
* command: more intuitive chapter seek behaviorPhilip Sequeira2013-08-173-1/+26
| | | | | | | | | If close to chapter start, skipping back goes to previous chapter (no change). If more than <threshold> seconds in, skipping back will now go to the beginning of the current chapter instead. The threshold is set by the new option --chapter-seek-threshold and defaults to 5 seconds. A negative value disables the new functionality.
* command: allow seek to "chapter -1"Philip Sequeira2013-08-172-3/+8
| | | | | This will seek to the start of the file regardless of whether the first real chapter starts there or not.
* m_option: add missing copy callback for some option typeswm42013-08-171-0/+5
| | | | | One reaosn for this is that this broke proper handling of .defval, since m_option_copy did nothing for these option types.
* m_option: make defval constwm42013-08-171-1/+1
| | | | There's really no reason why it shouldn't.
* sub: don't print detected charset if it's UTF-8wm42013-08-152-4/+9
| | | | | Too noisy. This also fixes that iconv() was called if "utf8" was used as codepage.
* sub: make --subcp=enca the default.wm42013-08-151-0/+5
|
* sub: allow specifying a fallback codepage if input is not UTF-8wm42013-08-151-2/+10
| | | | | | | | | | | | | | | Normally, --subcp always forces conversion. This really always forces conversion, even if the UTF-8 check on the input succeeds. Extend the --subcp to allow codepages as fallback if UTF-8 doesn't work. So, for example --subcp=utf8:cp1250 will use UTF-8 if the input looks like UTF-8, and will fall back to use cp1250 if the UTF-8 check fails. I think this should actually be the default, but on the other hand, this changes the semantics of the option, and a user would actually expect --subcp to force conversion, rather than silently using UTF-8 if that happens to work.
* bstr: make UTF-8 check stricterwm42013-08-151-0/+8
| | | | | | | | | | | | | | | | | | | | | | | Don't accept overlong sequences. Don't accept codepoints past the maximum unicode codepoint. Don't accept the UTF-16 surrogate codepoints. I'm not sure if there are more codepoints that are defined to be invalid, but we just want to make libavcodec happy, so this is enough. (libavcodec's subtitle converter checks for valid UTF-8 and throws up and dies if it's not - now we want to use bstr_sanitize_utf8_latin1() to force valid UTF-8, so the strictness of our UTF-8 parser has to match at least that of the libavcodec's check.) I'm not sure whether the min test is actually 100% correct. Note that libavcodec also treats BOM codepoints as invalid. This is definitely a bug: the BOM is really just "zero-width non-breaking space" redefined by Microsoft, but it is perfectly valid to appear in the middle of a string. Official Unicode has merely deprecated the old usage of the BOM codepoint, and didn't make it illegal. Besides, the string could be from the start of a file, so even this check doesn't make sense even with libavcodec's insane logic. We don't copy this bug.
* sub: if charset detection fails, treat it as broken UTF-8wm42013-08-152-7/+17
| | | | | | | | | | | Broken UTF-8 in this context means we treat it as UTF-8, but we also interpret broken UTF-8 sequences as Latin1. Also, run our own UTF-8 check function before the charset detectors. This prevents from ENCA's UTF-8 check possibly messing up (like detecting 7-bit clean UTF-8 as ASCII, or other things). It also takes care of UTF-8 detection if no charset detector (ENCA, libguess) is compiled in, and it lets us deal better with cut-off UTF-8 sequences.
* bstr: add UTF-8 validation and sanitation functionswm42013-08-152-1/+81
|
* input: fix build if HAVE_PTHREADS is undefinedGiuliano Schneider2013-08-151-1/+1
|
* macosx: remove platform specific input queueStefano Pigozzi2013-08-131-3/+0
| | | | | Since last commit the input queue in the core is thread safe, so there is no need for all this platform specific stuff anymore.
* input: make input queue thread safeStefano Pigozzi2013-08-131-6/+35
| | | | | | | If pthreads are enabled the input queue acce