| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| |
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This is basically a hack for drivers which prevent the mpv DXVA2 decoder
glue from working if OpenGL is in fullscreen mode.
Since it doesn't add any "hard" new API to the client API, some of the
code would be required for a true zero-copy hw decoding pipeline, and
sine it isn't too much code after all, this is probably acceptable.
|
| |
|
|
|
| |
Since we still read-back (and don't have hard plans on changing this),
this doesn't have much of an advantage.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When seeking to a different position, and seeking takes long, the OSD
might get redrawn. This means that the VO will receive a request to
redraw an old frame using whatever the previous PTS was. This breaks the
interpolation logic: the old frame will be added to the queue, and then
the next frames (with lower PTS if you seeked backwards) are not drawn
as the logic assumes they're past frames.
Fix this by using the non-interpolation code path when redrawing after a
seek reset, and no "real" frame has been drawn yet.
It's a recent regression caused by the redrawing code simplification.
The old code simply sent a VOCTRL for redrawing the frame, and the VO
had to deal with retaining the old frame on its own.
This is a hack as in there's probably a better solution.
Fixes #2097.
|
| |
|
|
| |
bother vo_vdpau.c, which actually uses these times.
|
| | |
|
| | |
|
| |
|
|
| |
Use the newer internal GL backend API.
|
| | |
|
| |
|
|
| |
vo_xv.c is the only place where these things are used.
|
| |
|
|
|
|
|
|
| |
Less code, and avoids a black flash on start.
In theory it could happen that we map the window, and then don't have a
frame to draw - but mapping the window is done in the exact moment we
have a new frame to display.
|
| |
|
|
|
| |
The value 1 is useful in some contexts, but not such a good choice
otherwise.
|
| | |
|
| |
|
|
|
|
|
|
| |
This is not the most theoretically perfect solution, ideally we could
check to see if the frame in question has already been rendered
somewhere in the queue and then avoid re-rendering it, at the cost of a
few extra lines of code. But I don't think the performance trade-off is
dramatic enough here.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This should make interpolation work much better in general, although
there still might be some side effects for unusual framerates (eg. 35 Hz
or 48 Hz). Most of the common framerates are tested and working fine.
(24 Hz, 30 Hz, 60 Hz)
The new code doesn't have support for oversample yet, so it's been
removed (and will most likely be reimplemented in a cleaner way if
there's enough demand). I would recommend using something like robidoux
or mitchell instead of oversample, though - they're much
smoother for the common cases.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
If the black bars appeared on the left/right borders, panscan=1 didn't
make the video cover the whole screen.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some window managers let you change the fullscreen state of any window
using a key combination. For example, on XFWM you can use Alt+F11 and
on Compiz you can configure a key combination with the
"Extra WM actions" plugin.
With this change mpv will handle these fullscreen state changes. So, if
you enter into fullscreen mode using the WM's shortcut and then you use
mpv's fullscreen toggle, you will get back into window mode.
Merges PR #2081.
Signed-off-by: wm4 <wm4@nowhere>
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
It only causes additional maintenance work.
Even if you wanted to have a fallback, it's probably better to use
--vo=sdl or so.
|
| |
|
|
| |
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.
|
wm4
Niklas Haas
Eduardo Sánchez Muñoz
rr-
Avi Halachmi (:avih)