summaryrefslogtreecommitdiffstats
path: root/player
Commit message (Collapse)AuthorAgeFilesLines
* player: allow passing number of loops to --loop-filewm42014-09-221-0/+2
| | | | | | | | | | E.g. --loop-file=2 will play the file 3 times (one time normally, and 2 repeats). Minor syntax issue: "--loop-file 5" won't work, you have to use "--loop-file=5". This is because "--loop-file" still has to work for compatibility, so the "old" syntax with a space between option name and value can't work.
* command: no space before "%" in volume default OSD messagewm42014-09-221-1/+1
| | | | | | More consistent with other output, such as the terminal status line. Also see issue #1103.
* video: filter new frames at a better time (2)wm42014-09-221-7/+9
| | | | | | | | | | | | | | | | | We generally want 2 things: 1. minimal wakeups for decoding each frame 2. minimal number of frames decoded on continuous seeking Commit 35810cb8 changed this a bit, and fixed 1. But it broke 2., and now it decodes 2 frames instead of 1 when you keep seeking (arrow key held down or such). This made seeking appear slower. Fix this by making the logic more explicit. In particular, call the filters only if we actually try to get a new frame. When playing with --no-audio and all other distractions disabled (like OSC), it still wakes up 2 times per frame - but the second time is merely because the VO didn't accept the new frame yet.
* osd: fix --term-osd=nowm42014-09-221-1/+1
| | | | | | | It didn't actually disable it. I'm actually not sure what this option is useful for, but fixing it can't harm.
* command: improve "osd" commandwm42014-09-222-10/+9
| | | | | | | Be less annoying, print the actual OSD level instead of something meaningless, but still clear the OSD if OSD level 0 (no OSD) is set. Remove the special handling for terminal OSD, that was just dumb.
* command: use show_property_osd() sub_stepwm42014-09-221-2/+1
| | | | Simpler and more consistent.
* command: when changing a property, always show it on OSDwm42014-09-211-1/+4
| | | | | | | | | | | | | This means that if a property not listed in property_osd_display[] is changed, it will be shown on the OSD as "name: ${name}". Properties that are listed in property_osd_display[] and have osd_name not set stay invisible by default. This is used for "pause" and "fullscreen", which (like before this commit) are not shown by default, because it would be annoying. The defaults still can be changed with command prefixes (osd-msg, no-osd, others).
* command: simplify OSD property display codewm42014-09-213-54/+42
| | | | | | | | | | | | | | | | Probably not many user-visible changes. One notable change is that the terminal OSD code for OSD bar fallback handling is removed with no replacement. Instead, terminal OSD gets the same text message as normal OSD. For volume, this is ok, because the text message is reasonable. Other properties will look worse, but could be adjusted, and there are in fact no other such properties that would be useful in audio-only mode. The fallback message for seeking falls away as well, but that message was useless anyway - the terminal status line provides all information anyway. I believe the show_property_osd() code is now much easier to follow.
* command: allow changing some OSD-related options even with no VOwm42014-09-211-2/+0
| | | | | | | If no VO was open, these options couldn't be changed or even queried. Although these properties are nearly useless if no VO exists, there's actually no good reason to forbid querying or setting them. Also, even if the VO is created, it doesn't mean the VO window was created.
* command: remove unneeded ifdefswm42014-09-211-4/+4
| | | | | | | | Why bother? Also, since now some properties could be mapped to non-existing options, but mp_property_generic_option() is used, deal with this case and return a not-found error code.
* command: always show OSD message when changing volume etc.wm42014-09-211-15/+3
| | | | | | | | | | | | | | If there's a command that uses the OSD by default, then always print the associated message (or a fallback made of name + value), even if the command has an associated OSD bar. This means volume, gamma, panscan, etc. all show both a message and a OSD bar. Also, add a '%' to the volume message. The extra_msg thing is not needed anymore. See issue #1103.
* options: remove --volstepwm42014-09-211-1/+1
| | | | | | | It's just confusing; users are encouraged to edit input.conf instead (changing the argument to the "add" command). Update input.conf to keep the old behavior.
* player: rename "Late:" field to "SD:"wm42014-09-201-1/+1
| | | | | | | | | Follow up to previous commit. This is probably confusing from a user point of view, since this field shouldn't show up normally anymore. (Before this commit, it could show up sporadically when a slow operation was performed during playback, such as switching fullscreen.)
* video: actually count decoder-dropped frameswm42014-09-201-4/+7
| | | | | | | | | Normally, feeding a packet to the decoder should always return a frame _if_ we received a frame before. So while we can't know exactly whether a frame was dropped, at least the normal case is easily detectable. This means we display something closer to the actual framedrop count, instead of a bad guess.
* video: improve decoder-based framedropping modewm42014-09-201-6/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the "old" framedropping mode (derived from MPlayer). At least in the mplayer2/mpv source base, it stopped working properly years ago (or maybe it never worked properly). For one, it depends on the video framerate, which assume constant framerate. Another problem was that it could lead to freezing video display: video could get so much behind that it couldn't recover from framedrop. Make some small changes to improve this. Don't use the current audio position to check how much we are behind. Instead, use the last known A/V difference. last_av_difference is updated only when a video frame is scheduled for display. This means we can keep stop dropping once we're done catching up, even if video is technically still behind. What helps us here that this forces a video frame to be displayed after a while. Likewise, we reset the dropped_frames count only when scheduling a new frame for display as well. Some inspiration was taken from earlier work by xnor (see issue #620), although the implementation turned out quite different. This still uses the demuxer-reported (possibly broken) FPS value. It also doesn't account for filters changing FPS. We can't do much about this, because without decoding _and_ filtering, we just can't know how long a frame is. In theory, you could derive that from the raw packet timestamps and the filter chain contents, but actually doing this is too involved. Fortunately, the main thing the FPS affects is actually the displayed framedrop count.
* player: make code more obviouswm42014-09-201-2/+2
| | | | Or at least I think so.
* player: use backwards flag for seeking external trackswm42014-09-201-1/+1
| | | | | Otherwise, the external track could end up at a position that's too late.
* player: reset last_av_difference if not applicablewm42014-09-202-0/+2
| | | | | | Don't let stale values linger around. Also fix a slightly related case in audio.c.
* video: separate calling decoder/filterwm42014-09-181-14/+22
| | | | | | | | | | | Rename video_decode_and_filter to video_filter, and add a new video_decode_and_filter function. This function now calls the decoder. This is done so that we can check filters a second time after decoding, which avoids a useless playloop iteration. (This and the previous commits are really just microoptimizations, which simply reduce the number of times the playloop has to recheck everything.)
* video: check whether there are enough frames after filteringwm42014-09-181-6/+11
| | | | | | | Move the check to a function. Run the check a second time after decoding/filtering. This second check is strictly speaking redundant (which is why it wasn't done until now), but it avoids a useless playloop iteration.
* video: filter new frames at a better timewm42014-09-181-24/+24
| | | | | | | Move this code below the code that "shifts" the newly filtered frame. This allows us to skip a useless playloop iteration later, because obviously we need to filter a new frame after the previous frame has been "shifted", and not before that.
* player: allow overriding OSD message for all OSD levelswm42014-09-181-17/+26
| | | | | | | | | | | | | | | | | | Until now, you could override only level 3 with --osd-status-msg. Extend this, add add --osd-msg1 to --osd-msg3 (one for each OSD level). OSD level 0 always means disable OSD, so that isn't included. --osd-msg3 corresponds to --osd-status-msg, but they're not exactly the same. To allow more customization, --osd-msgN do not include the OSD symbol. The symbol can be manually added with "${osd-sym-cc}". We keep the "old" option for some short-term compatibility. --osd-msg1 should be particularly useful; for example you could do: --osd-msg1='${?pause==yes:${osd-sym-cc}}' to display a "paused" symbol when paused, and nothing during normal playback. (Although admittedly, the syntax is quite a bit of work.)
* command: allow using ASS tags on OSD messageswm42014-09-181-0/+12
| | | | | | | | | | | We don't allow this by default, because it would be silly if random external data (like filenames or file tags) could accidentally trigger them. Add a property that magically disables this ASS tag escaping. Note that malicious input could still disable ASS tag escaping by itself. This would be annoying but harmless.
* command: add osd-sym-cc propertywm42014-09-183-11/+22
| | | | This allows you to reproduce the OSD symbol.
* player: don't let multiline filenames set options on resumewm42014-09-161-4/+7
| | | | | | | | | | | | | | | | | If --write-filename-in-watch-later-config is used, and the filename contains newline characters (as generally allowed on Unix), then the newline will be written to the resume file literally, and the parts after the newline character are interpreted as options. This is possibly security relevant. Change newline characters (and in fact any other special characters) to '_'. Reported as #1099 (this commit is a reimplementation of the proposed pull request). CC: @mpv-player/stable
* options.lua: call msg.debug after resolving 'identifier'Otto Modinos2014-09-161-2/+1
|
* command: avoid a double -> int castBen Boeckel2014-09-161-1/+1
| | | | | | | | Just check against zero directly. Changes behavior, but that should be ok. Signed-off-by: wm4 <wm4@nowhere>
* sanitizer: avoid divide-by-zero instancesBen Boeckel2014-09-141-5/+5
| | | | | | | | Merges pull request #1094, with some minor changes. mpv expects IEEE, and IEEE allows divisions by 0 for floats, so these shouldn't actually be a problem, but do it anyway for the sake of clang. Signed-off-by: wm4 <wm4@nowhere>
* player: shorten skip heuristic for playlist_prev to 1 secondwm42014-09-141-2/+2
| | | | See issue #1084.
* client API: use playback abort mechanismwm42014-09-131-0/+5
| | | | | | If you send the "quit" or "stop" command with the client API, it will now attempt to kill network I/O immediately (same as normal input in the previous commits).
* stream: redo playback abort handlingwm42014-09-133-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This mechanism originates from MPlayer's way of dealing with blocking network, but it's still useful. On opening and closing, mpv waits for network synchronously, and also some obscure commands and use-cases can lead to such blocking. In these situations, the stream is asynchronously forced to stop by "interrupting" it. The old design interrupting I/O was a bit broken: polling with a callback, instead of actively interrupting it. Change the direction of this. There is no callback anymore, and the player calls mp_cancel_trigger() to force the stream to return. libavformat (via stream_lavf.c) has the old broken design, and fixing it would require fixing libavformat, which won't happen so quickly. So we have to keep that part. But everything above the stream layer is prepared for a better design, and more sophisticated methods than mp_cancel_test() could be easily introduced. There's still one problem: commands are still run in the central playback loop, which we assume can block on I/O in the worst case. That's not a problem yet, because we simply mark some commands as being able to stop playback of the current file ("quit" etc.), so input.c could abort playback as soon as such a command is queued. But there are also commands abort playback only conditionally, and the logic for that is in the playback core and thus "unreachable". For example, "playlist_next" aborts playback only if there's a next file. We don't want it to always abort playback. As a quite ugly hack, abort playback only if at least 2 abort commands are queued - this pretty much happens only if the core is frozen and doesn't react to input.
* player: fix idle mode event handlingwm42014-09-131-8/+9
| | | | | | | | | | | Idle mode went to sleep too early, e.g. just pressing "ESC" did nothing, until the next event happened. This was because it directly went to sleep after processing commands. What we should do instead is rechecking all state after processing commands, redraw OSD, and then go to sleep. This also fixes some strange OSD-related behavior. Also move some other code around to separate idle mode initialization from the normal run loop.
* input: remove central select() callwm42014-09-101-1/+0
| | | | | This is now unused. Get rid of it and all surrounding infrastructure, and replace the remaining "wakeup pipe" with a semaphore.
* terminal-unix: move to threadwm42014-09-101-5/+0
| | | | | | | Do terminal input with a thread, instead of using the central select() loop. This also changes some details how SIGTERM is handled. Part of my crusade against mp_input_add_fd().
* player: reset some VO state when video is terminatedwm42014-09-091-0/+3
| | | | | Useful for idle mode or if video is switched off during playback, and --force-window is used.
* player: deal with some corner cases with playlist navigationwm42014-09-092-18/+23
| | | | | | | | | | | | | | | The purpose is making accessing the current playlist entry saner when commands are executed during initialization, termination, or after playlist navigation commands. For example, the "playlist_remove current" command will invalidate playlist->current - but some things still access the playlist entry even on uninit. Until now, checking stop_play implicitly took care of it, so it worked, but it was still messy. Introduce the mpctx->playing field, which points to the current playlist entry, even if the entry was removed and/or the playlist's current entry was moved (e.g. due to playlist navigation).
* player: normalize playlist entries on addwm42014-09-091-4/+0
| | | | This is not necessarily more correct, but it's less trouble.
* player: some more input refactoringwm42014-09-074-56/+18
| | | | | | | | | | | | | | | | | Continues commit 348dfd93. Replace other places where input was manually fetched with common code. demux_was_interrupted() was a weird function; I'm not entirely sure about its original purpose, but now we can just replace it with simpler code as well. One difference is that we always look at the command queue, rather than just when cache initialization failed. Also, instead of discarding all but quit/playlist commands (aka abort command), run all commands. This could possibly lead to unwanted side-effects, like just ignoring commands that have no effect (consider pressing 'f' for fullscreen right on start: since the window is not created yet, it would get discarded). But playlist navigation still works as intended, and some if not all these problems already existed before that in some forms, so it should be ok.
* lua: synchronously wait until scripts are loadedwm42014-09-063-5/+40
| | | | | | | | | | | | | | | | | This makes the player wait until each script is loaded. Do this to give the script a chance to setup all its event handlers. It might also be useful to allow a script to change options that matter for playback. While waiting for a script to be loaded, the player actually accepts input. This is needed because the scripts can execute player commands anyway while they are being "loaded". The player won't react to most commands though: it can't quit or navigate the playlist in this state. For deciding whether a script is finally loaded, we use a cheap hack: if mpv_wait_event() is called, it's considered loaded. Let's hope this is good enough. I think it's better than introducing explicit API for this. Although I'm sure this will turn out as too simplistic some time in the future, the same would probably happen with a more explicit API.
* player: minor refactoringwm42014-09-062-22/+31
| | | | | | | Expose the central event handling functions explicitly, so that other parts of the player can use them. No functional changes. Preparation for the next commit.
* audio: fix initial sync with huge AO bufferwm42014-09-061-1/+1
| | | | | | | | | | | | | | With e.g --start=-3 --audio-buffer=10 the decoder entered EOF state before the initial sync was finished, entered STATUS_EOF, and just started playing audio from a random position. This doesn't handle seeking outside of the file, which is a different case. E.g. --start=30:00 with audio and video enabled in a file shorter than 30:00 will play a random last part of audio. This could perhaps be fixed by using the hr-seek target for cutting audio, instead of the video PTS, but that would be kind of intrusive, so don't do it for now. The simpler solution, assuming audio EOF on video EOF, wouldn't work, because we allow audio to start before video, or to last after video.
* sub: fix possible deadlock with --no-sub-ass and similarwm42014-09-061-6/+1
| | | | | | | | | | | | | | | This is a deadlock caused by a lock order issue: sub/osd.c locks the OSD first, then the subtitle decoder lock. player/sub.c does the reverse. Fix this by discussing away the requirement for locking (see below), which allows us to drop the broken sub lock. sub_get_text() still acquires and releases the sub decoder lock, but it's not held at the same time as the OSD lock anymore, so it should be fine. Originally, the sub lock was acquired because sub_get_text() returns a pointer to a mutable string. We simply declare that it's ok to call it unlocked, as long as only 1 thread accesses it, which works out fine in this case.
* audio: correctly initialize output bufferwm42014-09-051-0/+6
| | | | | | | Just like the previous commit, this takes care of fallout from commit 7ab228, which fixed a bug, but introduced some new ones. CC: @mpv-player/stable
* player: check for null in resume config searchJames Ross-Gowan2014-09-051-1/+2
| | | | | | Signed-off-by: wm4 <wm4@nowhere> CC: @mpv-player/stable
* audio: fix random crashes on uninitwm42014-09-051-2/+1
| | | | I added this non-sense earlier this day. Oops.
* audio: fix obscure audio resync failure with timelineswm42014-09-052-3/+6
| | | | | | | | | | | | | | | | | Somehow, there was a larger misunderstanding in the code: ao_buffer does not need to be preserved over audio reinit for proper support of gapless audio. The actual AO internal buffer takes care of this. In fact, preserving ao_buffer just breaks audio resync. In the ordered chapter case, end_pts is used, which means not all audio data in the buffer is played, thus some data is left over when audio decoding resumes on the next segment. This triggers some code that aborts resync if there's "audio decoded" (ao_buffer contains something), but no PTS is known (nothing was actually decoded yet). Simplify, and always bind the output buffer to the decoder. CC: @mpv-player/stable (maybe)
* cosmetics: remove a stray ';'wm42014-09-051-1/+1
|
* video: rename VOCTRL_GET_WINDOW_SIZEwm42014-09-051-2/+4
| | | | Make it clear that this accesses the un-fullscreened window size.
* player: add --media-title optionwm42014-09-021-0/+4
| | | | Requested by ChrisK2.
* player: properly resume playlists loaded at runtimewm42014-09-021-0/+3
| | | | | | | If a playlist is loaded from the internal playlist (like "mpv playlist.m3u"), then attempt to resume from it. CC: @mpv-player/stable
* player: add --osd-playing-msg optionwm42014-09-021-5/+13
|
* player: simplistic HLS bitrate selectionwm42014-09-011-4/+11
| | | | | | --hls-bitrate=min/max lets you select the min or max bitrate. That's it. Something more sophisticated might be possible, but is probably not even worth the effort.
* command: remove broken quvi-format propertywm42014-09-011-74/+0
| | | | Never really worked, and libquvi is probably a lost cause anyway.
* demux: get rid of old wrapperwm42014-09-011-1/+1
| | | | | demux_info_get() used to be central, but was turned into a wrapper, and now there was only one caller left. Get rid of it.
* command: disable some commands/properties properly in idle modewm42014-09-011-2/+21
| | | | | In particular, don't allow to add any external subtitle tracks in idle mode. This make no sense and would just lead to leaks or worse.
* player: reset playback-related fields right on startwm42014-09-011-23/+17
|
* player: don't allow remote playlists to load local fileswm42014-09-011-3/+6
| | | | | | | | Because that might be a bad idea. Note that remote playlists still can use any protocol marked with is_safe and is_network, because the case of http-hosted playlists containing URLs using other streaming protocols is not unusual.
*