The playback start logic explicitly waits until the first frame has been
displayed. Usually this will introduce a wait of 1 vsync. For normal
playback this doesn't matter, but with respect to low latency needs,
this only leads to additional data getting queued up in the demuxer or
network buffers.
Another thing is that the timing logic decodes 1 frame ahead (= 1 frame
extra latency) to determine the exact duration of a frame.
To be fair, there doesn't really seem to be a hard reason why this is
needed. With the current code, enabling the option does lead to A/V
desync sometimes (if the demuxer FPS is too inaccurate), and also frame
drops at playback start in some situations. But this all seems to be
avoidable, if the timing logic were to be rewritten completely, which
should probably happen in the future. Thus the new option comes with the
warning that it can be removed any time. This is also why the option has
"hack" in the name.
Well I guess it doesn't help that much.
Also add some stuff that might help to the manpage.
The fundamental problem with some "live" sources (e.g. x11grab) is
actually that the player gets behind initially, and never thinks it has
to catch up. This is also why --untimed can help.
It's a mess: mp3 files have user tags as global metadata (because the
id3v2 tag is global and there is only 1 stream), while OGG files have it
per-track (because it's per-stream on the lowest level). mpv needs to
try to make something nice out of the mess.
It did so by trying to detect audio-only OGG files, and then copying the
per-stream metadata to the global metadata. Make the heuristic for
detecting this slightly more clever, so it works for files with extra,
unrelated streams, like the awful libavformat cover art hack.
Fixes#5577.
Useful for libavfilter. Somewhat risky, because we can't ensure the
consistency of the unknown side data (but this is a general problem with
side data, and libavfilter filters will usually get it wrong too _if_
there are conflict cases).
Fixes#5569.
We must not create new references herem because mp_image_new_ref() is
called later, and actually creates new references (including doing
actual error checking). Blame C, not me.
It appears some (or all) mkv files with EAC3 are muxed in a way that
breaks FFmpeg's spdifenc. I suspect it's because either dependent
substream packets are localted in their own packets, or the reverse. Or
possibly this is case where the muxer did not respect packet boundaries
at all. Enabling the EAC3 parser seems to fix this anyway, because why
waste your precious time on retarded Dolby bullshit technology? (Which
idiot came up with this shitty substream garbage?)
Observed with dolby_digital_plus_channel_check_lossless-DWEU.mkv.
Fixes#5578.
I think DASH playback tends to work much better with FFmpeg's DASH
demuxer, which requires libxml2.
For nvdec, FFmpeg git master now requires the external nvidia headers,
since the builtin ones were removed.
the NSWindowButton enum was moved to be a member of NSWindow and renamed
to ButtonType in SDK 10.13. apparently that wasn't documented anywhere.
not even in the SDK changes Document and the official Documentations
makes it look like it was always like this. the old NSWindowButton enum
though is still around on SDK 10.13 or at least got a typealias. so we
will just use that.
The purpose of the new API is to make it useable with other APIs than
OpenGL, especially D3D11 and vulkan. In theory it's now possible to
support other vo_gpu backends, as well as backends that don't use the
vo_gpu code at all.
This also aims to get rid of the dumb mpv_get_sub_api() function. The
life cycle of the new mpv_render_context is a bit different from
mpv_opengl_cb_context, and you explicitly create/destroy the new
context, instead of calling init/uninit on an object returned by
mpv_get_sub_api().
In other to make the render API generic, it's annoyingly EGL style, and
requires you to pass in API-specific objects to generic functions. This
is to avoid explicit objects like the internal ra API has, because that
sounds more complicated and annoying for an API that's supposed to never
change.
The opengl_cb API will continue to exist for a bit longer, but
internally there are already a few tradeoffs, like reduced
thread-safety.
Mostly untested. Seems to work fine with mpc-qt.
The stdatomic emulation adds "_" to each variable used inside the
macros, to avoid that compilers print -Wshadow warnings for identifiers
that are also used in surrounding code. Do this more consistently,
because new warnings have been showing up.
when resizing async it's possible that the layer, and the underlying gl
surface, is stretched on an aspect ratio change. to prevent that we do
an atomic resize (resize and draw at the same time). usually max one
unique frame should be dropped but it's possible, depending on the
performance, that more are dropped.
the title bar is now within the window bounds instead of outside. same
as QuickTime Player. it supports several standard styles, two dark and
two light ones. additionally we have properly rounded corners now and
the borderless window also has the proper window shadow.
Also make the earliest supported macOS version 10.10.
Fixes#4789, #3944
By blocking the VT switcher signal in the VO thread we get less races
and other oddities.
This gets rid of tearing (at least for me) when VT switching with
--gpu-context=drm.
crtc_setup gets called on VT reacquire as well as during normal setup. When
called during VT reacquire p->front_buf might not be 0, so the maths was wrong,
and could cause array OOB errors. Use mathematically correct (for negative
numbers) modulo to always pick the farthest away buffer (should work
even for larger values of BUF_COUNT).
The VT switcher was being set up, but it was being neither polled nor
interrupted.
Insert wait_events and wakeup functions based on those from vo_drm,
and add return early in drm_egl_swap_buffers if p->active isn't set.
This should get basic VT switching working, however there will likely
still be some random glitches. Switching between mpv and X11/weston is
unlikely to work satisfactorily until we can solve the problems with
drmSetMaster and drmDropMaster.
This introduces the option --drm-format (currently used only by
context_drm_egl, vo_drm implementation is pending) which allows you to
pick between a xrgb8888 or a xrgb2101010 visual for --gpu-context=drm.
Requires a recent mesa (18.0.0_rc4 or later) to work.
This also fixes a bug when using --gpu-context=drm on a 30bpp-enabled
mesa (allow_rgb10_configs set to true). Previously it would've set up
an XRGB8888 format at the DRM/GBM level, while a 30bpp EGLConfig would
be picked, resulting in a garbled image.
even though the fullscreen animation has a shorter duration than the
system wide animation (space sliding effect) there are still cases where
it takes longer, eg performance issues (especially on init). furthermore
the final size of the animation is usually different than the actual
fullscreen size because of spect ratio differences. the actual resize to
fullscreen is done automatically by cocoa itself when the actual
transition to fullscreen happens (system event). so it could happen that
the last animation resize happened after the actual resize to fullscreen
leading to a wrongly sized frame after entering fullscreen. to prevent
this we cancel the animation when entering fullscreen, we always set the
proper frame size when in fullscreen and discard any other frame sizes,
and to prevent some performance problems on init we push entering
fullscreen to the end of the main queue to execute it when most of the
init routines are done.
Fixes#5525
on live resize, eg async resize, the layer's bounds size is not in sync
with the actual surface size. this led to a wrongly sized frame and a
perceived flicker. get and use the actual surface size instead.
Mobius isn't well-defined for sig_peak <= 1.0. We can solve this by just
soft-clamping sig_peak to 1.0. Although, in this case, we can just skip
tone mapping altogether since the limit of mobius as sig_peak -> 1.0 is
just a linear function.
Based on testing with real-world non-HDR BT.2020 clips, clipping the
color space looks better than attempting to gamut map using a tone
mapping shader that's (by now) optimized for HDR content.
If anything, we'd have to develop a separate gamut mapping shader that
works in LCh space.
Do this because retrying reading on higher levels (like the demuxer)
usually causes tons of problems. A hack like this is simpler and could
allow to remove some of the higher level retry behavior.
This works by trying to detect whether the file is appended. If we reach
EOF, check if the file size changed compared to the initial value. If it
did, it means the file was appended at least once, and we set the
p->appending flag. If that flag is set, we simply retry reading more
data every time we encounter EOF. The only way to do this is polling,
and we poll for at most 10 times, after waiting for 200ms every time.
Just bail out immediately (and disable audio) if format probing has no
result, instead of doing nothing and then apparently freezing.
This can happen with bogus filters, cases where the first audio frame is
essentially dropped by filters (can happen with large resampling
factors), and if the audio track contains no packets at all, or all
packets fail to decode.
in certain circumstances the returned fbo for drawing is 0, but that
fbo is solely used internally by the CAOpenGLLayer for its drawing and
should never be used. in that case we fallback to 1 or the last used fbo
instead if it was not 0.
Fixes#5546
When pixels are non-square, the appropriate value of vo->monitor_par is
necessary to determine the destination rectangle, which in turn tells
how to scale the video along the x and y axis. Before this commit, the
drm driver only used --monitorpixelaspect. For example, to play a video
with the right aspect on a 4:3 screen and 640:400 pixels,
--monitorpixelaspect=5:6 had to be given.
With this commit, vo->monitor_par is determined from the size of the
screen in pixels and the --monitoraspect parameter. The latter is
usually easier to determine than --monitorpixelaspect, since it is
simply the proportion between the width and the height of the screen,
in most cases 16:9 or 4:3. If --monitoraspect is not given,
--monitorpixelaspect is used if given, otherwise pixel aspect is
assumed 1:1.
This solves a number of problems simultaneously:
1. When outputting HLG, this allows tuning the OOTF based on the display
characteristics.
2. When outputting PQ or other HDR curves, this allows soft-limiting the
output brightness using the tone mapping algorithm.
3. When outputting SDR, this allows HDR-in-SDR style output, by
controlling the output brightness directly.
Closes#5521
The HLG OOTF is defined as a one-parameter family of OOTFs depending on
the display's peak luminance. With the preceding change to OOTF scale
and handling, we no longer have any issues with outputting values in
whatever signal range we need.
So as a result, it's easy for us to support a tunable OOTF which may
(drastically) alter the display brightness. In fact, this is also the
only correct way to do it, because the HLG appearance depends strongly
on the OOTF configuration. For the OOTF, we consult the mastering
display's tagging (via src.sig_peak). For the inverse OOTF, we consult
the output display's target peak.
The primary need for this change is the fact that the OOTF was
incorrectly scaled, due to the fact that the application of the OOTF can
itself change the required normalization peak. (Plus, an oversight in
pass_inverse_ootf meant we forgot to normalize at the end of it)
The linearize/delinearize functions still normalize the scale since it's
used in a number of places throughout gpu/video.c, but the color
management function now converts to absolute scale right away, instead
of in an awkward way inside the tone mapping branch. The OOTF functions
now work in absolute scale only.
In addition, minor changes have been made to the way normalization is
handled for tone mapping - we now divide out the dst_peak *after* peak
detection, in order to make the scale of the peak detection buffer
consistent even if the dst_peak were to (hypothetically) change
mid-stream. In theory, we could also do this for desaturation, but doing
the desaturation before tone mapping has the advantage of preserving
much more brightness than the other way around - and even mid-stream
changes are not that drastic here.
Finally, some preparation work has been done for allowing the user to
customize the `dst.sig_peak` in the future.
