| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ffmpeg cuda wrappers need more than 1 packet for determining whether
hw decoding will work. So do something complicated and keep up to 32
packets when trying to do hw decoding, and replay the packets on the
software decoder if it doesn't work.
This code was written in a delirious state, testing for regressions and
determining whether this is worth the trouble will follow later. All mpv
git users are alpha testers as of this moment.
Fixes #3914.
|
|
|
|
| |
Basically change everything. Why does the code get larger? No idea.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Cover art handling is a disgusting hack that causes a mess in all
components. And this will stay this way. This is the Xth time I've
changed cover art handling, and that will probably also continue.
But change the code such that cover art is injected into the demux
packet stream, instead of having an explicit special case it in the
decoder glue code. (This is somewhat more similar to the cover art hack
in libavformat.)
To avoid that the over art picture is decoded again on each seek, we
need some additional "caching" in player/video.c. Decoding it after each
seek would work as well, but since cover art pictures can be pretty
huge, it's probably ok to invest some lines of code into caching it.
One weird thing is that the cover art packet will remain queued after
seeks, but that is probably not an issue.
In exchange, we can drop the dec_video.c code, which is pretty
convenient for one of the following commits. This code duplicates a
bunch of lower-level decode calls and does icky messing with this weird
state stuff, so I'm glad it goes away.
|
|
|
|
| |
They're already pulled in by drm_common.h.
|
|
|
|
|
|
|
| |
I'm not sure what systems have <sys/poll.h> (maybe there are historical
reasons why some would), but POSIX defines <poll.h>. Although this code
is full of highly OS specific calls (like ioctl()), there's no reason
not to use the more standard include path.
|
|
|
|
| |
Cosmetic change.
|
|
|
|
|
|
|
|
|
|
|
| |
This is available since the first commit after libva 0.39.4. Since the
version wasn't bumped since, we just check some random other symbol that
was added since (I'd rather not add a configure check).
The libva message callback repeats the endlessly repeated API mistakes
of libraries using global message callback handlers. But it's the only
way to shut up libva's dumb messages to stderr, so add something
complicated and dumb to workaround libva's stupidity.
|
|
|
|
|
|
|
|
| |
Just some minor refactoring within va_initialize() as preparation for
the next commit.
Also, do not call vaTerminate(display) on failures. All callers already
do this, so this would have led to a double-free.
|
|
|
|
|
|
|
|
| |
vo_wayland_wait_events() is going to return when its time to swap the
buffers anyway, calling request_frame() before makes no sense.
Fixes the constant high CPU usage by the compositor when mpv is paused
and the window is in view.
|
|
|
|
|
|
|
|
| |
According to MSDN, in WM_SYSCOMMAND messages, the four low-order
bits of the wParam parameter are used internally by the system.
To obtain the correct result when testing the value of wParam,
an application must combine the value 0xFFF0 with the wParam
value by using the bitwise AND operator.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Looks quite like a bug. If you have a filter chain with only the
dynaudnorm filter, and send call av_buffersrc_add_frame(s, NULL), then
subsequent av_buffersink_get_frame() calls will return EAGAIN instead of
EOF.
This was apparently caused by a recent change in FFmpeg.
Some other circumstances (which I didn't fully analyze and which is due
to the playloop's absurd temporary-EOF behavior on seeks) then led the
decoder loop to send data again, but since libavfilter was stuck in the
EOF state now, it could never recover. It kept sending new input (due to
missing output), until the demuxer refused to return more audio packets.
Each time a filter error was printed.
Fortunately, it's pretty easy to workaround. We just mark the p->eof
flag as we send an EOF frame to libavfilter. The p->eof flag is used
only to recover from temporary EOF: it resets the filter if new data is
available again. We don't care much about av_buffersink_get_frame()
returning a broken EAGAIN state in this situation and essentially ignore
it, meaning if we get EAGAIN after sending EOF, we assume effectively
that EOF was fully reached.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is actually a pretty important fix. eglChooseConfig() might be the
first thing that fails when porobing for desktop GL / ES2 / ES3 support,
because EGL_RENDERABLE_TYPE is set values specific to the underlying
APIs.
Not sure how the hell this worked before. EGL 1.4 implementations
certainly could fail the call with EGL_BAD_ATTRIBUTE if
EGL_RENDERABLE_TYPE has EGL_OPENGL_ES3_BIT set. It's quite possible that
many EGL implementations tolerate invalid EGLConfig values steming from
uininitialized EGLConfig values (and eglCreateWindowSurface() even is
specified to return EGL_BAD_CONFIG error code for "not valid"
EGLConfigs).
|
|
|
|
|
|
| |
This was accidentally flipped from 0 to 1 in a previous commit. Actually
simply remove it, because 0 is the default value for this parameter
anyway.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The way it should (probably) work is that selecting a RGBA framebuffer
format will simply make the compositor use the alpha. It works this way
on Wayland. On X11, this is... not done. Instead, both GLX and EGL
report two FB configs, which are exactly the same, except for the
platform-specific visual. Only the latter (non-default) points to a
visual that actually has alpha. So you can't make the pure GLX and EGL
APIs select alpha mode, and you have to override manually.
Or in other words, alpha was hacked violently into X11, in a way that
doesn't really make sense for the sake of compatibility, and forces API
users to wade through metaphorical cow shit to deal with it.
To be fair, some other platforms actually also require you to enable
alpha explicitly (rather than looking at the framebuffer type), but they
skip the metaphorical cow shit step.
|
|
|
|
|
|
|
|
| |
So that the EGL code can use it too.
Also print the actual FB config ID, instead of nonsense. (I _think_ once
in the past a certain GLX implementation just used numeric config IDs
casted to EGLConfig - or at least that would explain this nonsense.)
|
|
|
|
|
|
|
| |
Preparation for the following commits. Since at least theoretically the
config selection depends on the context type (EGL_RENDERABLE_TYPE has
separate bits for ES 2, ES 3, and desktop GL), doing it any other way
would be too painful.
|
|
|
|
|
|
|
|
|
|
| |
For X11 garbage we have to pass some annoying parameters to EGL context
creation. Add some sort of extensible API, so that adding a new
parameter doesn't break all callers. We still want to keep it as a
single function, because it's so nice isolating all the EGL nonsense API
boilerplate like this. (Did I mention yet that X11 and EGL are garbage?)
Also somewhat simplifies the vo_flags mess in the helper internals.
|
|
|
|
| |
The unprefixed versions are silently deprecated.
|
|
|
|
|
|
|
|
|
|
|
|
| |
The chroma alignment renormalization code forgot to account for the fact
that the chroma subsampling ratio has to be rotated.
Unfortunately, doing it this way seems to have somewhat broken the
chroma offset rotation logic for odd-sized subsampled image files. While
this is a bug, it's much, much less noticeable, so it's not nearly as
important as the bug this change fixes. Either way, a future patch needs
to still revise this logic, ideally by redesigning the entire rotation
mechanism.
|
|
|
|
| |
fixes #3946
|
|
|
|
|
| |
Useless now, so get rid of it. Also affects some user-visible display
things (like reported codec in use).
|
|
|
|
|
|
|
|
|
| |
Conceptually cleaner, although the API claims this is equivalent.
Originally, AVCodecContext fields were used, because not all supported
libavcodec/libavutil versions had the AVFrame fields.
This is not done for chroma_sample_location - it has no AVFrame field.
|
|
|
|
|
|
|
|
|
| |
Helps with gif, probably does unwanted things with other formats.
This doesn't handle --end quite correctly, but this could be added
later.
Fixes #3924.
|
| |
|
|
|
|
|
| |
This field is (or should be) deprecated, and there's no need to set it
with the new API.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
this replaces the old fullscreen with the native
macOS fullscreen. additional the
--fs-black-out-screens was removed since the new
API doesn't support it in a way the old one did.
it can possibly be re-added if done manually.
Fixes #2857 #3272 #1352 #2062 #3864
|
|
|
|
| |
It does more harm than good, since it spams terminal a lot
|
|
|
|
|
|
| |
the 'path' of an youtube url (youtube.com/watch?v=x)
would just be '/watch'. obviously this fails to
load.
|
|
|
|
|
|
|
| |
Allow minimizing the borderless/fullscreen window by clicking on the
taskbar button or pressing Win+Down hotkey.
Also fixes #2229 and probably fixes #2451
|
|
|
|
|
|
| |
According to MSDN, GetWindowLong and SetWindowLong have been
superseded by GetWindowLongPtr and SetWindowLongPtr.
It's a cosmetic code change in this case.
|
|
|
|
| |
In which case it does nothing.
|
|
|
|
| |
Using vo_opengl + MMAL overlay didn't quite work out.
|
|
|
|
|
|
| |
Possible with bumped FFmpeg/Libav.
These are just the simple cases.
|
|
|
|
|
| |
After various simplifications, these includes simply aren't needed
now.
|
|
|
|
|
|
|
|
|
|
|
| |
Needs explicit logic. Fixes a pretty bad regression which prefers
vdpau-copy over native vaapi with direct rendering (with --hwdec=auto)
if libvdpau-va-gl1 is present. The reason is that vdpau-copy is above
vaapi, simply because all vdpau hwdecs are grouped and happened to be
listed before vaapi.
Although this is not that bad for copy-mode (unlike the case described
above), it's still a good idea to use our native vaapi code instead.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Apparently we don't always set the viewport to window dimensions
anymore, e.g. if nothing is actually rendered. This means the viewport
can contain old values.
The window screenshot code uses the viewport values to guess the default
framebuffer dimensions. With --force-window --idle --no-osc (which draws
nothing and issues a glClear() command only), taking a screenshot would
yield an image with the wrong size and possibly garbage in it. Fix this
by explicitly passing the currently known window dimensions. Abusing the
values stored in the viewport was questionable anyway.
|
|
|
|
|
|
| |
Fixes a segfault introduced in libwayland
e8ad23266f36521215dcd7cfcc524e0ef67d66dd, where a poison value has been
introduced to catch this kind of use-after-free bug.
|
|
|
|
|
|
|
|
| |
Long planned. Leads to some sanity.
There still are some rather gross things. Especially g_groups is ugly,
and a hack that can hopefully be removed. (There is a plan for it, but
whether it's implemented depends on how much energy is left.)
|
|
|
|
|
|
| |
If Angle is statically linked there were some warnings during compilation.
Fixes #3834
|
|
|
|
|
|
| |
We want to avoid causing problems if libmpv is used in an application
that links cuda, or if the libav* libraries are linked with cuda,
as might happen if the scale_npp filter is used.
|
|
|
|
|
| |
Improves autoprobe behavior. This is equivalent to other hwdec interop
wrappers. If CUDA is just not available, it should remain silent.
|
|
|
|
|
|
| |
is not present
If CUDA SDK wasn't installed, mpv crashed immediately with the message "Failed to load CUDA symbols"
|
|
|
|
| |
Fixes #3834
|
|
|
|
|
|
|
|
|
|
| |
The test ended up failing if cuda.h wasn't present, even if cuda.h
isn't used during the actual build.
This test is attempting to establish if the ffmpeg being built
against has dynlink_cuda support. While it might theoretically be
possible to build against the older normally-linked-cuda version
of ffmpeg, it seems more trouble than it's worth.
|
|
|
|
| |
Remove the inverted condition by swapping if branches.
|
| |
|
|
|
|
|
|
| |
This was a typo in the extensiuon spec and was probably always broken.
Could have led to broken builds when used with ancient ANGLE headers
(or possibly generic EGL headers).
|
|
|
|
|
| |
This change applies the pattern used in ffmpeg to dynamically load
cuda, to avoid requiring the CUDA SDK at build time.
|
|
|
|
|
|
|
|
|
| |
The latest 375.xx nvidia drivers add support for P016 output
surfaces. In combination with an ffmpeg change to return those
surfaces, we can display them.
The bulk of the work is related to knowing which format you're
dealing with at the right time. Once you know, it's straight forward.
|
|
|
|
| |
Was deprecated, superseded by --hwdec=vdpau-copy.
|
|
|
|
|
|
|
|
| |
At least with Nvidia drivers, some thread tries to access D3D11 objects
after ANGLE unloads d3d11.dll. Fix this by holding a reference to
d3d11.dll ourselves.
Might fix the crash in #3348. (I wish I knew why though.)
|
|
|
|
|
|
|
|
| |
- win32-console-wrapper.c was inconsistently using the explicit Unicode
versions of some Windows API functions and structures.
- vo.c should use llabs for int64_t, since long is 32-bit on Windows.
- vo_direct3d.c had a potential use of an uninitialized variable if it
took the first goto error_exit.
|
|
|
|
|
| |
Do it after color management, etc. so that it matches the color drawn in
the margins.
|
|
|
|
|
|
|
|
|
|
| |
Deactivating this options makes it possible to
circumvent the default OS X behavior of using
points. Windows on HiDPI resolutions won't open
in double the size anymore and videos are display
in their native resolution when windowed.
Fixes #3716
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a bit unintuitiv, but it appears hwdec backends have to unset
hwdec_priv manually in their uninit function. Normally with this idiom
you'd expect the common code to do this (and maybe even freeing the priv
struct). Since other hwdec backends do this quite consistently, just fix
vdpau for now.
Also add an assert to detect similar bugs sooner.
Fixes #3788.
|
|
|
|
|
| |
Only print at most 2. Just because with some decoders, we will always
hit this code path, such as playing avi of vfw-muxed mkv on RPI.
|
|
|
|
|
|
| |
Same deal as with the previous commit.
(Unfortunately, this code is still duplicated.)
|
|
|
|
|
|
| |
Implementation-wise, the values from the demuxer/codec header are merged
with the values from the decoder such that the former are used only
where the latter are unknown (0/auto).
|
|
|
|
|
| |
Also extend the default buffer size for formatting this string, because
it can get too damn long.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The intention was that if --blend-subtitles is enabled, the frame should
always be re-rendered instead of using e.g. a cached scaled frame. The
reason is that subtitles can change anyway, e.g. if you pause and change
subtitle size and such.
On the other hand, if the frame is marked as repeated, it should always
use the cached copy. Actually "simplify" this and drop the cache only if
playback is paused (which frame->still indicates indirectly).
Also see PR #3773.
|
|
|
|
|
|
|
|
| |
unmap_current_image() is called after rendering. This essentially
invalidates the textures, so we can't assume that the image is still
present.
Also see PR #3773.
|