summaryrefslogtreecommitdiffstats
path: root/player/playloop.c
Commit message (Collapse)AuthorAgeFilesLines
* player: don't delay OSD redraw when pausedwm42014-08-101-2/+4
| | | | We want this heuristic to trigger during normal playback only.
* player: some further playloop cleanupswm42014-08-031-45/+33
| | | | | | | | | | | | | Handle --term-playing-msg at a better place. Move MPV_EVENT_TICK hack into a separate function. Also add some words to the client API that you shouldn't use it. (But better leave breaking it for later.) Handle --frames and frame_step differently. Remove the mess from the playloop, and do it after frame display. Give up on the weird semantics for audio-only mode (they didn't make sense anyway), and adjust the manpage accordingly.
* player: make quit exit immediatelywm42014-08-031-3/+3
| | | | | Stopping playback canceled waiting, but executed the remainder of the playloop, including things like executing pointless seeks.
* player: allow redrawing screen during seekswm42014-08-031-6/+12
| | | | | | | | If seeks take very long, it's better not to freeze up the display. (This doesn't handle the case when decoding video frames is extremely slow; just if hr-seek is used, or the demuxer is threaded and blocks on network I/O.)
* player: don't ignore first chapterwm42014-07-311-1/+1
| | | | | It's a mystery why this was done this way. If the first chapter starts later than the current position, we do have to return -1.
* client API: make "cache" property and similar observablewm42014-07-311-0/+12
| | | | | | Achieve this by polling. Will be used by the OSC. Basically a bad hack - but the point is that the mpv core itself is in the best position to improve this later.
* player: rename a variablewm42014-07-301-3/+3
| | | | | Make it clear that this condition happens when switching to a new timeline segment. It doesn't even need to coincide with a chapter.
* player: move video display code out of the playloopwm42014-07-301-316/+9
| | | | | | | | | | Basically move the code from playloop.c to video.c. The new function write_video() now contains the code that was part of run_playloop(). There are no functional changes, except handling "new_frame_shown" slightly differently. This is done so that we don't need new a new MPContext field or a return value for write_video() to signal this condition. Instead, it's handled indirectly.
* player: split seek_reset()wm42014-07-301-30/+12
| | | | | | | | This also reduces some code duplication with other parts of the code. The changfe is mostly cosmetic, although there are also some subtle changes in behavior. At least one change is that the big desync message is now printed after every seek.
* player: fix time display wheen seeking past EOF with --keep-openwm42014-07-301-17/+16
| | | | | | | | | | | | | | 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.
* player: remove a pointless fieldwm42014-07-291-3/+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-281-100/+91
| | | | | | | | | | | | | | | | | | | | | 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.
* player: fix idle mode event handlingwm42014-07-221-2/+2
|
* player: don't sleep after seekswm42014-07-211-0/+1
|
* 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.
* 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-181-7/+7
| | | | | | | | | 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-181-3/+6
| | | | | | | | | | | | 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-181-30/+27
| | | | | | | | | | | | | | | | | 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-161-19/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Revert "Remove DVD and Bluray support"wm42014-07-151-0/+2
| | | | | | This reverts commit 4b93210e0c244a65ef10a566abed2ad25ecaf9a1. *shrug*
* Remove DVD and Bluray supportwm42014-07-141-2/+0
| | | | It never worked well. Just remux your DVD and BD images to mkv.
* 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).
* demux: remove accurate_seek fieldwm42014-07-081-5/+3
| | | | It's unused now. (Only the dvd code used it until recently.)
* Remove stream_pts stuffwm42014-07-061-2/+0
| | | | | This was used by DVD/BD, but its usage was removed with one of the previous commits.
* 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.
* player: make the time display relative to start PTSTsukasa OMOTO2014-06-291-0/+7
| | | | | | This commit makes the playback start time always at time 0. Signed-off-by: wm4 <wm4@nowhere>
* video/out: change aspects of OSD handlingwm42014-06-151-32/+9
| | | | | | | | | Let the VOs draw the OSD on their own, instead of making OSD drawing a separate VO driver call. Further, let it be the VOs responsibility to request subtitles with the correct PTS. We also basically allow the VO to request OSD/subtitles at any time. OSX changes untested.
* player: hide some messages in verbose modewm42014-06-091-3/+3
| | | | This started getting annoying.
* stream: don't use end_poswm42014-05-241-4/+5
| | | | | | | | | | | | | | | | | | | Stop using it in most places, and prefer STREAM_CTRL_GET_SIZE. The advantage is that always the correct size will be used. There can be no doubt anymore whether the end_pos value is outdated (as it happens often with files that are being downloaded). Some streams still use end_pos. They don't change size, and it's easier to emulate STREAM_CTRL_GET_SIZE using end_pos, instead of adding a STREAM_CTRL_GET_SIZE implementation to these streams. Make sure int64_t is always used for STREAM_CTRL_GET_SIZE (it was uint64_t before). Remove the seek flags mess, and replace them with a seekable flag. Every stream must set it consistently now, and an assertion in stream.c checks this. Don't distinguish between streams that can only be forward or backwards seeked, since we have no such stream types.
* stream: kill start_pos, remove --sb optionwm42014-05-241-2/+2
| | | | | | | | | | | | | | | | | | | | stream.start_pos was needed for optical media only, and (apparently) not for very good reasons. Just get rid of it. For stream_dvd, we don't need to do anything. Byte seeking was already removed from it earlier. For stream_cdda and stream_vcd, emulate the start_pos by offsetting the stream pos as seen by the rest of mpv. The bits in discnav.c and loadfile.c were for dealing with the code seeking back to the start in demux.c. Handle this differently by assuming the demuxer is always initialized with the stream at start position, and instead seek back if initializing the demuxer fails. Remove the --sb option, which worked by modifying stream.start_pos. If someone really wants this option, it could be added back by creating a "slice" stream (actually ffmpeg already has such a thing).
* player: fix cover art sometimes "syncing" against audiowm42014-05-221-1/+3
| | | | | | | Cover art is treated like video, but is not really video. In one case, the audio sync code was accidentally still active. Fixes cover art playback with --ao=null. (This is due to ao_null's latency emulation. Although it's not very clear whether that is actually correct...)
* cache: redo options and default settingswm42014-05-201-4/+8
| | | | | | | | | | | | Some options change from percentages to number of kilobytes; there are no cache options using percentages anymore. Raise the default values. The cache is now 25000 kilobytes, although if your connection is slow enough, the maximum is probably never reached. (Although all the memory will still be used as seekback-cache.) Remove the separate --audio-file-cache option, and use the cache default settings for it.
* player: disable hr-seek framedropping during backsteppingwm42014-05-121-2/+3
|
* player: remove VO from seeking code pathwm42014-05-071-3/+2
| | | | | | | | | | | | | | | Until recently, the VO was an unavoidable part of the seeking code path. This was because vdpau deinterlacing could double the framerate, and hr- seek and framestepping etc. all had to "see" the additional frames. But we've removed the frame doubling from the vdpau VO and moved it into a video filter (vf_vdpaupp), and there's no reason left why the VO should participate in seeking. Instead of queuing frames to the VO during seek and skipping them afterwards, drop the frames early. This actually might make seeking with vo_vdpau and software decoding faster, although I haven't measured it.
* player: minor reshuffling of video codewm42014-05-071-28/+30
|
* player: limit max. fallback frame durationwm42014-05-071-1/+1
| | | | | | It's calculated from the demuxer reported FPS, which is not very reliable. Limit the damage a completely insane and broken value could cause.
* player: handle video reconfig slightly different againwm42014-05-071-23/+26
| | | | | | | | | | Now we avoid calling update_video() twice on reconfig (once to check whether there are still new frames, and again to actually do the reconfig). Instead, we check whether there's still something going on before calling update_video() at all, and depending on that update_video() will be allowed to reconfig or not. This will simplify some things later.
* options: remove deprecated --identifyMartin Herkt2014-05-041-3/+0
| | | | | | | Also remove MSGL_SMODE and friends. Note: The indent in options.rst was added to work around a bug in ReportLab that causes the PDF manual build to fail.
* video: fix video end conditionwm42014-05-031-5/+4
| | | | | | | | | | This wasn't really fine, and could (perhaps) cause weird corner cases on reinit or when the player was paused. Before eb9d20, video_left was also set to true if vo->frame_loaded was set, and this variable basically indicated whether the previous update_video() call was successful. This was overlooked when changing everything. Simply always call update_video(), it should be equivalent.
* video: rename a variablewm42014-05-031-2/+2
| | | | Cosmetic change, reduce the diff of the following commit.
* video: change everythingwm42014-05-021-21/+23
| | | | | | | Change how the video decoding loop works. The structure should now be a bit easier to follow. The interactions on format changes are (probably) simpler. This also aligns the decoding loop with future planned changes, such as moving various things to separate threads.
* video: improve error messageswm42014-04-301-2/+1
|
* client API: add chapter change eventwm42014-04-271-0/+11
| | | | Also works for mpv_observe_property() on the "chapter" property.
* dispatch: move into its own source filewm42014-04-231-1/+1
| | | | | | | This was part of osdep/threads.c out of laziness. But it doesn't contain anything OS dependent. Note that the rest of threads.c actually isn't all that OS dependent either (just some minor ifdeffery to work around the lack of clock_gettime() on OSX).
* player: fix audio EOF check on --no-audiowm42014-04-181-1/+1
| | | | | This considered audio to never reach EOF when audio was disabled, instead of always being EOF.
* player: add a --loop-file optionwm42014-04-171-0/+11
| | | | Unlike --loop, loops a file instead of the playlist.
* player: unrangle one aspect of audio EOF handlingwm42014-04-171-9/+4
| | | | | | | | | | | | | | | | | | For some reason, the buffered_audio variable was used to "cache" the ao_get_delay() result. But I can't really see any reason why this should be done, and it just seems to complicate everything. One reason might be that the value should be checked only if the AO buffers have been recently filled (as otherwise the delay could go low and trigger an accidental EOF condition), but this didn't work anyway, since buffered_audio is set from ao_get_delay() anyway at a later point if it was unset. And in both cases, the value is used _after_ filling the audio buffers anyway. Simplify it. Also, move the audio EOF condition to a separate function. (Note that ao_eof_reached() probably could/should whether the last ao_play() call had AOPLAY_FINAL_CHUNK set to avoid accidental EOF on underflows, but for now let's keep the code equivalent.)
* audio: explicitly document audio EOF conditionwm42014-04-171-1/+1
| | | | | | This should probably be an AO function, but since the playloop still has some strange stuff (using the buffered_audio variable instead of calling ao_get_delay() directly), just leave it and make it more explicit.
* player: add a --dump-stats optionwm42014-04-171-1/+18
| | | | | | | | | | | | | | | | | | | | | | | This collects statistics and other things. The option dumps raw data into a file. A script to visualize this data is included too. Litter some of the player code with calls that generate these statistics. In general, this will be helpful to debug timing dependent issues, such as A/V sync problems. Normally, one could argue that this is the task of a real profiler, but then we'd have a hard time to include extra information like audio/video PTS differences. We could also just hardcode all statistics collection and processing in the player code, but then we'd end up with something like mplayer's status line, which was cluttered and required a centralized approach (i.e. getting the data to the status line; so it was all in mplayer.c). Some players can visualize such statistics on OSD, but that sounds even more complicated. So the approach added with this commit sounds sensible. The stats-conv.py script is rather primitive at the moment and its output is semi-ugly. It uses matplotlib, so it could probably be extended to do a lot, so it's not a dead-end.
*