summaryrefslogtreecommitdiffstats
path: root/player
Commit message (Collapse)AuthorAgeFilesLines
* video: actually flush filter chainwm42014-07-301-1/+4
| | | | | | | Frames buffered in filters weren't flushed, so on EOF, the last frames were dropped, depending on how much filters buffered. Oops. Test case: "mpv something.jpg --vf=buffer"
* audio: better sync behavior on bogus EOFwm42014-07-301-1/+3
| | | | | | | In situations when the demuxer reports EOF, but immediately "recovers" after that and returns new data, it could happen that audio sync was skipped. Deal with this by actually entering the EOF state, instead of assuming this will happen later.
* audio: better initial sync for files where audio starts laterwm42014-07-301-5/+15
| | | | | | | Some files have the first audio much later into the video (for whatever reasons). Instead of appending large amounts of silence to the audio buffer (and refusing to sync if the audio to append is "too large"), just wait until enough video has played.
* audio: cosmetics: remove unused return valuewm42014-07-302-11/+9
|
* player: fix time display wheen seeking past EOF with --keep-openwm42014-07-304-20/+19
| | | | | | | | | | | | | | Regression since commit 261506e3. Internally speaking, playback was often not properly terminated, and the main part of handle_keep_open() was just executed once, instead of any time the user tries to seek. This means playback_pts was not set, and the "current time" was determined by the seek target PTS. So fix this aspect of video EOF handling, and also remove the now unnecessary eof_reached field. The pause check before calling pause_player() is a lazy workaround for a strange event feedback loop that happens on EOF with --keep-open.
* player: let explicitly imprecise seeks cancel precise seekswm42014-07-291-0/+3
| | | | | | | | | | | If an imprecise seek is issues while a precise seek is ongoing, don't wait up to 300ms (herustistic which usually improves user experience), but instead let it cancel the seek. Improves responsiveness of the OSC after the previous commit. Note that we don't do this on "default-precise" seeks, because we don't know if they're going to be precise or not.
* osc: Do precise seeks on simple clicks on seekbarChrisK22014-07-291-11/+19
|
* audio: ignore (some) decoding errors on initializationwm42014-07-291-1/+4
| | | | | | | | | | | | It probably happens relatively often that the first packet (or even the first N packets) of a stream will fail to decode, but decoding will eventually succeed at a later point. Before commit 261506e3, this was handled by an explicit retry loop (although this was also for other purposes), but with then was changed to abort on the first error. This makes it impossible to decode some audio streams. Change this so that errors are ignored for the first 50 packets, which should make it equivalent to the old code.
* player: fix desync when seeking and switching external trackswm42014-07-296-32/+30
| | | | | | | | | | | | If you for example use --audio-file, disable the external track, seek, and enable the external track again, the playback position of the external file was off, and you would get major A/V desync. This was actually supposed to work, but broke at some time ago (probably commit 2b87415f). It didn't work, because it attempted to seek the stream if it was already selected, which was always true due to reselect_demux_streams() being called before that. Fix by putting the initial selection and the seek together.
* player: remove a pointless fieldwm42014-07-292-5/+4
|
* player: disable hr-seek in .ts fileswm42014-07-291-0/+1
| | | | | | | | Seeking in .ts files (and some other formats) is too unreliable, so there's a separate code path for this case. But it breaks hr-seek. Maybe hr-seek could actually be enabled in this case if we're careful enough about timestamp resets, but for now nothing changes.
* player: allow precise seeking with percent seekswm42014-07-291-2/+1
| | | | I'm not sure why this was explicitly disabled. It's from mplayer2 times.
* player: update playback position on seekwm42014-07-291-0/+2
| | | | | | | If the actual PTS is not known yet right after a seek, the "time-pos" property will just return the seek target PTS. For this purpose, trigger a change event to make the client API update the "time-pos" and related properties. (MPV_EVENT_TICK triggers this update.)
* player: logically speed up seek logicwm42014-07-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | Commit 261506e3 made constant seeking feel slower, because a subtle change in the restart logic makes it now waste time showing another video frame. The slowdown is about 20%. (Background: the seek logic explicitly waits until a video frame is displayed, because this makes it easier for the user to search for something in the video. Without this logic, the display would freeze until the user stops giving seek commands.) Fix this by letting the seek logic issue another seek as soon as the first video frame is displayed. This will prevent it from showing a (useless, slow) second frame. Now it seems to be as fast as before the change. One side-effect is that the next seek happens after the first video frame, but _before_ audio is restarted. Seeking is now silent. I guess this is ok, so we don't do anything about it. Actually, I think whether this happens is probably random; the seeking logic simply doesn't make this explicit, so anything can happen.
* audio: change playback restart and resyncingwm42014-07-285-250/+288
| | | | | | | | | | | | | | | | | | | | | This commit makes audio decoding non-blocking. If e.g. the network is too slow the playloop will just go to sleep, instead of blocking until enough data is available. For video, this was already done with commit 7083f88c. For audio, it's unfortunately much more complicated, because the audio decoder was used in a blocking manner. Large changes are required to get around this. The whole playback restart mechanism must be turned into a statemachine, especially since it has close interactions with video restart. Lots of video code is thus also changed. (For the record, I don't think switching this code to threads would make this conceptually easier: the code would still have to deal with external input while blocked, so these in-between states do get visible [and thus need to be handled] anyway. On the other hand, it certainly should be possible to modularize this code a bit better.) This will probably cause a bunch of regressions.
* audio, client API: check mp_make_wakeup_pipe() return valuewm42014-07-251-3/+4
| | | | Could fail e.g. due to FD exhaustion.
* command: fix and simplify overlay_addwm42014-07-251-50/+44
| | | | | | | | | | | | | | | | Actually free the old mmap region when readding an overlay of the same ID without removing it before. (This is explicitly documented as working.) Replace the OSD atomically. Before this commit, the overlays were removed and then readded to avoid synchronization problems. Simplify the code: now there is no weird mapping between index and ID. The OSD sub-bitmap list still needs to be prepared to skip unused IDs (since each sub-bitmap list entry must be in use), but the code for this is relatively separated now. Fixes issue #956.
* command: append entries to the end of the playlist with loadlist appendAlessandro Ghedini2014-07-251-1/+1
| | | | | | Currently entries are added after the current playlist element. This is kinda confusing, more so given that "loadfile append" appends at the end of the playlist.
* audio: cosmetics: collapse a functionwm42014-07-241-14/+6
| | | | | There's no need for build_afilter_chain() to be a separate function anymore.
* audio: fix race condition in EOF codewm42014-07-241-1/+1
| | | | | | | | | | Don't return an EOF code if there's still buffered data. Also, don't call demux_stream_eof() in the playloop. There's probably nothing wrong with it, but it's cleaner not to use it. Also give AD_EOF its own value, so that a decoding error doesn't drain audio by causing an EOF condition.
* command: add append-play loadfile modewm42014-07-231-2/+2
| | | | | | | | "loadfile filename append-play" will now always append the file to the playlist, and if nothing is playing yet, start playback. I don't want to change the semantics of "append" mode, so a new mode is needed. Probably fixes issue #950.
* player: remove something DVD specificwm42014-07-221-8/+1
| | | | | This is not needed anymore, because demux_disc isolates us from this crap.
* sub: offset subtitle timing to video start PTSwm42014-07-221-1/+2
| | | | | | | | | | | | This allows using external subtitle files with e.g. transport stream files that don't start at time 0. Note that if the .ts file has timestamp resets, everything goes south. But I guess this was already the case before, unless there are external subtitle files that also include timestamp resets, which is unlikely. (On the other hand, you could for example expect that it works with embedded DVB subtitles, that were somehow captured from the same stream and use the same timestamps.)
* video: fix corner case with accidental EOFwm42014-07-221-5/+5
| | | | | | | | | | | | | | The video flushing logic was broken: if there are no more packets, decode_image() will feed flush packets to the decoder. Even if an image was produced, it will return the demuxer EOF state, and since commit 7083f88c, this EOF state is returned to the caller, which is incorrect. Revert this part of the change, and explicitly check for VD_WAIT (the bogus change was intended to forward this error code to the caller). Also, turn the "r < 1" into something equivalent that doesn't rely on the exact value of VD_EOF. "r < 0" is ok, because at least here, errors are always negative.
* player: fix idle mode event handlingwm42014-07-221-2/+2
|
* osd: properly handle OSD bar timeoutwm42014-07-211-4/+10
| | | | | This could just remain stuck on the screen, until the playloop happened to be run again.
* player: don't sleep after seekswm42014-07-211-0/+1
|
* audio: remove unused metadata fieldwm42014-07-211-1/+0
| | | | | This was used for replaygain at some point, until replaygain info was passed through explicitly.
* player: simplify a conditionwm42014-07-201-7/+8
| | | | | | | Move a condition somewhere else, which makes it conceptually simpler. Also, the assignment to full_audio_buffers removed with this commit was dead, and its value never used.
* player: simplify logic on video errorswm42014-07-201-1/+1
| | | | | | | | | Fatal errors in the vidoe chain (such as failing to initialize the video chain) disable video decoding. Restart the playloop, instead of just continuing the current iteration. The resulting behavior should be the same, but it gets rid of possible corner cases.
* audio: use symbolic constants instead of magic integerswm42014-07-201-4/+3
| | | | Similar to commit 26468743.
* player: readd code accidentally removed with commit 61efe87ewm42014-07-201-0/+5
| | | | Oops.
* player: fix regression with ordered chapterswm42014-07-202-14/+18
| | | | | | | | | | | | | | | | | | | Broken by commit 1301a907. This commit added demuxer threading, and changed some other things to make them simpler and more orthogonal. One of these things was ntofications about streams that appear during playback. That's an obscure corner case, but the change made handling of it as natural as normal initialization. This didn't work for two reasons: 1. When playing an ordered chapters file where the initial segment was not from the main file, its streams were added to the track list. So they were printed twice, and switching to the next segment didn't work, because the right streams were not selected. 2. EDL, CUE, as well as possibly certain Matroska files don't have any data or tracks in the "main" demuxer, so normally the first segment is picked for the track list. This was simply broken. Fix by sprinkling the code with various hacks.
* command: potentially fix dvd angle settingwm42014-07-201-5/+4
| | | | | | | | This called demux_flush(), but that doesn't make any sense with an asynchronously running demuxer. It would just keep reading and add new packets again. Explicitly pause the demuxer, so that this can't happen. Also, when flushing, data will be missing, so the decoders should always be reinitialized, even if the operation fails.
* player: don't wait forever with --cache-pause-below behaviorwm42014-07-201-0/+1
| | | | | | | Commit dc00b146, which disables polling by default, missed another instance of polling: when the player pauses automatically on low cache. This could lead to apparent freezes when playing network streams.
* video: use symbolic constants instead of magic integerswm42014-07-183-38/+43
| | | | | | | | | In my opinion this is not really necessary, since there's only a single user of update_video(), but others reading this code would probably hate me for using magic integer values instead of symbolic constants. This should be a purely cosmetic commit; any changes in behavior are bugs.
* video: don't block when reading video packetswm42014-07-183-13/+35
| | | | | | | | | | | | Instead of blocking on the demuxer when reading a packet, let packets be read asynchronously. Basically, it polls whether a packet is available, and if not, the playloop goes to sleep until the demuxer thread wakes it up. Note that the player will still block for I/O, because audio is still read synchronously. It's much harder to do the same change for audio (because of the design of the audio decoding path and especially initialization), so audio will have to be done later.
* player: remove the last instances of pollingwm42014-07-183-38/+39
| | | | | | | | | | | | | | | | | Mouse cursor handling, --heartbeat-cmd, and OSD messages basically relied on polling. For this reason, the playloop always used a small timeout (not more than 500ms). Fix these cases, and raise the timeout to 100 seconds. There is no reason behind this number; for this specific purpose it's as close to infinity as any other number. On MS Windows, or if vo_sdl is used, the timeout remains very small. In these cases the GUI code doesn't do proper event handling in the first place, and fixing it requires much more effort. getch2_poll() still does polling, because as far as I'm aware no event- based way to detect this state change exists.
* demux: add a demuxer threadwm42014-07-166-102/+120
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds a thread to the demuxer which reads packets asynchronously. It will do so until a configurable minimum packet queue size is reached. (See options.rst additions.) For now, the thread is disabled by default. There are some corner cases that have to be fixed, such as fixing cache behavior with webradios. Note that most interaction with the demuxer is still blocking, so if e.g. network dies, the player will still freeze. But this change will make it possible to remove most causes for freezing. Most of the new code in demux.c actually consists of weird caches to compensate for thread-safety issues (with the previously single-threaded design), or to avoid blocking by having to wait on the demuxer thread. Most of the changes in the player are due to the fact that we must not access the source stream directly. the demuxer thread already accesses it, and the stream stuff is not thread-safe. For timeline stuff (like ordered chapters), we enable the thread for the current segment only. We also clear its packet queue on seek, so that the remaining (unconsumed) readahead buffer doesn't waste memory. Keep in mind that insane subtitles (such as ASS typesetting muxed into mkv files) will practically disable the readahead, because the total queue size is considered when checking whether the minimum queue size was reached.
* ao_lavc: Fix design of audio pts handling.Rudolf Polzer2014-07-161-1/+1
| | | | | | | | | There was confusion about what should go into audio pts calculation and what not (mainly due to the audio push thread). This has been fixed by using the playing - not written - audio pts (which properly takes into account the ao's buffer), and incrementing the samples count only by the amount of samples actually taken from the buffer (unfortunately this now forces us to keep the lock too long for my taste).
* Revert "Remove DVD and Bluray support"wm42014-07-157-0/+495
| | | | | | This reverts commit 4b93210e0c244a65ef10a566abed2ad25ecaf9a1. *shrug*
* Remove DVD and Bluray supportwm42014-07-147-495/+0
| | | | It never worked well. Just remux your DVD and BD images to mkv.
* command: don't show VO information in colorspace propertieswm42014-07-131-3/+1
| | | | | | | | | | Until now, changing the properties showed the VO colorspace parameters on OSD. This didn't work quite well, because it showed the VO parameters _before_ the change. This is because at least one video frame with the new parameters has to be shown, and this doesn't happen right after changing the property, but a bit later. Also fix a random typo in unrelated code.
* Remove some mp_msg calls with no trailing \nwm42014-07-131-21/+21
| | | | | | | The final goal is all mp_msg calls produce complete lines. We want this because otherwise, race conditions could corrupt the terminal output, and it's inconvenient for the client API too. This commit works towards this goal. There's still code that has this not fixed yet, though.
* player: remove some inactive codewm42014-07-131-8/+1
| | | | | | | demux_seek() actually doesn't return seek success. Instead, it fails if the demuxer is flagged as unseekable (but this is checked explicitly at the beginning of this function), or if the seek target PTS is MP_NOPTS_VALUE (which can never happen).
* audio: drop buffered audio when switching tracks or filterswm42014-07-132-0/+2
| | | | | | | | No reason to wait until the audio has been played. This isn't a problem with gapless audio disabled, and since gapless is now default, this behavior might be perceived as regression. CC: @mpv-player/stable
* osc: improve previous commitChrisK22014-07-101-6/+3
|
* osc: round displayed cache valueChrisK22014-07-101-3/+3
| | | | Fixes #919
* build: include <strings.h> for strcasecmp()wm42014-07-103-0/+3
| | | | | | | It happens to work without strings.h on glibc or with _GNU_SOURCE, but the POSIX standard requires including <strings.h>. Hopefully fixes OSX build.
* demux: remove accurate_seek fieldwm42014-07-081-5/+3
| | | | It's unused now. (Only the dvd code used it until recently.)
* osc: fix failure when using DVD menuswm42014-07-071-1/+1
| | | | [osc] Lua error: mp.assdraw:31: attempt to concatenate local 's' (a nil value)
* lua: redo error handling, print backtraceswm42014-07-071-82/+90
| | | | | | | | | | | | | | | | | | | | The original goal was just adding backtraces, however making the code safe (especially wrt. to out of memory Lua errors) was hard. So this commit also restructures error handling to make it conceptually simpler. Now all Lua code is run inside a Lua error handling, except the calls for creating and destroying the Lua context, and calling the wrapper C function in a safe way. The new error handling is actually conceptually simpler and more correct, because you can just call any Lua function at initialization, without having to worry whwther it throws errors or not. Unfortunately, Lua 5.2 removes lua_cpcall(), so we have to emulate it. There isn't any way to emulate it in a way that works the same on 5.1 and 5.2 with the same semantics in error cases, so ifdeffery is needed. The debug.traceback() function also behaves weirdly differently between the Lua versions, so its output is not as nice as it could be (empty extra line).
* Remove stream_pts stuffwm42014-07-062-19/+0
| | | | | This was used by DVD/BD, but its usage was removed with one of the previous commits.
* demux: minor simplificationwm42014-07-061-1/+1
| | | | Oops, should have been part of commit 37085788.
* player: don't use stream position as fallback for percent-poswm42014-07-051-3/+2
| | | | | | | | This should be unneeded, and the packet position is already sufficient for this case. Accessing the stream position directly is going to be a problem when the stream is accessed from another thread later.
* dvd: move angle switching codewm42014-07-051-14/+28
| | | | | No need to provide a "nice" API for it; just do this stuff directly in the command code.
* dvd, bluray, cdda: add demux_disc containing all related hackswm42014-07-053-114/+0
| | | | | | | | | | | | DVD and Bluray (and to some extent cdda) require awful hacks all over the codebase to make them work. The main reason is that they act like container, but are entirely implemented on the stream layer. The raw mpeg data resulting from these streams must be "extended" with the container-like metadata transported via STREAM_CTRLs. The result were hacks all over demux.c and some higher-level parts. Add a "disc" pseudo-demuxer, and move all these hacks and special-cases to it.
* discnav: fix a commentwm42014-07-051-1/+1
|
* demux: make start time a simple fieldwm42014-07-052-3/+3
| | | | Simpler, especially for later changes.
* demux: make replaygain per-trackwm42014-07-051-1/+1
| | | | | | It's unlikely that files with multiple audio tracks and with replaygain actually hap