| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Who knows when this broke?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When using --hwdec=auto, about half of all systems will print:
"[vdpau] Error when calling vdp_device_create_x11: 1"
this happens because usually mpv will be linked against both vdpau and
vaapi libs, but the drivers are not necessarily available. Then trying
to load a driver will fail. This is a normal part of probing, but the
error messages were printed anyway. Silence them by explicitly
distinguishing probing.
This pretty much goes through all the layers. We actually consider
loading hw backends for vo_opengl always "auto probed", even if a hw
backend is explicitly requested. In this case vd_lavc will print a
warning message anyway (adjust this message a bit).
|
| |
|
|
|
|
|
|
|
| |
No particular reason, but it's still possible that it causes additional
corner cases, and it's not really needed to test this on wine (other
than testing fullscreen stuff, which should be done on a real Windows
anyway).
|
|
|
|
|
|
| |
No particular reason, but since we already have an internal variable,
it's better than using the option struct, which will be redone sooner
or later.
|
|
|
|
| |
Signed-off-by: wm4 <wm4@nowhere>
|
| |
|
| |
|
|
|
|
|
| |
When gl_shader_cache was destroyed, existing user shader entries leaked
the file path string.
|
|
|
|
|
|
|
|
|
|
|
|
| |
gl_video_set_options() does not acquire ownership of the opts parameter
or its contents. In case of vo_cmdline, opts will point to temporary
memory. This memory will be free'd at a later point, and p->opts will
point to free'd memory on the next reinitialization.
The fix is pretty ugly, but it's a quick bug fix. This can probably be
removed once VO sub-options are exposed as properties.
Fixes #2035.
|
|
|
|
|
|
|
| |
All vo_gl.c related code has been GPL+LGPL dual-licensed. The OSD code
is no exception and is also derived from vo_gl.c. Thus it should have
the same license (although I think technically speaking sub-licensing
it by removing one of the licenses is ok).
|
|
|
|
|
| |
This is (at least currently) redundant, but makes the code more
explicit. (This was discussed on IRC.)
|
|
|
|
|
|
|
|
|
| |
Commits 92b27be and f4ce99d removed high-fps logic to to a bug. That bug was
a missing parenthesis around everything after duration >= 0 && ... at the
removed code.
This patch restores the removed code, fixes the bug and then refactors the
code a bit.
|
|
|
|
|
|
|
| |
This reverts commit f1746741dee6000b7fd139e7a10f72aba0674b3b.
Together with the other revert, this fixes #2023 (the reason being
broken framedrop handling - it was dropping frames when it shouldn't).
|
|
|
|
| |
This reverts commit ffcad1a72b9a3bf5a7ac5ddcbfa71ec19b6faf9b.
|
|
|
|
|
|
|
|
| |
read_output_surface() could fail and return NULL.
Also, make sure we don't set the image to a size larger than the
allocated size. Normally this shouldn't happen, but in theory it could
in corner cases; this is for robustness.
|
|
|
|
|
|
| |
We can't do much in this case, but at least we can not call the vdpau
API functions with too large sizes. Apparently the API considers this
undefined behavior, and random stuff might happen.
|
|
|
|
|
|
|
| |
The previous code was not wrong, but I'd claim this makes the code more
robust. If a situation could happen in which the passed surface size is
incorrect, we could have passed a too small image, and
VdpOutputSurfaceGetBitsNative could have randomly overwritten memory.
|
|
|
|
| |
Why should I be required to type so much?
|
|
|
|
|
| |
This is because it turns out the regular robidoux is pretty useful for
tscale etc.
|
|
|
|
|
|
|
|
|
| |
Check the maximum size of video surfaces, and refuse initialization if
the video is too large for them.
Maybe we could do something more sophisticated, like inserting a
software scaler. On the other hand, this would have a very questionable
benefit, as it would be guaranteed to be too slow.
|
|
|
|
|
|
| |
Reconfiguring with the same video size should never cause the window to
resize back to the video size (if the user changed its size). This was
broken and it resized anyway.
|
| |
|
|
|
|
|
| |
When running on Wayland, and vo_opengl is not available or rejected for
some reason, it's better to use vo_wayland instead of e.g. vo_x11.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
If gl_hwdec_driver.map_image fails, all textures will be set to 0. This
in turn makes pass_prepare_src_tex() skip generation of the texture
uniforms, which leads to a shader compilation error, as e.g. texture0 is
not defined but expected to exist and accessed.
Set the textures to an invalid non-0 ID instead. OpenGL can deal with
it.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Always configure the vdpau mixer based on the current surface sent to
it. Before this, we just hardcoded the chroma type, and the surface size
was essentially a guess.
Calling VdpVideoSurfaceGetParameters() on every surface is a bit
suspicious, but it appears it's a cheap function (just requiring some
locks and a table lookup). This way we avoid creating another
complicated mechanism to carry around the actual surface parameters
with a mp_image/AVFrame.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
As suggested by haasn. The term "full range" makes it sound like it has
to do with TV vs. PC range, which is not the case at all.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
They're completely orthogonal concepts, merged in the past due to
convenience and ease of implementing it in the old #ifdef hell renderer.
Especially after the CMS stuff was generalized by 634b4a, this was a
trivial change to implement and also means color management will be much
higher quality when enabled with vo=opengl (which had quantization
issues in the past due to the 8 bit FBO format and upscaling), since it
can be done in a single pass now.
|
|
|
|
| |
Signed-off-by: wm4 <wm4@nowhere>
|
| |
|
|
|
| |
Makes ricers happy.
|
| |
|
|
|
|
| |
The current code just segfaults.
|
|
|
|
|
|
|
|
| |
A rather dumb hack to copy the problematic rectangle textures (mandated
by VDA) into 2D ones.
(This isn't done yet for OpenGL 3.0+. We need to make sure the
performance isn't reduced too much by it.)
|
|
|
|
|
| |
vo_direct3d still seems to require this (tested on Windows 8.1 with
Intel graphics). Do it in vo_direct3d instead of messing with all VOs.
|
|
|
|
| |
Completely useless.
|
| |
|
|
|
|
|
|
| |
It sometimes happens on exit, and it's probably a bad idea. If the
process hangs on exit (possibly due to stupid hardcoded timeouts it's
doing), mpv will also hang now, unfortunately.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It appears some WMs have a problem with out method of setting initial
fullscreen mode. We assume that if the window's _NET_WM_STATE includes
_NET_WM_STATE_FULLSCREEN before mapping the window, the WM will show it
as fullscreen at mapped. EWMH doesn't say anything that this should
work, although one could argue that it's implied.
In any case, since it's not standard behavior without at least some
doubt, it's probably a good idea to try the "old" method as well.
Fortunately, it should be idempotent.
See #1937, #1920.
|
|
|
|
|
| |
pts can never be 0 or negative. If there is no frame, some code below
catches this case by checking hasframe.
|
| |
|
|
|
|
|
| |
The requested version field didn't make much sense anymore, and was even
partially ignored by some backends.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
An attempt to get rid of the weird mix of callbacks that take either
struct vo or MPGLCopntext as parameter. This is not perfect, and the
API will probably change a bit until all other code is ported to it.
the main question is how to separate struct vo completely from the
windowing code, which actually needs vo for very little.
In the end, the legacy callbacks will be dropped.
|
|
|
|
|
|
|
|
| |
Instead of having separate backends, make use of GLES a flag. This
reduces the number of backends and the resulting annoyances.
Also, nobody cares about using GLES, so there's no backward
compatibility either.
|
|
|
|
|
| |
The final goal is to remove the nonsense separation between the 3
backend init/vo_init/GL context creation calls.
|
|
|
|
| |
Awkward stuff not needed anymore.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this change, Cocoa state was accessed from both the VO and the
Cocoa main thread. This was probably not a good idea. There was some
locking as well as implicit synchronization using the dispatch
mechanism, but it wasn't watertight.
Change this completely. Now Cocoa things are always accessed from the
main thread only. The old mutex falls away, as well as the
vo_cocoa_set_current_context() function, which implicitly used the lock
to coordinate VO accesses. With the new code, the VO thread generally
has to wait for the main thread, while the main thread never waits for
the VO and rarely accesses it. Fortunately, this is rather straight
forward, and most of this is achieved by making vo_cocoa_control() run
on the main thread. The logic of the code does generally not change.
Some aspects are trickier. Apparently we can't access the
NSOpenGLContext from the VO thread, because this object is not thread-
safe. We use some CGLContextObj functions instead, such as for making
the context current and swapping the buffers.
|
| |
|
|
|
|
|
|
|
|
|
| |
The hardware always decodes to nv12 so using this image format causes less cpu
usage than uyvy (which we are currently using, since Apple examples and other
free software use that). The reduction in cpu usage can add up to quite a bit,
especially for 4k or high fps video.
This needs an accompaning commit in libavcodec.
|
|
|
|
|
|
| |
Some code always calls vo_event(), even with event==0, which leads to
immediate wakeup, which in turn causes the function to be called again.
This would burn CPU, which was especially noticeable when paused.
|
|
|
|
|
|
|
|
|
|
|
| |
Interrupt video timing. This means the Cocoa event loop does not have
to up to 2 video frame durations until redrawing the frame finally has
finished.
We abuse the VO event flags for this. Eventually this should use
wait_vo() or so in the video timing wait function, but for now the
interaction this would require with the code of other VOs/backends
would cause too much of a mess.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of requiring a complicated mechanism to share the entire OpenGL
and renderer state between VO and Cocoa thread just to do the redrawing
during live-resize on the Cocoa thread, let the Cocoa thread wait on the
VO thread. This wil allow some major simplifications and cleanups in the
future.
One problem with this is that it can enter a deadlock whenever the VO
tries to sync with the Cocoa thread. To deal with this, the Cocoa thread
waits with a timeout. This can probably be improved later, though in
general this situation can always happen, unless the Cocoa thread waits
in a reentrant way.
Some other details aren't completely clean either. For example,
pending_events should be accessed atomically. This will also be fixed
later.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Will be used to make video waiting interruptible with Cocoa (see the
following commit).
One worry was that this could cause hangs if the system clock jumps
backwards. Normally we don't support such behavior, because it's
almost impossible to handle it reasonably. E.g. we would have to
change the default clock type for condition variables, which in turn
would require a custom function for creating condition variables,
or so. If the OS even supports different clocks.
But it turns out that this is no issue, because other events seem
to wakeup the wait call anyway, and mpv internal absolute times use
a monotonic clock.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This uses the OpenGL frame interpolation code, which before could be
used by vo_opengl only.
Some effort was made to make it behave like vo_opengl, for the better or
the worse. As a consequence, there is a minor duplication of code and
mechanism. Hopefully this can all be wiped as soon as the VO frame
queue/timing mechanism is cleaned up.
This also attempts to use mpv_opengl_cb_report_flip() (as called by the
API user) to determine the vsync interval. This might need refinement as
well.
(In general, we simply expect the API user to work in vsync-blocking
manner.)
|
|
|
|
|
|
|
|
|
| |
(I have no idea why there are different modes.)
Instead of risking to drop frames too early, give it some margin. Since
there are situations this could deadlock, wait with a timeout. This can
happen if e.g. the API user is refusing to render anything, or if
uninitialization is happening.
|
|
|
|
| |
Quite an oversight.
|
|
|
|
|
|
|
| |
Gives the VOs more flexibility.
gl_video.c already ignores the timing info if no interpolation is
active, so this requires no further changes.
|
|
|
|
|
|
|
| |
There is not much of a reason to have these wrappers around. Use POSIX
standard functions directly, and use a separate utility function to take
care of the timespec calculations. (Course POSIX for using this weird
format for time values.)
|
| |
|
|
|
|
|
| |
The first one (for VOCTRL_GET_DISPLAY_FPS) could have led to undefined
behavior if the FPS was unknown. The second is for general symmetry.
|
| |
|
|
|
|
|
| |
Instead of bstr. Most callers of this function do not need bstr. The
bstr version of this function is now mp_path_join_bstr().
|
|
|
|
|
|
|
|
|
| |
Now among other things panscan can be changed during playback.
Unfortunately, it flickers. The issue is that reconfig() clears the
framebuffer. Removing the clearing shows that the "unused" parts of
the picture are not cleared - even though OSD could render there. As
such, this is a separate issue.
|
|
|