summaryrefslogtreecommitdiffstats
path: root/player
Commit message (Collapse)AuthorAgeFilesLines
* build: add -Wno-format-zero-lengthwm42014-09-262-2/+2
| | | | | | This warning makes absolutely no sense. Passing an empty string to printf-like functions is perfectly fine. In the OSD case, it just sets an empty message, practically clearing the OSD.
* player: do not wrongly clear OSD bar stops, reindentwm42014-09-251-30/+30
| | | | | | | | | | set_osd_bar_chapters() always cleared the OSD bar stops, even if the current bar was not the seek bar. Obviously it should leave the state of the bar alone in this case. Also change the function control flow so that we can drop one indentation level, and do the equivalent change for the other OSD bar functions.
* player: simplify OSD message handling codewm42014-09-252-103/+60
| | | | | | | | | | | Eliminate the remains of the OSD message stack. Another simplification comes from the fact that we do not need to care about time going backwards (we always use a monotonic time source, and wrapping time values are practically impossible). What this code was pretty trivial, and by now unnecessarily roundabout. Merge get_osd_msg() into update_osd_msg(), and add_osd_msg() into set_osd_msg_va().
* player: move code to make playloop smallerwm42014-09-252-9/+9
| | | | | This is basically a cosmetic change, although it weirdly also affects the percent position in encoding mode.
* player: rate-limit OSD text updatewm42014-09-254-10/+18
| | | | | | | | | | | | | | | There's no need to update OSD messages and the terminal status if nobody is going to see it. Since the player doesn't block on video display anymore, this update happens to often and probably burns slightly more CPU than necessary. (OSD redrawing is handled separately, so it's just mostly useless text processing and such.) Change it so that it's updated only on every video frame or all 50ms (whatever comes first). For VO OSD, we could in theory try to lock to the OSD redraw heuristic or the display refresh rate, but that's more complicated and doesn't work for the terminal status.
* player: fix OSD redraw heuristic with audio-only modewm42014-09-251-1/+1
| | | | | | When using --force-window (and no video or cover art), this heuristic prevents any redrawing during seeking. It should be applied only if there is any form of video.
* sub: approximate subtitle display in no-video modewm42014-09-251-0/+3
| | | | | | | | | | | | | | | | | | | | | | This makes subtitle display somewhat work if no video is displayed, but a VO window exists (--force-window or cover art display). The main problem with normal subtitle display is that it's locked to video: it uses the video PTS as reference, and the subtitles advance only if a new video frame is displayed. In audio-only mode on the other hand, no video frame is ever displayed (or only 1 in the cover art case). You would need a workaround to adjust the subtitle PTS, and you would have to decide with what frequency to update the display. In general, there is no "right" display FPS for subtitles. Some formats (ASS) have animations parameterized by time, and any refresh rate could be used. Sidestep these problems by enabling the text OSD-based subtitle mechanism. This is similar to --no-sub-ass, and updates and renders subtitles with plain OSD. It has some caveats: no bitmap subs, somewhat incorrect timing, no formatting. Timing in particular is a bit strange and depends how often the audio output asks for new data, or other events that happen to wakeup the playloop.
* osc: update cache displayChrisK22014-09-251-3/+14
| | | | now similar to what the status line displays
* player: change --keep-open semanticswm42014-09-241-1/+3
| | | | By popular request.
* player: show correct playback time with --keep-open --no-videowm42014-09-241-1/+2
| | | | Whatever.
* player: --loop-file takes precedence before --keep-openwm42014-09-241-2/+2
|
* audio: cleanup spdif format definitionswm42014-09-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this commit, there was AF_FORMAT_AC3 (the original spdif format, used for AC3 and DTS core), and AF_FORMAT_IEC61937 (used for AC3, DTS and DTS-HD), which was handled as some sort of superset for AF_FORMAT_AC3. There also was AF_FORMAT_MPEG2, which used IEC61937-framing, but still was handled as something "separate". Technically, all of them are pretty similar, but may use different bitrates. Since digital passthrough pretends to be PCM (just with special headers that wrap digital packets), this is easily detectable by the higher samplerate or higher number of channels, so I don't know why you'd need a separate "class" of sample formats (AF_FORMAT_AC3 vs. AF_FORMAT_IEC61937) to distinguish them. Actually, this whole thing is just a mess. Simplify this by handling all these formats the same way. AF_FORMAT_IS_IEC61937() now returns 1 for all spdif formats (even MP3). All AOs just accept all spdif formats now - whether that works or not is not really clear (seems inconsistent due to earlier attempts to make DTS-HD work). But on the other hand, enabling spdif requires manual user interaction, so it doesn't matter much if initialization fails in slightly less graceful ways if it can't work at all. At a later point, we will support passthrough with ao_pulse. It seems the PulseAudio API wants to know the codec type (or maybe not - feeding it DTS while telling it it's AC3 works), add separate formats for each codecs. While this reminds of the earlier chaos, it's stricter, and most code just uses AF_FORMAT_IS_IEC61937(). Also, modify AF_FORMAT_TYPE_MASK (renamed from AF_FORMAT_POINT_MASK) to include special formats, so that it always describes the fundamental sample format type. This also ensures valid AF formats are never 0 (this was probably broken in one of the earlier commits from today).
* 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
| |