1
0
mirror of https://github.com/mpv-player/mpv synced 2024-12-23 15:22:09 +00:00
Commit Graph

195 Commits

Author SHA1 Message Date
wm4
b7e179f6d3 video: fix debug message
Should not be a warning, and the message text was also very useless.
2016-01-06 19:48:55 +01:00
wm4
2059ba2c40 video: do not disable hr-seek framedrop too early
This didn't make too much sense, and just made seeking slower. Strictly
suggest the decoder to drop a frame if its PTS is before the seek
target.
2015-12-30 15:51:47 +01:00
wm4
b47bf06f97 sub: change how subtitles are read
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.
2015-12-29 01:35:52 +01:00
wm4
0a0bb9059f video: switch from using display aspect to sample aspect
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).
2015-12-19 20:45:36 +01:00
wm4
c46106d633 player: remove redundant check
Found by Coverity.
2015-12-05 23:53:48 +01:00
wm4
832cb56f2d player: don't make display-sync panic on timestamp discontinuities 2015-12-04 17:07:50 +01:00
wm4
68c6da69f7 player: resync audio only on larger timestamp discontinuities
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.)
2015-12-04 16:55:55 +01:00
wm4
318e9801f2 vo_opengl: fix interpolation with display-sync
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.
2015-11-28 15:45:49 +01:00
wm4
ea1caa474a player: fix commit 50bb209a
Well, this was stupid.
2015-11-28 02:24:03 +01:00
wm4
7023c383b2 vo: change vo_frame field units
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).
2015-11-27 22:04:44 +01:00
wm4
50bb209a80 player: always disable display-sync on desyncs
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.
2015-11-27 14:40:52 +01:00
wm4
b250c19a38 player: make display-vdrop mode do what the manpage claims
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.
2015-11-26 18:53:32 +01:00
wm4
5bc9b273b3 player: log some more display-sync information 2015-11-25 22:07:47 +01:00
wm4
85450d06a1 player: use demuxer ts offset to simplify timeline ts handling
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.)
2015-11-16 23:17:33 +01:00
wm4
a790009a63 player: account for minor VO underruns
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.
2015-11-14 21:49:48 +01:00
wm4
9f43778eb2 player: fix audio drift computation at different playback speeds
This computed nonsense if the user set a playback speed other than 1
(in addition to the display-sync speed change).
2015-11-14 21:42:25 +01:00
wm4
0f3dedebb4 player: stricter framedrop threshold
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.
2015-11-13 22:53:38 +01:00
wm4
70d46a9fb8 player: try to compensate actual audio drift
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.
2015-11-13 22:51:39 +01:00
wm4
c362c3d7ae player: change display-sync audio speed only if needed
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.)
2015-11-13 22:50:58 +01:00
wm4
07b8abbd62 player: remove display_sync_disable_counter
We can implement it differently and drop a tiny bit of state.
2015-11-13 22:49:50 +01:00
wm4
d5981924fe command: add vsync-ratio property
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.)
2015-11-13 22:48:32 +01:00
wm4
62b386c2fd player: compute required display-sync speed change differently
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.
2015-11-13 22:47:14 +01:00
wm4
fad254562b player: smooth out frame durations by averaging them
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.
2015-11-13 22:46:55 +01:00
wm4
d32c4c75ef player: refactor display-sync frame duration calculations
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.
2015-11-13 22:45:40 +01:00
wm4
624c9e46ce player: always require a future frame with display-sync enabled
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.)
2015-11-13 22:42:42 +01:00
wm4
7c4fe02d01 player: less naive rounding 2015-11-11 19:52:35 +01:00
wm4
179d7317e7 player: use input instead of output format for spdif check
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.
2015-11-04 21:49:54 +01:00
wm4
8f7cf9443f player: move audio speed adjustment code
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.
2015-11-04 21:49:54 +01:00
wm4
f1e767b6a2 player: another fix to A/V difference calculation in display-sync mode
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.
2015-11-01 19:53:48 +01:00
wm4
8fd63c8f0c video: fix another A/V difference bug in display-sync mode
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.
2015-10-31 13:21:16 +01:00
wm4
7aba3a5d96 command: add mistimed-frame-count property
Does what the manpage says. This is a replacement incrementing the
dropped frame counter (see previous commit).
2015-10-30 14:05:41 +01:00
wm4
acd5816a6d video: fix framedrop accounting in display-sync mode
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.
2015-10-30 13:26:55 +01:00
wm4
33489feca8 player: raise display sync desync tolerance
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.
2015-10-28 23:57:27 +01:00
wm4
fc3f1e7c54 player: minor refactor for A/V diff computation
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.
2015-10-28 23:57:24 +01:00
wm4
466658ee7e player: fix display sync A/V difference estimation on drops
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.
2015-10-28 23:57:24 +01:00
wm4
70aa3b04f8 player: disable total-avsync-change update in display-sync mode
The total-avsync-change property made no sense in display-sync mode (in
addition to making not all that much sense in general).
2015-10-27 20:56:58 +01:00
wm4
c24921d56b player: fix display-sync A/V calculation on high playback speeds
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.)
2015-10-27 20:56:49 +01:00
wm4
aaec2aba38 player: add audio drop/duplicate mode
Not very robust in the moment.
2015-10-27 20:56:46 +01:00
wm4
750c29766f player: be slightly less prone to framedrop in display sync mode
1 to 2 frames desync is still tolerable, and will be quickly compensated
(if everything works).
2015-10-19 23:45:43 +02:00
wm4
b0b67cdf5d player: do not use copysign()
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.
2015-10-19 23:44:50 +02:00
wm4
3274fabeb3 player: fix an adjustment in display sync mode
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.
2015-10-14 18:53:00 +02:00
wm4
dbbde6161d player: fix missed wakeup on video EOF
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.
2015-10-09 15:53:02 +02:00
wm4
291f301c10 video/out: remove an unused parameter
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.
2015-10-03 18:20:16 +02:00
wm4
ee63c9c210 video: replace vf_format outputlevels option with global option
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.
2015-09-29 21:12:26 +02:00
wm4
a75e933dac player: fix excessive CPU usage in audio-only mode
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.
2015-09-22 11:19:39 +02:00
wm4
f1778d1f5b video: disable interpolation during framestepping
It just causes annoying artifacts.

Interestingly, this means keeping down the frame stepping key (".") will
play video with interpolation disabled.
2015-08-25 21:48:11 +02:00
wm4
cab1f6439c video: don't decode 2 frames ahead with display-sync
This is not needed. It was used only temporarily in a development
branch, and is a leftover from earlier rebasing.
2015-08-19 21:24:56 +02:00
wm4
031555fbe6 player: add display sync mode
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.
2015-08-10 18:48:45 +02:00
wm4
fedaad8250 player: separate controls for user and video controlled speed
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).
2015-08-10 18:40:16 +02:00
wm4
3d1cc17ab2 player: redo estimated-vf-fps calculation
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.)
2015-08-10 18:38:57 +02:00