Seems to work with GtkSocket and passing the gtk_socket_get_id() value
via "wid" option to mpv.
One caveat is that using <tab> to move input focus from mpv to GTK does
not work. It seems we would have to interpret <tab> ourselves in this
case. I'm not sure if we really should do this - it would probably
require emulating some other typical conventions too. I'm not sure if an
embedder could do something about this on the toolkit level, but in
theory it would be possible, so leave it as is for now.
Don't use vo_control() for sending VOCTRL_RESET when starting a seek.
This means vo_seek_reset() won't wait until the VO actually processed
VOCTRL_RESET. It happens asynchronously instead.
The impact of this change should be minimal, unless the VO is somehow
too busy (like blocking on vsync).
This avoids issues when upscaling directly in linear light, and is the
recommended way to upscale images according to imagemagick.
The default slope of 6.5 offers a reasonable compromise between
ringing artifacts eliminated and ringing artifacts introduced by
sigmoid-upscaling. Same goes for the default center of 0.75.
The previous implementation of opengl-cb kept only latest flipped frame.
This can cause massive frame drops because rendering is done asynchronously
and only the latest frame can be rendered.
This commit introduces frame queue and releated options to opengl-cb.
frame-queue-size: the maximum size of frame queue (1-100, default: 1)
frame-drop-mode: behavior when frame queue is full (pop, clear, default: pop)
The frame queue holds delayed frames and drops frames if the frame queue is
overflowed with next method:
'pop' mode: drops all the oldest frames overflown.
'clear' mode: drops all frames in queue and clear it.
With default options(frame-queue-size=1:frame-drop-mode=pop),
opengl-cb behaves in the same way as previous implementation effectively.
For frame-queue-size > 1, opengl-cb tries to calls update() without waiting
next flip_page() in order to consume queued frames.
Signed-off-by: wm4 <wm4@nowhere>
vo_opengl was crashing since f811348d because it passed NULL for the
events parameter to vo_control. Normally the parameter should not be
NULL, so add a hack to account for this. In particular, we should
handle the events that are returned. For the call in preinit() we
skip this, but it most likely has no meaning anyway, because in this
stage no window is visible yet.
This was always supposed to work.
Just add the option declaration. Normally I'm not a fan of duplicating
such things, but in this case it's (still) harmless.
This affects OSX, where memory profiles are updated e.g. on fullscreen
switches. The profile most likely doesn't change, but the LUT will
be generated and reloaded anyway.
Somewhat of a regression from commit f811348.
Fixes#1439.
If icc-path is set, but the thing is replaced with a memory profile,
then p->icc_path would point to deallocated memory.
Also, the NULL checks are unnecessary.
glXGetProcAddress() is outdated, and as far as I know doesn't give all
the guarantees the "new" ARB function gives.
Probably doesn't matter too much, because until now it always appeared
to work. On the other hand, since this function is (bogusly) used only
on the gl3 code path, it could have happened that users hit this, and
just reverted to vo_opengl_old instead.
When the given mp_image_params does not match with that of gl_video,
gl_video_config() always calls uninit_video() but calls init_video()
only if valid format is given.
Since uninit_video() does not change image_params of gl_video,
when the same params as the previous one is given to gl_video_config()
after gl_video is unitialized with invalid format, gl_video_config()
never calls init_video().
To prevent this, invalidate image_params of gl_video in uninit_video().
Previously we just forced loading a profile from file, but that has poor
integration for querying the OS / display server for an ICC profile, and
generating profiles on the fly (which we might use in the future for creating
preset 3dluts).
Also changed the previous icc-profile-auto code to use this mechanism, and
moved gl_lcms to be an opaque type with state instead of just providing pure
functions.
This makes vo_opengl_cb respond to controls like "gamma" and
"brightness". The commit includes an awkward refactor for vo_opengl to
make it easier for vo_opengl_cb.
One problem is a logical race condition. The set of supported controls
depends on the pixelformat, which in turn is set by reconfig(). But the
actual reconfig() call (on the renderer) happens asynchronously on the
renderer thread. At the time it happens, the player most likely already
tried to set some controls for command line options (see init_vo() in
video.c). So setting this command line options will fail most of the
time, though it could randomly succeed. This can't be fixed directly,
because the player can't wait on the renderer thread, because the
renderer thread might already wait on the player.
Although the line count increases, this is better for making sure
everything is handled consistently for all users of the mp_csp_params
stuff.
This also makes sure mp_csp_params is always initialized with
MP_CSP_PARAMS_DEFAULTS (for consistency).
Returning the property before the window is mapped could lead to
confusing behavior, and in particular strange differences between
vo_vdpau and vo_opengl. (vo_opengl creates the window right at the
start, while vdpau waits until the first reconfigure event.) It might
even be possible that for vo_opengl random results were returned,
because the hidden window can have different placement than the actual,
final one on initial video reconfig.
Fix this by returning the property only if the window is considered
mapped. command.c handles this case specifically, and makes the property
unavailable, instead of returning an empty list.
There are currently 568 pixel formats (actually fewer, but the namespace
is this big), and for each format elaborate synchronization was done to
call it synchronously on the VO. This is completely unnecessary, and we
can do with just a single call.
While there's no actual need to get rid of these, I want to make sure
nobody actually needs this stuff, and removing it is the best way to
get to know this. We still can revert this commit if it turns out there
is a significant need for this stuff.
The final goal is removing vo_opengl_old entirely. Add a warning, which
basically announces this intention.
This is only needed for switching video track with `_`, since Cocoa
automatically handles cleaning up the application's presentation options when
quitting the process.
Fixes#1399
The way we use rectangle textures (required by VDA for no reason) works
onl in OpenGL 3.0 or higher. Below that, the shader will fail to
compile. We could add support for older OpenGL versions, but that would
be a major pain.
This normally doesn't matter; mpv itself always creates OpenGL 3.2
contexts on OSX. But it could matter if a client API user uses
vo_opengl_cb, and gives it a 2.1 context (which OSX also allows you to
create).
Until now, calling mpv_opengl_cb_uninit_gl() at a "bad moment" could
make the whole thing to explode. The API user was asked to avoid such
situations by calling it only in "good moments". But this was probably a
bit too subtle and could easily be overlooked.
Integrate the approach the qml example uses directly into the
implementation. If the OpenGL context is to be unitialized, forcefully
disable video, and block until this is done.
The details of the non-linear transformation from/to BT.2020's constant
luminance system don't really make sense with any other gamma curve,
since changing the gamma curve completely breaks the chroma channels.
vo_opengl was originally written against OpenGL 3 core, and it seems
GPUs/drivers supporting this are mostly sane. Later, it was made to work
with OpenGL 2.1 too. Lately we removed the requirement for RG textures,
and look, someone reported a problem with "lesser" Intel GPUs.
This commit does the same in vo_opengl what was added to vo_opengl_old a
long time ago.
Fixes#1383.
Using them reduces state change, since now at least vo_opengl_cb has to
setup/break the vertex array bindings on every frame if no VAOs are
available.
This reverts the VAO related change in commit f64665e7.
Originally, this code was written to have full control over the OpenGL
state, rather than having to cooperate with unknown components by being
embeded like vo_opengl_cb is meant to be. As a consequence, it was
thought to be ok to setup a global binding (if the context is below
OpenGL 3.0, which guarantees VAOs).
This could break badly. Fix it by setting up and breaking the bindings
on entry/exit.
GL_ARB_debug_output provides a logging callback, which can be used to
diagnose problems etc. in case the driver supports it. It's enabled only
if the vo_opengl "debug" suboption is set.
Now it accepts the same renderer arguments as vo_opengl. This also
disables debug checks by default, and reverts the background color
override. Both can now be controlled by the host application.
