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).
It always was a weird artifact - VOCTRLs are meant _not_ to require
special handling in the code that passes them through (like in vo.c).
Removing it is also interesting to further reduce the dependency of
backends on struct vo. Just get rid of it.
Removing it is somewhat inconvenient, because in many situations the UI
window is created after the first VOCTRL_UPDATE_WINDOW_TITLE. This means
these backends have to store it in a new field in their own context.
Don't use the average FPS if there are likely skipped vsyncs. Note that
we don't use the normal skip detection, as it is unreliable if the real
and assumed display FPS differ too much. The normal skip detection is
still in place as it's more reliable in the case when vsync jitters
much, but the display FPS is relatively exact.
Further improvement over commit 41f2c653.
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).
If we switched away from the system FPS, we were remaining in this mode
ssentially forever. There's no reason to do so; switch back if the
estimated FPS gets worse again. Improvement over commit 41f2c653.
Commit 12eb8b2d accidentally disabled framedropping in the audio timing
case. It tried to replace the last_flip field with the prev_vsync one,
which didn't work because prev_sync is reset to 0 if the timing code is
used. Fix it by always setting it properly. This field must (or should)
be reinitialized to something sensible when switching to display sync
timing mode; since prev_vsync is not reset anymore, the check when to
reinitialize this field has to be adjusted as well.
It's a bit weird that update_vsync_timing_after_swap() now does some
minor work for timing mode too, but I guess it's ok, if only to avoid
additional fields and timer calls.
If the system-reported display FPS (returned by the VO backends, or
forced with --display-fps) is too imprecise (deviating frame duration by
more than 1%). This works if the display FPS is off by almost 1 (typical
for old/bad/broken OS APIs). Actually it even works if the FPs is
completely wrong.
Is it a good idea? Probably not. It might be better to only output a
warning message. But unless there are reports about it going terribly
wrong, I'll go with this for now.
Actually I'm not content with the detection added in commit 44376d2d. It
triggers too often if vsync is very jittery. It's easy to avoid this: we
add more samples to the detection by reusing the drift computation loop.
If there's a significant step in the drift, we consider it a drop.
Return the estimated/ideal flip time to the timing logic (meaning
vo_get_delay() returns a smoothed out time). In addition to this add
some lame but working drift compensation. (Useful especially if the
display FPS is wrong by a factor such as 1.001.)
Also remove some older leftovers. The vsync_interval_approx and
last_flip fields are redundant or unneeded.
For the vo-delayed-frame-count property.
Slightly less dumb than the previous one (which was removed earlier),
but still pretty dumb. But this also seems to be relatively robust, even
with strong vsync jittering.
This logic was kind of questionable anyway, and --display-sync should
give much better results. (I would even go as far as saying that the
FPS-dependent framedrop code made things worse in some situations. Not
all, though.)
This is simply the average refresh rate. Including "bad" samples is
actually an advantage, because the property exists only for
informational purposes, and will reflect problems such as the driver
skipping a vsync.
Also export the standard deviation of the vsync frame duration
(normalized to the range 0-1) as vsync-jitter property.
It doesn't have any real purpose anymore. Up until now, it was still
implemented by vo_wayland, but since we changed how the frame callbacks
work, even that appears to be pointless.
Originally, the plan was to somehow extend this mechanism to all
backends and to magically fix frame scheduling, but since we can't hope
for proper mechanisms even on wayland, this idea looks way less
interesting.
Currently, vo.c will always continue to render the currently queued
frame, which sets last_flip, which in turn confuses vo_get_delay(),
which in turn will show a bogus A/V desync message on unpause. So just
reset it again on unpause.
I guess the removed code is an old leftover, and makes no sense anymore.
Should fix weird A/V diff dropouts when frames are being dropped with
display-sync.
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.
"Missed" implies the frame was dropped, but what really happens is that
the following frame will be shown later than intended (due to the
current frame skipping a vsync).
(As of this commit, this property is still inactive and always
returns 0. See git blame for details.)
next_vsync/prev_vsync was only used to retrieve the vsync duration. We
can get this in a simpler way.
This also removes the vsync duration estimation from vo_opengl_cb.c,
which is probably worthless anyway. (And once interpolation is made
display-sync only, this won't matter at all.)
This affects only the display-sync code path, as for normal timing the
wakeup_pts stuff handles proper wakeup. It's probably mostly a
theoretical issue.
Commit acd5816a broke this. It was stopping playback occasionally.
Another case where the non-display-sync interpolation mode
(in->vsync_timed==true) is causing a lot of subtle issues and will be
removed soon.
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.
This was not very reliable.
In the normal vo_opengl case, this didn't deal well enough with vsync
jitter. Vsync timings can jitter quite extremely, up to a whole vsync
duration, in which case the "missed" frame counter keeps growing, even
though nothing is wrong. This behavior also messes up the A/V difference
calculation, but as long as it's within tolerance, it won't provoke
extra frame dropping/repeating. Real misses are harder to detect, and I
might add such detection later.
In the vo_opengl_cb case, this was additionally broken due to the
asynchronity between renderer and VO threads.
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.
This reverts commit d11184a256.
Unfortunately, there was a lot of unexpected resistance.
Do note that this is still extremely slow, crappy, etc.
Note that vo_x11.c was further edited. Compared to the removed vo_x11.c,
an additional ~200 lines of code was removed in order to simplify it. I
tried to strip it down as much as possible. In particular, support for
odd non-32 bit formats (24, 16, 15, 8 bit) is dropped.
Closes#2300.
We must not use the frame PTS in any case. In this case, it fails
because nothing sets it up to wake up. This typically caused the player
to apparently "pause", until something else waked it up, like moving the
mouse and other events.
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.
Pretty stupid: vo_get_vsync_interval() returns a negative value if the
display FPS is unknown (e.g. xrandr not compiled), and the comparison
whether the value is below 0 fails later because it's assigned to an
unsigned int.
Regression since commit e3d85ad4.
Also, fix some comments in vo.c.
When full_redraw is set, we always need to take the draw_image path. If
it's not set, we can try VOCTRL_REDRAW_FRAME (and fallback to draw_image
if that fails).
Fixes#2184.
If the framedrop count happens to be incremented with
vo_increment_drop_count() during rendering, these increments were
counted twice, because these events also set in->dropped_frame.
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.
This caused issues with hardware decoding. The VOs by definition dictate
the lifetime of the hardware context, so no surface allocations must
survive the VO. Fixes assertions on exit with vdpau.
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.
For now, this is trivial (and actually redundant). The future display
sync code will make better use of it. The main point is that the new
internal API pretty much makes this transparent to the vo_opengl
interpolation code.
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 interpolation
code.
Note that the first frame (after playback start or seeking) will usually
not have any future frames (to make seeking fast). Near the end of the
file, the number of future frames will become lower as well.
Dmitrij D. Czarkoff