summaryrefslogtreecommitdiffstats
path: root/player/playloop.c
Commit message (Collapse)AuthorAgeFilesLines
* player: remove unused return valuewm42016-06-081-6/+3
|
* player: tell user about --force-seeking if demuxer is not seekablewm42016-06-081-1/+2
| | | | | | | | | | | | | This comes up often, see e.g. #3220. The issue is that if the stream input is not seekable, the demuxer is marked as not seekable. But if the stream cache is enabled, the file still _might_ be seekable to a degree. We recently disabled seeking in this mode because it can cause very weird issues, mostly because if stream-layer seeking fails, the demuxers will arbitrarily misbehave. On the other hand, it can work if the seek is within the cached range, which is why the user can still enable it with --force-seeking. There is a weird trade-off between allowing this and not crapping up too easily, so just informing the user about the possibility seems best.
* build: silence -Wunused-resultNiklas Haas2016-06-071-1/+1
| | | | | | | | For clang, it's enough to just put (void) around usages we are intentionally ignoring the result of. Since GCC does not seem to want to respect this decision, we are forced to disable the warning globally.
* player: restore usual seeking behaviorwm42016-05-091-16/+31
| | | | | | | | | | | | | | | | | | | | | | Commit 786f37ae accidentally changed seeking behavior such that continuous seeking (holding the seek button down) would use the previous seek target timestamp, instead of the new video timestamp. (This is for the default mode, seeking to keyframes.) The result is that the movement on the seekbar is smooth, but the way the video updates is awkward. Some might actually prefer the new behavior (and some players effectively show similar bahavior), but I don't. So restore the old behavior. This is done in two steps: First: strictly wait for the entire seek process to finish, which will effectively make the seeking code pick up the new video timestamp correctly. This would play audio immediately, which would result in noise during continuous seeking, which leads to second: explicitly abort the playback restarting process if this case is detected, and never play audio.
* player: strictly wait until done when backsteppingwm42016-04-271-1/+1
| | | | | | | | | | | This fixes backstepping getting "stuck" when e.g. holding down a key bound to the backstep command. The reason is that even if the backstep itself is finished, the next backstep might not take the new video PTS as reference if the hr-seek itself isn't finished yet. The intention of not waiting for the hr-seek to finish was faster backstepping by possibly skipping audio decoding. But it probably doesn't matter enough to make the rest of the code more complex.
* player: cleaner determination of current playback PTSwm42016-04-231-8/+11
| | | | | In particular, this won't overwrite the playback PTS in coverart mode, which actually fixes relative seeks.
* player: eagerly redraw OSD when seeking with coverartwm42016-04-231-1/+2
|
* player: force wakeup on playback restartwm42016-04-201-0/+1
| | | | Just a theoretical issue, most likely.
* player: reduce some timer callswm42016-04-201-4/+5
|
* player: minor simplification to buffering property updateswm42016-04-201-9/+4
| | | | | | | | | | Strictly schedule an update in regular intervals as long as either stream cache or demuxer are prefetching. Don't update just always because the stream cache is enabled ("idle != -1") or cache-related properties are observed (mp_client_event_is_registered()). Also, the "idle" variable was awkard; get rid of it with equivalent code.
* player: simplify an aspect of buffering determinationwm42016-04-191-15/+30
| | | | | | | | | | | | | | | Calculate the buffering percentage in the same code which determines whether the player is or should be buffering. In particular it can't happen that percentage and buffering state are slightly out of sync due to calling DEMUXER_CTRL_GET_READER_STATE and reusing it with the previously determined buffering state. Now it's also easier to guarantee that the buffering state is updated properly. Add some more verbose output as well. (Damn I hate this code, why did I write it?)
* player: loop on end of file if ab-loop-b is unsetwm42016-04-181-0/+3
| | | | Possibly slightly more useful/intuitive.
* cache: use a single STREAM_CTRL for various cache infowm42016-03-291-2/+3
| | | | | | | | Instead of having a separate for each, which also requires separate additional caching in the demuxer. (The demuxer adds an indirection, since STREAM_CTRLs are not thread-safe.) Since this includes the cache speed, this should fix #3003.
* player: simplify mp_seek()wm42016-02-281-55/+46
|
* demux: remove relative seekingwm42016-02-281-12/+3
| | | | | | | | | | | | | | | | | | | Ever since a change in mplayer2 or so, relative seeks were translated to absolute seeks before sending them to the demuxer in most cases. The only exception in current mpv is DVD seeking. Remove the SEEK_ABSOLUTE flag; it's not the implied default. SEEK_FACTOR is kept, because it's sometimes slightly useful for seeking in things like transport streams. (And maybe mkv files without duration set?) DVD seeking is terrible because DVD and libdvdnav are terrible, but mostly because libdvdnav is terrible. libdvdnav does not expose seeking with seek tables. (Although I know xbmc/kodi use an undocumented API that is not declared in the headers by dladdr()ing it - I think the function is dvdnav_jump_to_sector_by_time().) With the current mpv policy if not giving a shit about DVD, just revert our half-working seek hacks and always use dvdnav_time_search(). Relative seeking might get stuck sometimes; in this case --hr-seek=always is recommended.
* player: minor simplificationwm42016-02-271-12/+5
| | | | | | No need to pass endpts down in such a dumb way. Also remove an outdated comment somewhere.
* player: fix --force-window behaviorwm42016-02-251-2/+2
| | | | | | | | | | | | | | | | | _Of course_ the previous commit broke --force-window behavior (like it does every single time I touch it). vo_has_frame() gets cleared after a seek, so e.g. stopping playback of a file and going to the next by keeping the seek key down will enter a short moment without video at the end of the first file, which will set the stalled_video variable to true. Prevent it by using the indication whether the window was properly created (which is probably exactly what we want here). This function is also responsible for destroying the window when needed, and obviously we should never do that while video is active. (This is the actual bug, although the other change in this commit already hides the common breakage it caused.)
* player: honor --force-window if video is selected, but inactivewm42016-02-241-4/+10
| | | | | If a video track is selected, but no video is decoded from it (mostly with broken files), then create the window anyway.
* player: remove old timeline/ordered chapters supportwm42016-02-151-47/+12
|
* player: add complex filter graph supportwm42016-02-051-0/+53
| | | | | | | | | | | | | | | | See --lavfi-complex option. This is still quite rough. There's no support for dynamic configuration of any kind. There are probably corner cases where playback might freeze or burn 100% CPU (due to dataflow problems when interaction with libavfilter). Future possible plans might include: - freely switch tracks by providing some sort of default track graph label - automatically enabling audio visualization - automatically mix audio or stack video when multiple tracks are selected at once (similar to how multiple sub tracks can be selected)
* player: refactor: eliminate MPContext.d_audiowm42016-01-221-3/+3
|
* Relicense some non-MPlayer source files to LGPL 2.1 or laterwm42016-01-191-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This covers source files which were added in mplayer2 and mpv times only, and where all code is covered by LGPL relicensing agreements. There are probably more files to which this applies, but I'm being conservative here. A file named ao_sdl.c exists in MPlayer too, but the mpv one is a complete rewrite, and was added some time after the original ao_sdl.c was removed. The same applies to vo_sdl.c, for which the SDL2 API is radically different in addition (MPlayer supports SDL 1.2 only). common.c contains only code written by me. But common.h is a strange case: although it originally was named mp_common.h and exists in MPlayer too, by now it contains only definitions written by uau and me. The exceptions are the CONTROL_ defines - thus not changing the license of common.h yet. codec_tags.c contained once large tables generated from MPlayer's codecs.conf, but all of these tables were removed. From demux_playlist.c I'm removing a code fragment from someone who was not asked; this probably could be done later (see commit 15dccc37). misc.c is a bit complicated to reason about (it was split off mplayer.c and thus contains random functions out of this file), but actually all functions have been added post-MPlayer. Except get_relative_time(), which was written by uau, but looks similar to 3 different versions of something similar in each of the Unix/win32/OSX timer source files. I'm not sure what that means in regards to copyright, so I've just moved it into another still-GPL source file for now. screenshot.c once had some minor parts of MPlayer's vf_screenshot.c, but they're all gone.
* player: refactor: eliminate MPContext.d_videowm42016-01-171-6/+6
| | | | | | | | | | | | | | Eventually we want the VO be driven by a A->V filter, so a decoder doesn't even have to exist. Some features definitely require a decoder though (like reporting the decoder in use, hardware decoding, etc.), so for each thing which accessed d_video, it has to be redecided if and how it can access decoder state. At least the "framedrop" property slightly changes semantics: you can now always set this property, even if no video is active. Some untested changes in this commit, but our bio-based distributed test suite has to take care of this.
* player: refactor: eliminate MPContext.d_subwm42016-01-171-2/+1
| | | | The same is going to happen to d_video and d_audio later.
* player: simplify backsteppingwm42016-01-121-98/+18
| | | | | | | | | | | | | | Basically reimplement it. The old implementation was quite stupid, and was probably done this way because video filtering and output used to be way less decoupled. Now we can reimplement it in a very simple way: when backstepping, seek to current time, but keep the last frame that was supposed to be discarded when reaching the target time. When the seek finishes, prepend the saved frame to the video frame queue. A disadvantage is that the new implementation fails to skip over timeline boundaries (ordered chapters etc.), but this never worked properly anyway. It's possible that this will be fixed some time in the future.
* player: handle hrseek framedrop correctlywm42016-01-121-1/+1
| | | | | This was non-sense and checked the option instead of the actual flag. Possibly could lead to incorrect hr-seeks.
* mpv_talloc.h: rename from talloc.hDmitrij D. Czarkoff2016-01-111-1/+1
| | | | This change helps avoiding conflict with talloc.h from libtalloc.
* player: eliminate demux_get_next_pts()wm42016-01-111-2/+2
| | | | | | | | | | | | | | | | This slightly changes behavior when seeking with external audio/subtitle tracks if transport streams and mpeg files are played, as well as behavior when seeking with such external tracks. get_main_demux_pts() is evil because it always blocks on the demuxer (if there isn't already a packet queued). Thus it could lock up the player, which is a shame because all other possible causes have been removed. The reduced "precision" when seeking in the ts/mpeg cases (where SEEK_FACTOR is used, resulting in byte seeks instead of timestamp seeks) might lead to issues. We should probably drop this heuristic. (It was introduced because there is no other way to seek in files with PTS resets with libavformat, but its value is still questionable.)
* sub: change how subtitles are readwm42015-12-291-1/+2
| | | | | | | | Slightly change how it is decided when a new packet should be read. Switch to demux_read_packet_async(), and let the player "wait properly" until required subtitle packets arrive, instead of blocking everything. Move distinguishing the cases of passive and active reading into the demuxer, where it belongs.
* video: switch from using display aspect to sample aspectwm42015-12-191-1/+1
| | | | | | | | | | | | | | | | MPlayer traditionally always used the display aspect ratio, e.g. 16:9, while FFmpeg uses the sample (aka pixel) aspect ratio. Both have a bunch of advantages and disadvantages. Actually, it seems using sample aspect ratio is generally nicer. The main reason for the change is making mpv closer to how FFmpeg works in order to make life easier. It's also nice that everything uses integer fractions instead of floats now (except --video-aspect option/property). Note that there is at least 1 user-visible change: vf_dsize now does not set the display size, only the display aspect ratio. This is because the image_params d_w/d_h fields did not just set the display aspect, but also the size (except in encoding mode).
* player: make timeline switching slightly nicerwm42015-11-181-9/+5
| | | | But not much.
* player: use demuxer ts offset to simplify timeline ts handlingwm42015-11-161-5/+3
| | | | | | | | | Use the demux_set_ts_offset() added in the previous commit to base each timeline segment to use timestamps according to its relative position within the overall timeline. As a consequence we don't need to care about these timestamps anymore, and everything becomes simpler. (Another minor but delicious nugget of sanity.)
* player: handle rebasing start time differentlywm42015-11-161-12/+10
| | | | | | | | | | | | | | | | Most of this is explained in the DOCS additions. This gives us slightly more sanity, because there is less interaction between the various parts. The goal is getting rid of the video_offset entirely. The simplification extends to the user API. In particular, we don't need to fix missing parts in the API, such as the lack for a seek command that seeks relatively to the start time. All these things are now transparent. (If someone really wants to know the real timestamps/start time, new properties would have to be added.)
* player: refactor display-sync frame duration calculationswm42015-11-131-21/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | Get rid of get_past_frame_durations(), which was a bit too messy. Add a past_frames array, which contains the same information in a more reasonable way. This also means that we can get the exact current and past frame durations without going through awful stuff. (The main problem is that vo_pts_history contains future frames as well, which is needed for frame backstepping etc., but gets in the way here.) Also disable the automatic disabling of display-sync if the frame duration changes, and extend the frame durations allowed for display sync. To allow arbitrarily high durations, vo.c needs to be changed to pause and potentially redraw OSD while showing a single frame, so they're still limited. In an attempt to deal with VFR, calculate the overall speed using the average FPS. The frame scheduling itself does not use the average FPS, but the duration of the current frame. This does not work too well, but provides a good base for further improvements. Where this commit actually helps a lot is dealing with rounded timestamps, e.g. if the container framerate is wrong or unknown, or if the muxer wrote incorrectly rounded timestamps. While the rounding errors apparently can't be get rid of completely in the general case, this is still much better than e.g. disabling display-sync completely just because some frame durations go out of bounds.
* command: make time properties unavailable if timestamp is unknownwm42015-10-161-8/+11
| | | | | | Let's hope this doesn't confuse client API users too much. It's still the best solution to get rid of corner cases where it actually return the wrong timestamp on start, and then suddenly jump.
* video/out: remove an unused parameterwm42015-10-031-1/+1
| | | | | | | | | | | This parameter has been unused for years (the last flag was removed in commit d658b115). Get rid of it. This affects the general VO API, as well as the vo_opengl backend API, so it touches a lot of files. The VOFLAGs are still used to control OpenGL context creation, so move them to the OpenGL backend code.
* player: some more --force-window fixeswm42015-09-211-11/+16
| | | | | | | | | | | | | Sigh... After the recent changes, another regression appeared. This time, the VO window wasn't cleared when changing from video to a non- video file (such as audio-only with no cover art). Fix this by properly taking the handle_force_window() bool parameter into account. Also, the info message could be printed twice, which is harmless but ugly. So just remove the message. Also, do some more minor cleanups (like fixing the comment, which was completely outdated).
* player: do not destroy VO prematurely when initializing playbackwm42015-09-201-1/+2
| | | | | | | | | | If --force-window wasn't used, this would destroy the VO while a file is still being loaded, resulting in flicker and other interruptions when switching from one playlist entry to another. Recent regression. The condition used here is pretty tricky, but it boils down to that it should trigger either in idle mode, or when loading has been fully done (at these points we definitely know whether the VO will be needed).
* player: make force-window in auto-profiles actually workwm42015-09-201-10/+32
| | | | | | | | | | | The previous commit was incomplete (and I didn't notice due to a broken test procedure). The annoying part is that actually creating the VO was separate; redo this and merge the code for this into handle_force_window() as well. This will also make implementing proper reaction to runtime option changes easier. (Only the part for actually listening to option changes is missing.)
* player: return better guess for playback time during seekswm42015-08-211-13/+27
| | | | | | | | Always compute the estimated absolute time of the seek target, and display this as playback time during seeks. Improves behavior with e.g. .ts files, for which we try to avoid seeks by timestamp.
* player: deliver IDLE event after uninitializing statewm42015-08-201-1/+1
| | | | | | | | | A client API user might count on the fact that audio and video outputs have already been uninitialized. (They remain uninitialized before entering idle mode in order to allow smooth transition to the next playlist entry.) Since event delivery is asynchronous, this has to happen after actually doing the uninitialization, or the client will essentially run into a race condition.
* demux: remove redundant demux_chapter.name fieldwm42015-08-121-2/+1
| | | | | | | | | | Instead, force everyone to use the metadata struct and set a "title" field. This is only a problem for the timeline producers, which set up chapters manually. (They do this because a timeline is a separate struct.) This fixes the behavior of the chapter-metadata property, which never returned a "title" property for e.g. ordered chapters.
* player: raise maximum idle timewm42015-08-071-1/+1
| | | | No reason to wake up every other minute.
* player: remove higher-level remains of DVD/BD menu supportwm42015-08-031-2/+0
| | | | | | | | | | | | | | | Nobody wanted to restore this, so it gets the boot. If anyone still wants to volunteer to restore menu support, this would be welcome. (I might even try it myself if I feel masochistic and like wasting a lot of time for nothing.) But if it does get restored, it should be done differently. There were many stupid things about how it was done. For example, it somehow tried to pull mp_nav_events through all the layers (including needing to "buffer" them in the demuxer), which was needlessly complicated. It could be done simpler. This code was already inactive, so this commit actually changes nothing. Also keep in mind that normal DVD/BD playback still works.
* player: put --term-playing-msg in a separate log categorywm42015-07-131-1/+3
| | | | Fixes #1983.
* player: refactor chapter seek codewm42015-07-101-22/+1
| | | | | | | mp_seek_chapter() had only 1 caller. Also the code was rather roundabout; the entire function can be compressed to 5 lines of code. (The new code is functionally the same - "mpctx->last_chapter_seek = -2;" was effectively a dead assingment.)
* player: never overwrite stop_play fieldwm42015-07-081-2/+3
| | | | | | | This is a real pain: if a quit command is received, it's set to PT_QUIT. And then other code could overwrite it, making it not quit. The annoying bit is that stop_play is written and read in many places. Just not overwriting it unconditionally seems to be the best course of action.
* player: increase tick event update frequencywm42015-06-231-1/+1
| | | | | | | | | | | | | | | 500ms is a bit too high. Change it to 50ms. This improves client API (and Lua) playback state update frequency. Updating absolutely every time the audio PTS changes would be possible, but is not helpful. Audio samplerates are high to trigger a wakeup feedback loop, so the process would waste CPU time on updating the playback position all the time. (If a client application wants to ensure smooth update of the playback position, it should update the position manually using a timer and by reading the property - the application can make a much better decision at how often the playback has to happen.)
* player: add some debug output for seekingwm42015-06-181-0/+4
|
* command: do not exit playback if the B point of A-B loop is past EOFwm42015-06-161-0/+2
| | | | | | | | | | | | | | The previous behavior is confusing if the B point is near EOF (consider B being the duration of the file, which is strictly speaking past the last video timestamp). The new behavior is fine as well for B being far past EOF. Achieve this by checking the EOF state in addition to whether playback has reached the B point. Also, move the A-B loop code out of command_event(). It just isn't useful anymore, and obfuscates the code more than it makes it loop simple. Fixes #2046.
* player: do not exit when a seek gets queuedwm42015-06-161-0/+4
| | | | | | | | | Seems logical. Note that if playback otherwise ends while playback is active and a seek is still queued, we still exit. Otherwise you couldn't end playback by seeking past the end of the file (which is classic MPlayer and mpv behavior).
*