summaryrefslogtreecommitdiffstats
path: root/player/playloop.c
Commit message (Collapse)AuthorAgeFilesLines
* 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.
* player: remove audio waitingwm42014-04-151-16/+0
| | | | | | | | The audio subsystem now wakes up the playback thread explicitly, and we don't need this anymore. It still could cause dropouts and such if there are bugs in the recently introduced audio changes, so this is a thing to watch out for.
* client API: remove mpv_event_pause_reasonwm42014-04-141-14/+10
| | | | | | | | | And slightly adjust the semantics of MPV_EVENT_PAUSE/MPV_EVENT_UNPAUSE. The real pause state can now be queried with the "core-idle" property, the user pause state with the "pause" property, whether the player is paused due to cache with "paused-for-cache", and the keep open event can be guessed with the "eof-reached" property.
* command: add property to indicate when pausing due to --keep-openwm42014-04-141-0/+3
| | | | | | | This property is set to "yes" if playback was paused due to --keep-open. The change notification might not always be perfect; maybe that should be improved.
* player: add missing "-" to options in workaround notice on A/V desynchronizationSebastian Morr2014-03-301-1/+1
| | | | | | While it technically works, using GNU-style options seems cleaner nowadays. Signed-off-by: wm4 <wm4@nowhere>
* player: use MP_NOPTS_VALUE as rel_time_to_abs() error valuewm42014-03-251-2/+1
| | | | | | And consistently use MP_NOPTS_VALUE as error value for the users of this function. This is better than using -1, especially because negative values can be valid timestamps.
* player: handle chapter range like --start/--endwm42014-03-251-3/+3
| | | | | | | | | | | Instead of comparing the current chapter every time, set the playback end timestamp to the chapter end. Likewise, don't execute an extra seek for the start chapter. Maybe we could also use the timeline facility to restrict playback to the given chapter range, but this would be strange when using --chapter=N to start playback at a given chapter. Then you couldn't seek back, which is possibly not what the user wants.
* player: let chapter_start_time() return MP_NOPTS_VALUE for unknown timeswm42014-03-251-2/+2
|
* player: remove weird separation between no chapters and 0 chapterswm42014-03-251-15/+11
| | | | | | For some reason, it mattered whether mpctx->chapters was NULL or not, even if mpctx->num_chapters was 0. Remove this separation; it serves no purpose.
* player: remove demuxer chapoter API wrapperswm42014-03-251-30/+6
| | | | | | Instead, always use the mpctx->chapters array. Before this commit, this array was used only for ordered chapters and such, but now it's always populated if there are chapters.
* stream: remove old chapter handling codewm42014-03-251-8/+1
| | | | | | | | Stream-level chapters (like DVD etc.) did potentially not have timestamps for each chapter, so STREAM_CTRL_SEEK_TO_CHAPTER and STREAM_CTRL_GET_CURRENT_CHAPTER were needed to navigate chapters. We've switched everything to use timestamps and that seems to work, so we can simplify the code and remove this old mechanism.
* Revert "player: simplify audio reset when seeking"wm42014-03-101-10/+15
| | | | | | | | | | | This reverts commit 75dd3ec2106701cb865f52966de66c51cb6f9204. This broke seeking with ordered chapters in some situations. While the reverted commit was perfectly fine for playback of normal files, it overlooked that in the ordered chapters case switching segments actually reinitialized the audio chain completely, including the decoder. And decoders still read packets on initialization. We can restore the original commit as soon as decoders stop doing this.
* audio/out: make ao struct opaquewm42014-03-091-5/+6
| | | | | | We want to move the AO to its own thread. There's no technical reason for making the ao struct opaque to do this. But it helps us sleep at night, because we can control access to shared state better.
* player: cheap hack against idle event feedback loopwm42014-03-011-2/+6
| | | | | | | | | | | The OSC used significant CPU time while the player was paused. It turned out that the "tick" event sent during pause is the problem. The OSC accesses the player core when receiving a tick event, which in turn will cause the core to send another tick event, leading to infinite feedback. Fix this by sending an idle tick only every 500ms. This is not very proper, but the idea behind the tick event isn't very clean to begin with (and the OSC should use timers instead).
* client APIs: fix some typosxylosper2014-02-281-1/+1
|
* client API: rename MPV_EVENT_PLAYBACK_START, add MPV_EVENT_SEEKwm42014-02-281-0/+5
| | | | | | Rename MPV_EVENT_PLAYBACK_START to MPV_EVENT_FILE_LOADED. Add MPV_EVENT_SEEK and MPV_EVENT_PLAYBACK_RESTART.
* client API: don't send MPV_EVENT_IDLE when not entering idle modewm42014-02-261-2/+3
| | | | | | For simplicity, this was sent before actually checking the idle condition, which meant that we'd send it even of the idle loop is never entered.
* client API: report pause/unpause reasonwm42014-02-241-15/+21
| | | | | | | | | Not sure about this... might redo. At least this provides a case of a broadcasted event, which requires per-event data allocation. See github issue #576.
* options: handle escape sequences in e.g. --playing-msg differentlywm42014-02-201-1/+2
| | | | | | | | | | M_OPT_PARSE_ESCAPES was pretty stupid, and broke the (useful) assumption that string variables contain exactly the same value as set by the option. Simplify it, and move escape handling to the place where it's used. Escape handling itself is not terribly useful, but still allows useful things like multiline custom OSD with "\n".
* client API: add event for metadata changeswm42014-02-191-1/+2
|
* client API: add events for video and audio reconfigwm42014-02-171-1/+1
|
* lua: port to client APIwm42014-02-101-3/+0