With the advent of actual HDR devices, my real measured ICC profile has
an "infinite" contrast, since the display is completely off on pure
black inputs. 100k:1 might not be enough, so let's just bump it up to
1m:1 to be safe.
Also, improve the logging in the case that the detected contrast is too
high by default.
This was there originally to detect too-old versions of ffmpeg. We now
only support >= 4.0, so it's not relevant. We just need the dependencies
to be present.
First fix a memory leak when skipping cursor planes by inverting the
check and putting everything, but the free, in the body.
Then fix a missed drmModeFreePlane by simply copying the fields of the
drmModePlane we are interested in and freeing the drmModePlane struct
early.
Fixes `--ytdl-format="dash-fastly_skyfire-video-363357330+dash-fastly_skyfire_sep-audio-363357330" https://vimeo.com/108650530`
This happened because the video track also had audio available and after
adding it expecting an audio-only track, there were no more tracks with video.
Could make it behave differently (and leak memory) in certain cases.
Basically, m_option_parse() randomly returns 0 or 1, but most time 1,
with the difference due to legacy reasons that don't matter anymore.
The "if (prop.name)" check is redundant, because an assert above it
implies that it never can be NULL.
Deduplicate some code for initializing the "prop" variable.
This gets rid of run_command() and its big switch statement, which was
an idiotically big function of almost 1000 lines.
The switch is replaced with a callback per command, and each command is
now implemented in its own function. Command IDs are not needed anymore,
so the mp_command_type enum disappears.
There should be no functional changes, but since this refactors 64
commands, regressions are possible.
The handler() parameter is void*, because in theory the input code is
supposed to be independent of the player core code. For example, you
should be able to reuse the command parser code for some other part of
mpv. In practice, the variable containing command list is defined in the
player core anyway, so you could say this doesn't work. But I'm still
trying to hold onto this idea, so I went with void*.
The plan is to remove the command ID enum. This will happen by replacing
the big switch statement in command.c with dispatching to per-command
callbacks. As preparation, remove uses of the command IDs outside of the
actual dispatching mechanism.
Also remove some instances of checking cmd->def for NULL. We now require
this always to be set.
These are old MPlayer commands that were redundant since 2007 or so. In
2013, mpv explicitly deprecated them (actually removed them, but left
this wrapper, which translated them to modern commands). The list was
not extended since 2013, and mpv always warned on the terminal when a
legacy command was used. So it's time to remove it.
Until recently, ao_lavc and vo_lavc started encoding whenever the core
happened to send them data. Since audio and video are not initialized at
the same time, and the muxer was not necessarily opened when the first
encoder started to produce data, the resulting packets were put into a
queue. As soon as the muxer was opened, the queue was flushed.
Change this to make the core wait with sending data until all encoders
are initialized. This has the advantage that we don't need to queue up
the packets.
The user won't want to have those in the video (I think). The core can
sporadically issue redraws, which is what you want for actual playback,
but not in encode mode. vo_lavc can explicitly detect those and skip
them. It only requires switching to a more advanced internal VO API.
The comments in vo.h are because vo_lavc draws to one of the images in
order to render OSD. This is OK, but might come as a surprise to whoever
calls draw_frame, so document it. (Current callers are OK with it.)
The video timing code could just decide that EOF was reached before it
was displayed. This is not really a problem for normal playback (if you
use something like --keep-open it'd show the last frame anyway,
otherwise it'd at best flash it on screen before destroying the window).
But in encode mode, it really matters, and makes the difference between
having one frame more or less in the output file.
Fix this by waiting for the VO before starting the real EOF.
vo_is_ready_for_frame() is normally used to determine when the VO frame
queue has enough space to send a new frame. Since the VO frame queue is
currently at most 1 frame, it being signaled means the remaining frame
was consumed and thus sent to the VO driver. If it returns false, it
will wake up the playloop as soon as the state changes.
I also considered using vo_still_displaying(), but it's not reliable,
because it checks the realtime of the frame end display time.
While I'm not sure whether it really works, at least it writes the pass1
log correctly now.
How 2-pass stat output is supposed to interact with the new decode API
is rather fishy. ffmpeg.c does the same, and before this change, the
log was not written on EOF (when at least libvpx actually outputs its
stats).
With the internal change from stringlist to keyvaluelist, these
sub-options stop working. I don't really care enough to bring them
back. (Order doesn't matter, -del always seemed annoying.)
Inspired by kmscube, first try to pick the Encoder and CRTC already
associated with the selected Connector, if any. Otherwise try to find
the first matching encoder & CRTC like before.
The previous behavior had problems when using atomic
modesetting (crtc_setup_atomic) when we picked an Encoder & CRTC that
was currently being used by the fbcon together with another Encoder.
drmModeSetCrtc was able to "steal" the CRTC in this case, but using
atomic modesetting we do not seem to get this behavior automatically.
This should also improve behavior somewhat when run on a multi screen
setup with regards to deinit and VT switching (still sometimes you end
up with a blank screen where you previously had a cloned display of
your fbcon)
Add some properties which where forgotten in crtc_setup_atomic.
In both change to not use DRM_MODE_PAGE_FLIP_EVENT | DRM_MODE_ATOMIC_NONBLOCK
flags. This should make it more similar to the drmSetCrtc which it aims to
replace (take effect directly, and blocking call). This also saves us the
trouble of having to set up a poll to wait for pageflip, which would've been
neccesary with DRM_MODE_PAGE_FLIP_EVENT, in both crtc_setup_atomic and
crtc_release_atomic.
This patch will make sure that the video plane is hidden when unused.
When using high resolution modes, typically UHD, and embedding mpv,
having the video plane sitting in the back when you don't play any video
is eating a lot of memory bandwidth for compositing.
That patch makes sure that the video layer is just disabled before and
after playback.
This commit allows to add atomic modesetting when using the atomic renderer.
This is actually needed when using and osd with a smaller size than screen resolution.
It will also make the drm atomic path more consistent
We are currently using primary / overlay planes drm objects, assuming that primary plane is osd and overlay plane is video.
This commit is doing two things :
- replace the primary / overlay planes members with osd and video planes member without the assumption
- Add two more options to determine which one of the primary / overlay is associated to osd / video.
- It will default osd to overlay and video to primary if unspecified
This patch adds
- DRM connector object to atomic context.
- fd property to the drm atomic object as well as a method to read blob type properties.
This allows to ensure that the proper connector is picked up, especially when specifying it
from the commandline, and also allows to make sure we're using the right one when embedding
with interop into an application.
That new API was introduced and allows to have several native resources.
Thisuses that mechanisma for drm resources rather than the deprecated
opengl-cb structs.
This patch therefore add two structs that can be used with the drm atomic interop.
- mpv_opengl_drm_params : which will hold all the drm handles
- mpv_opengl_drm_osd_size : which will hold osd layer size
This commit adds a drm-osd-size=WxH parameter to commandline which
allows to define the OSD plane dimension. OSD can be upscaled to
screen resolution when having OSD at video resolution is too heavy.
This is especially useful for UHD modes on embedded devices where
the GPU cannot handle UHD modes at a decent framerate.
It was documented for --screenshot-template, but apparently never
implemented.
This value is not explicitly rounded, other than for printf() %f default
formatting (which rounds to 6 digits).
This means that a time of 4.5678 is displayed as "00:00:04.568" when the
format string is "%H:%M:%S.%T". Likewise, 59.99999 will be displayed as
"00:01:00.000". Before this change, the sub-ms times were just
truncated.
Requested by TheAMM.
Define a hard-coded value for gl_NumWorkGroups if it is not available.
This adds an additional requirement of needing a shader recompile for
all window size changes.
This was considered a worthwhile compromise as currently f.ex. d3d11
completely lacked any peak computation - this is a major quality of
life upgrade.
