summaryrefslogtreecommitdiffstats
path: root/player/video.c
Commit message (Collapse)AuthorAgeFilesLines
* player: remove redundant checkwm42015-12-051-1/+1
| | | | Found by Coverity.
* player: don't make display-sync panic on timestamp discontinuitieswm42015-12-041-2/+2
|
* player: resync audio only on larger timestamp discontinuitieswm42015-12-041-2/+2
| | | | | | | | | Helps with files that have occasional broken timestamps. For larger discontinuities, e.g. caused by actual timestamp resets, we still want to realign audio. (I guess in general, this should be removed and replaced by a more general resync-on-desync logic, but not now.)
* vo_opengl: fix interpolation with display-syncwm42015-11-281-1/+2
| | | | | | | | | | | | | | | | | | | | At least I hope so. Deriving the duration from the pts was not really correct. It doesn't include speed adjustments, and becomes completely wrong of the user e.g. changes the playback speed by a huge amount. Pass through the accurate duration value by adding a new vo_frame field. The value for vsync_offset was not correct either. We don't need the error for the next frame, but the error for the current one. This wasn't noticed because it makes no difference in symmetric cases, like 24 fps on 60 Hz. I'm still not entirely confident in the correctness of this, but it sure is an improvement. Also, remove the MP_STATS() calls - they're not really useful to debug anything anymore.
* player: fix commit 50bb209awm42015-11-281-1/+1
| | | | Well, this was stupid.
* vo: change vo_frame field unitswm42015-11-271-1/+2
| | | | | | | This was just converting back and forth between int64_t/microseconds and double/seconds. Remove this stupidity. The pts/duration fields are still in microseconds, but they have no meaning in the display-sync case (also drop printing the pts field from opengl/video.c - it's always 0).
* player: always disable display-sync on desyncswm42015-11-271-22/+12
| | | | | | | | | | | | | | | Instead of periodically trying to enable it again. There are two cases that can happen: 1. A random discontinuity messed everything up, 2. Things are just broken and will desync all the time Until now, it tried to deal with case 1 - but maybe this is really rare, and we don't really need to care about it. On the other hand, case 2 is kind of hard to diagnose if the user doesn't use the terminal. Seeking will reenable display-sync, so you can fix playback if case 1 happens, but still get predictable behavior in case 2.
* player: make display-vdrop mode do what the manpage claimswm42015-11-261-4/+7
| | | | | Don't change video speed in this mode, which is closer to the claim on the manpage that it's close to the behavior of the "audio" mode.
* player: log some more display-sync informationwm42015-11-251-3/+6
|
* player: use demuxer ts offset to simplify timeline ts handlingwm42015-11-161-4/+0
| | | | | | | | | 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: account for minor VO underrunswm42015-11-141-2/+2
| | | | | | | | | If the player sends a frame with duration==0 to the VO, it can trivially underrun. Don't panic, but keep the correct time. Also, returning the absolute time from vo_get_next_frame_start_time() just to turn it into a float with relative time was silly. Rename it and make it return what the caller needs.
* player: fix audio drift computation at different playback speedswm42015-11-141-8/+9
| | | | | This computed nonsense if the user set a playback speed other than 1 (in addition to the display-sync speed change).
* player: stricter framedrop thresholdwm42015-11-131-3/+2
| | | | | | 80ms allowable desync was a bit too much. It'd allow for a range of 160ms, which everyone can notice. It might also be a bother to apply compensation resampling speed for that long.
* player: try to compensate actual audio driftwm42015-11-131-0/+40
| | | | | | | | | | | | | | | | We always let audio slowly desync until a threshold is reached, and then pushed it back by applying a maximum compensation speed. Refine what comes afterwards: instead of playing with the nominal video speed, use the actual required audio speed for keeping sync as measured by the A/V difference. (The "actual" speed is the ideal speed with A/V differences added.) Although this works in theory, it's somewhat questionable how much this works in practice. The ideal time value is actually not exact, but is the time at which the frame is scheduled (could be compensated by using the time_left calculations in handle_display_sync_frame()). It doesn't account for speed changes or catastrophic discontinuities. It uses only 10 past frames.
* player: change display-sync audio speed only if neededwm42015-11-131-38/+48
| | | | | | | | | | As long as it's within the desync tolerance, do not change the audio speed at all for resampling. This reduces speed changes which might be caused by jittering timestamps and similar cases. (While in theory you could just not care and change speed every single frame, I'm afraid that such changes could possibly cause audio artifacts. So better just avoid it in the first place.)
* player: remove display_sync_disable_counterwm42015-11-131-10/+8
| | | | We can implement it differently and drop a tiny bit of state.
* command: add vsync-ratio propertywm42015-11-131-4/+7
| | | | | | | | This is very "illustrative", unlike the video-speed-correction property, and thus useful. It can also be used to observe scheduling errors, which are not detected by the core. (These happen due to rounding errors; possibly not evne our fault, but coming from files with rounded timestamps and so on.)
* player: compute required display-sync speed change differentlywm42015-11-131-22/+36
| | | | | | | | | | | | | Instead of looking at the current frame duration for the intended speedup, look at all past frames, and find a good average speed. This ties in with not wanting to average _all_ frame durations, which doesn't make sense in VFR situations. This is currently done in the most naive way possible, but already sort of works for VFR which switches between frame durations that are integer multiples of a base rate. Certainly more improvements could be made, such as trying to adjust directly on FPS changes, instead of averaging everything, but for now this is not needed at all.
* player: smooth out frame durations by averaging themwm42015-11-131-1/+1
| | | | | | | | | | | | | | | | | | Helps somewhat with muxer-rounded timestamps. There is some danger that this introduces a timestamp drift. But since they are averaged values (unlike as when using an incorrect container framerate hint), any potential drift shouldn't be too brutal, or compensate itself soon. So I won't bother yet with comparing the results with the real timestamp, unless we run into actual problems. Of course we still prefer potentially real timestamps over the approximated ones. But unless the timestamps match the container FPS, we can't know whether they are (no, checking whether the they have microsecond components would be cheating). Perhaps in future, we could let the demuxer export the timebase - if the timebase is not 1000 (or divisible by it), we know that millisecond-rounded timestamps won't happen.
* player: refactor display-sync frame duration calculationswm42015-11-131-103/+83
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* player: always require a future frame with display-sync enabledwm42015-11-131-2/+6
| | | | | | We need a frame duration even on start, because the number of vsyncs the frame is shown is predetermined. (vo_opengl actually makes use of this property in certain cases.)
* player: less naive roundingwm42015-11-111-1/+1
|
* player: use input instead of output format for spdif checkwm42015-11-041-1/+1
| | | | | | This check disables the display-sync resample method. If the filters convert PCM to AC3, we can still insert a filter to change speed. This is because filters are inserted at the beginning of the filter chain.
* player: move audio speed adjustment codewm42015-11-041-54/+60
| | | | | | | | | Move it (in a cosmetic sense), and also move its invocation to below all the video handling. All other changes remain cosmetic, including moving the framedrop calculation code, and getting rid of the video_speed_correction variable.
* player: another fix to A/V difference calculation in display-sync modewm42015-11-011-1/+1
| | | | | | | update_av_diff() works on the timestamps, while time_left is in real time. When playing at not-1 speed, these are very different, and cause the A/V difference to jitter. Fix this by scaling the expected A/V desync to the correct range.
* video: fix another A/V difference bug in display-sync modewm42015-10-311-2/+3
| | | | | | | | | | | | | | | This didn't show up with cases where the frame pattern has a cycle of 1 or 2 like it is the case with 24-on-24 fps, or 24-on-60 fps. It did show up with 25-on-60 fps. (We don't slow down 25 fps video to 24 on default settings.) In this case, we must not add the timing error of the next frame to the A/V difference estimation of the current frame. Use the previous timing error instead. This is another bug resulting from the confusion about whether we calculate parameters for the currently playing frame, or the one we're about to queue.
* command: add mistimed-frame-count propertywm42015-10-301-0/+4
| | | | | Does what the manpage says. This is a replacement incrementing the dropped frame counter (see previous commit).
* video: fix framedrop accounting in display-sync modewm42015-10-301-2/+0
| | | | | | | | | | | | | | Commit a1315c76 broke this slightly. Frame drops got counted multiple times, and also vo.c was actually trying to "render" the dropped frame over and over again (normally not a problem, since frames are always queued "tightly" in display-sync mode, but could have caused 100% CPU usage in some rare corner cases). Do not repeat already dropped frames, but still treat new frames with num_vsyncs==0 as dropped frames. Also, strictly count dropped frames in the VO. This means we don't count "soft" dropped frames anymore (frames that are shown, but for fewer vsyncs than intended). This will be adjusted in the next commit.
* player: raise display sync desync tolerancewm42015-10-281-5/+2
| | | | | | | Bump it to 80, and 2 vsyncs. This is another measure against vsync jitter. Admittedly this is a bit simplistic (and we should probably estimate a stable estimated vsync phase instead), but for now this will do.
* player: minor refactor for A/V diff computationwm42015-10-281-19/+27
| | | | | | | | Calculate the A/V difference directly in the display sync code, instead of the awkward current way, which reuses the fields for audio sync. We still set time_frame, because it makes falling back to audio sync somewhat smoother.
* player: fix display sync A/V difference estimation on dropswm42015-10-281-0/+2
| | | | | | | When dropping or repeating frames, we essentially influence when the frame after the next frame will be shown, not the next frame. This led to dropping/repeating frames 2 times, because the A/V difference had a delay of one frame. Compensate it with the expected value.
* player: disable total-avsync-change update in display-sync modewm42015-10-271-0/+4
| | | | | The total-avsync-change property made no sense in display-sync mode (in addition to making not all that much sense in general).
* player: fix display-sync A/V calculation on high playback speedswm42015-10-271-0/+1
| | | | | | This is all kinds of stupid - update_avsync_after_frame() will multiply this value with the speed at a later point, and we only update this field for this function. (This should be refactored.)
* player: add audio drop/duplicate modewm42015-10-271-1/+1
| | | | Not very robust in the moment.
* player: be slightly less prone to framedrop in display sync modewm42015-10-191-3/+7
| | | | | 1 to 2 frames desync is still tolerable, and will be quickly compensated (if everything works).
* player: do not use copysign()wm42015-10-191-1/+1
| | | | | | | Apparently this function caused weird problems to me. I have no idea why. The usage of the function looks perfectly fine to me, and even rounding issues can be excluded. In any case, getting rid of this solved my problem, and makes the code actually more readable.
* player: fix an adjustment in display sync modewm42015-10-141-1/+1
| | | | | | This adjustment is supposed to improve the audio speed calculation in case of unexpected desync. The flipped sign made it actually worse, although the total impact of this bug was very minor.
* player: fix missed wakeup on video EOFwm42015-10-091-0/+3
| | | | | | | If video EOF happens during playback restart, and audio is syncing, and the demuxer packet queue overflows (i.e. no new packets will be read), then it could happen that the player accidentally enters sleeping, and continues playing anything only after e.g. user input wakes it up.
* 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.
* video: replace vf_format outputlevels option with global optionwm42015-09-291-0/+1
| | | | | | | | | | | The vf_format suboption is replaced with --video-output-levels (a global option and property). In particular, the parameter is removed from mp_image_params. The mechanism is moved to the "video equalizer", which also handles common video output customization like brightness and contrast controls. The new code is slightly cleaner, and the top-level option is slightly more user-friendly than as vf_format sub-option.
* player: fix excessive CPU usage in audio-only modewm42015-09-221-3/+4
| | | | | | | | | Caused by one of the --force-window commits. The unconditional uninit_video_out() call (which normally should be idempotent) raised sporadic MPV_EVENT_VIDEO_RECONFIG events. This is ok, except for the fact that clients (like a Lua script or libmpv users) would cause the event loop to run again after receiving it, triggering a feedback loop. Fix it by sending the events really only on a change.
* video: disable interpolation during framesteppingwm42015-08-251-0/+1
| | | | | | | It just causes annoying artifacts. Interestingly, this means keeping down the frame stepping key (".") will play video with interpolation disabled.
* video: don't decode 2 frames ahead with display-syncwm42015-08-191-2/+1
| | | | | This is not needed. It was used only temporarily in a development branch, and is a leftover from earlier rebasing.
* player: add display sync modewm42015-08-101-2/+204
| | | | | | | | | | | | | | | | | | | | | | | | If this mode is enabled, the player tries to strictly synchronize video to display refresh. It will adjust playback speed to match the display, so if you play 23.976 fps video on a 24 Hz screen, playback speed is increased by approximately 1/1000. Audio wll be resampled to keep up with playback. This is different from the default sync mode, which will sync video to audio, with the consequence that video might skip or repeat a frame once in a while to make video keep up with audio. This is still unpolished. There are some major problems as well; in particular, mkv VFR files won't work well. The reason is that Matroska is terrible and rounds timestamps to milliseconds. This makes it rather hard to guess the framerate of a section of video that is playing. We could probably fix this by just accepting jittery timestamps (instead of explicitly disabling the sync code in this case), but I'm not ready to accept such a solution yet. Another issue is that we are extremely reliant on OS video and audio APIs working in an expected manner, which of course is not too often the case. Consequently, the new sync mode is a bit fragile.
* player: separate controls for user and video controlled speedwm42015-08-101-5/+5
| | | | | | | | | | For video sync, we want separate playback speed controls for user- requested speed and the "correction" speed for video timing. Further, we use this separation to make sure only a resampler is inserted if playback speed is only changed for video sync correction. As of this commit, this is basically inactive code. It's just preparation for the video sync code (the following commit).
* player: redo estimated-vf-fps calculationwm42015-08-101-0/+72
| | | | | | | | | | | | | | Additionally to taking the average, this tries to use the demuxer FPS to eliminate jitter, and applies some other heuristics to check if the result is sane. This code will also be used for the display sync code (it will actually make use of the require_exact parameter). (The value of doing this over keeping the simpler demux_mkv hack is somewhat questionable. But at least it allows us to deal with other container formats that use jittery timestamps, such as mp4 remuxed from mkv.)
* video: unbreak EOF with video-only files that have timestamp resetswm42015-08-031-1/+2
| | | | | | | Normally when there's a timestamp reset, we make audio resync to make sure audio and video line up (again). But in video-only mode, just setting audio to resyncing breaks EOF detection, because there's no code which would get audio_status out of this bogus state.
* video: move frame duration code to a separate functionwm42015-08-011-11/+23
| | | | Minor preparation for something else.
* video: move up vo_frame setupwm42015-07-281-12/+12
|
* video: always decode at least 2 frames in advancewm42015-07-261-5/+1
| | | | | | | Remove the exception for decoding only 1 frame if VO framedrop is disabled. This was originally done to be able to test potential regressions when we enabled VO framedrop and decoding 2 frames by default. It's not needed anymore.
* video: always re-probe auto deint filter on filter reconfigwm42015-07-211-2/+5
| | | | | | | | | If filters are disabled or reconfigured, attempt to remove and probe the deinterlace filter again. This fixes behavior if e.g. a software deint filter was automatically inserted, and then hardware decoding is enabled during playback. Without this commit, initializing hw decoding would fail because of the software filter; with this commit, it'll replace it with the hw deinterlacer instead.
* vo: minor simplification for queue size handlingwm42015-07-201-2/+2
| | | | | | | | | | Instead of calling it "future frames" and adding or subtracting 1 from it, always call it "requested frames". This simplifies it a bit. MPContext.next_frames had 2 added to it; this was mainly to ensure a minimum size of 2. Drop it and assume VO_MAX_REQ_FRAMES is at least 2; together with the other changes, this can be the exact size of the array.
* video: don't force video refresh if video is restartingwm42015-07-101-1/+3
|
* player: never overwrite stop_play fieldwm42015-07-081-1/+1
| | | | | | | 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.
* vo: change internal API for drawing frameswm42015-07-011-11/+21
| | | | | | | | | | | | | | draw_image_timed is renamed to draw_frame. struct frame_timing is renamed to vo_frame. flip_page_timed is merged into draw_frame (the additional parameters are part of struct vo_frame). draw_frame also deprecates VOCTRL_REDRAW_FRAME, and replaces it with a method that works for both VOs which can cache the current frame, and VOs which need to redraw it anyway. This is preparation to making the interpolation and (work in progress) display sync code saner. Lots of other refactoring, and also some simplifications.
* video: pass future frames to VOwm42015-07-011-33/+59
| | | | | | | | | | Now the VO can request a number of future frames with the last parameter of vo_set_queue_params(). This will be helpful to fix the in