| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
This reverts commit 503c6f7fd6c3c542667c93c75db260671c4ba982.
There are situations where some decoders (MF apparently) always require
a timestamp. Also, this makes bitrate estimation more granular than
necessary. It seems it's better to try to detect fiels with broken
default durations explicitly instead. Or maybe something should be
added to smooth audio timestamps after filters.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This also draws it after color management etc. In a nutshell, this
change makes the transparency checkerboard independent of upscaling,
panning, cropping etc. It will always be the same apparent size and
position (relative to the window).
It will also be independent of the video colorspace and such things.
(Note: This might cause white imbalance issues if playing a file with a
white point that does not match the display, in absolute colorimetric
mode. But that's uncommon, especially in conjunction with transparent
image files, so it's not a primary concern here)
|
|
|
|
|
|
| |
Until now, we've let the windowing backend decide. But since they
usually require premultiplied alpha, and premultiplied alpha is easier
to handle, hardcode it.
|
|
|
|
|
|
| |
The recent changes fixed rotation handling, but reversed the rotation
direction. The direction is expected to be counter-clockwise, because
demuxers export video rotation metadata as such.
|
|
|
|
|
|
| |
Don't assume EOF if we didn't try to read anything in the first place.
Fixes regressions in particular with low cache sizes, which triggered
the other code paths more often.
|
|
|
|
|
|
|
|
| |
Instead of having a separate for each, which also requires separate
additional caching in the demuxer. (The demuxer adds an indirection,
since STREAM_CTRLs are not thread-safe.)
Since this includes the cache speed, this should fix #3003.
|
|
|
|
|
|
| |
Enables runtime change of the option.
Fixes #2994.
|
|
|
|
|
|
|
|
|
|
|
| |
This would get stuck in reconfiguring the filter chain forever, because
params was mutated ("params.rotate = 0;"). This was used as input for
vf_reconfig(), but the filter chain input must always be equivalent to
the decoder output, or filter chain reconfiguration will be triggered.
The line of code to reset the rotation is from a time when this used to
work differently.
Also remove the unnecessary try_filter() parameter.
|
|
|
|
|
|
|
| |
Makes certain cases of runtime changes actually work.
Also change the label for the stereo3d filter and make it consistent
with the rotate one.
|
|
|
|
| |
No functional changes.
|
|
|
|
|
| |
Using a single gl_transform variable instead of many float ones makes it
easier to see what it's doing. No functional change.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This has been completely broken since commit 93546f0c. But even before,
rotation handling did not make too much sense. In particular, it rotated
the contents of the cropped image, instead of adjusting the crop
rectangle as well. The result was that things like panscan or zooming
did not behave as expected with rotation applied.
The same is true for vertical flipping. Flipping is triggered by
negative image stride. OpenGL does not support flipping the image on
upload, so it's done as part of the rendering. It can be triggered with
--vf=flip, but other filters and even decoders could setup negative
stride to flip the image.
Fix these issues by applying transforms to texture coordinates properly,
and by making rotation and flipping part of these transforms.
This still doesn't work properly for separated scaling. The issue is
that we'd have to adjust how the passes are done. For now, pick a very
stupid solution by rotating the image to a FBO, and then scaling from
that. This has the avantage that the scale logic doesn't have to be
complicated for such a rare case. It could be improved later.
Prescaling is apparently still broken. I don't know if chroma
positioning works properly either. None of this should affect the case
with no rotation.
|
|
|
|
|
|
|
|
|
| |
gl_transform_vec() assumed column-major, while everything else seemed to
assumed row-major memory organization for gl_transform.m. Also,
gl_transform_trans() seems to contain additional confusion.
This didn't matter until now, as everything has been orthogonal, this
the swapped matrix entries were always 0.
|
|
|
|
|
|
|
|
|
| |
If the texture count is lower than 4, entries in va.textcoord[] will
remain uninitialized. While this is unlikely to be a problem (since
these values are unused on the shader side too), it's not nice and might
explain some things which have shown up in valgrind.
Fix by always initializing the whole thing.
|
| |
|
|
|
|
|
| |
Inverted condition due to weird semantics after a refactor some time
ago. Fixes #2848.
|
|
|
|
|
|
|
|
|
| |
E.g. "mouse 100 100 1 double" did not actually process the double-click,
because double-click emulation is on by default. So the user would have
to send two successive clicks instead. This is probably not expected, so
disable this weird logic for artificial input.
Fixes #2899.
|
|
|
|
|
|
| |
Still requires Cocoa for various things, but no vo_opengl.
Untested. Fixes #2980 (probably).
|
| |
|
| |
|
|
|
|
|
| |
Requested. The intention is that scripts can provide mappable actions
for key bindings without setting a default key.
|
|
|
|
|
| |
Does the same thing as the rpi one - makes fallback possible by
pretending that h264_mediacodec is a hwdec.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
In particular, this prevents subtitle packets from building up in the
subtitle queue if e.g. --vo=null is used. In this situation,
sub_get_bitmaps() is never called, and thus the segment never switched.
This also seems to help with flickering at segment switch boundaries (if
subs are supposed to be visible at the transition points).
In theory, this could trigger a switch too early, but the way VO and
subtitle renderer interact wrt. timing is a bit iffy anyway.
|
|
|
|
|
|
|
|
|
|
|
| |
SEEK_HR is interpreted by demux_mkv.c, and enables subtitle preroll by
prefetching additional subtitle pakcets which might overlap with the
seek destination. This should make the case work when segment boundaries
fall into the middle of subtitle events.
This still usually leaves a flicker of at least 1 frame on start,
because dec_sub.c does not ensure that enough subtitles are read before
rendering after a segment switch. (Probably a WONTFIX.)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The default security descriptor for named pipes in Windows allows the
pipe to be opened for read access by the Everyone group and Anonymous
account, as well as low-integrity processes (like web browser renderer
processes.) This does not allow commands to be ran, but it does allow
events to be received.
I don't think any sensitive data is exposed by events, but that may not
always be the case and Lua plugins might change this, since they can
broadcast their own events with script-message. To be safe, this commit
sets a custom security descriptor on the named pipe which only allows
access from processes running under the same user account with an
integrity level greater than or equal to the one used by mpv.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of reallocating almost all of the shader string several times
per pass, build it into a fixed buffer that will be reallocated as
needed.
While this still uses a linear search and full comparison of the shader
text, this will compare the shader's string length first before doing a
full comparison as a nice side effect. (That's also why the fragment
shader is compared first - it's more likely to be different for
different cache entries than the vertex shader stub.)
|
| |
|
|
|
|
| |
For now only found in Libav.
|
|
|
|
|
| |
vd_lavc.c had this, and soon I'll need it in ad_lavc.c too. For now it's
unused.
|
|
|
|
|
|
| |
The mp_set_av_packet()/mp_pts_from_av() functions check whether the
timebase is set at all (i.e. AVRational.num!=0), so there's no need to
fiddle with pointers.
|
|
|
|
|
| |
Use bstr as appending buffer, which should avoid frequent reallocation
and copying. The previous commit should help with this a little.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until now, bstr_xappend_vasprintf() called vsnprintf() always twice:
once to determine how much output the call would produce, and a second
time to actually output the data to the (possibly resized) target
memory.
Change this so that it tries to output to the already allocated memory
first, and repeat the call only if allocation is required.
This is especially helpful, as bstr_xappend_vasprintf() is designed to
avoid reallocation when building strings. Usually, the second
vsnprintf() will happen only at the beginning, when the buffer hasn't
been extended to his largest needed size yet.
Not sure if there is a need to optimize this; but see the next commit.
|
|
|
|
|
| |
Broken in commit d6c99c85. vo_opengl_cb.c adds the corner case that
p->osd can be NULL. This make opengl-cb always crash.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
JSON IPC works on Windows now, and although the transports for each
plaform have similar characteristics, they unfortunately have different
names (Unix domain sockets on Linux/Unix vs. named pipes on Windows.)
Hopefully this change better reflects the purpose of the option too,
since with --input-ipc-server, mpv acts as an IPC server that can
service many simultaneous clients (as opposed to --input-file, which can
only do one-to-one IPC.)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This implements the JSON IPC protocol with named pipes, which are
probably the closest Windows equivalent to Unix domain sockets in terms
of functionality. Like with Unix sockets, this will allow mpv to listen
for IPC connections and handle multiple IPC clients at once. A few cross
platform libraries and frameworks (Qt, node.js) use named pipes for IPC
on Windows and Unix sockets on Linux and Unix, so hopefully this will
ease the creation of portable JSON IPC clients.
Unlike the Unix implementation, this doesn't share code with
--input-file, meaning --input-file on Windows won't understand JSON
commands (yet.) Sharing code and removing the separate implementation in
pipe-win32.c is definitely a possible future improvement.
|
|
|
|
|
| |
Also change the property to an int, since using double is questionable
and pointless.
|
|
|
|
|
|
|
|
|
| |
Shader miscompilation and bad output.
Regression probably since commit 93546f0c (or one of the following
ones).
Fixes #2982.
|
|
|
|
| |
Found by clang-tidy.
|
|
|
|
|
|
|
|
|
| |
Glitches when resizing are still possible, but are reduced. Other VOs
could support this too, but don't need to do so.
(Totally avoiding glitches would be much more effort, and probably not
worth the trouble. How about you just watch the video the player is
playing, instead of spending your time resizing the window.)
|
|
|
|
|
|
|
| |
Should reflect I/O speed.
This could go into the terminal status line. But I'm not sure how to put
it there, since it already uses too much space, so it's not there yet.
|
|
|
|
|
|
|
|
|
|
|
| |
The old algorithm produced results which were not uniformly distributed,
i.e. some particular shuffles were preferred over others.
The new algorithm is an implementation of the Fisher-Yates shuffle which
is guaranteed to shuffle uniformly given a sufficiently uniform rand()
and ignoring potential floating-point errors.
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until now, we have tried to create a GL 3.0 context. The main reason for
this is that many Mesa-based drivers did not support anything better.
But some drivers (Mesa AMD) will not report a higher OpenGL version,
because their compatibility mode is restricted. While later GL features
are reported as extensions just fine, there doesn't seem to be a way to
determine or enable higher GLSL versions.
Add some more shitty hacks to try to deal with this messed up situation,
and try to probe each interesting GL version separately (starting with
3.3, then 3.2 etc.). Other backends might suffer from similar problems,
but these will have to deal with it on their own.
Probably fixes #2938, or maybe not.
|
|
|
|
| |
This line was added in ae5df9be98e4193342321f30285655fcf88e7e63, and it appears to have been a typo.
|
|
|
|
|
|
|
|
|
| |
Prevents an infinite loop of configure event and set_fullscreen
request on Weston and other compositors respecting the protocol.
Fixes #2817
This reverts commit eb6b2b6e50e6e3d3db41190ad818d8b966750734.
|
|
|
|
|
|
| |
This colorspace has been historically used as a calibration target for
most digital projectors and sees some involvement in the UltraHD
standards, so it's a useful addition to mpv.
|
|
|
|
|
| |
The .exe extension *is* required. It only kind of worked without it due to the
--check-c-compiler flag.
|
|
|
|
|
| |
Apparently, you're not supposed to use msys2 pkg-config for mingw stuff.
Also, in msys2, python *is* python3.
|
| |
|
|
|
|
|
|
|
|
|
| |
This changes behavior somewhat. The old behavior can be restored by
running "mp.use_suspend=true". It was originally introduced for the OSC,
but I can't reproduce whatever misbehavior I was seeing.
(See mp.suspend()/resume() for explanations what the suspend mechanism
does.)
|
|
|
|
| |
Regression since commit 6640b22a.
|
|
|
|
|
| |
"Normal" seeks, which don't actually switch the segment, do not need to
reinit the decoders.
|
|
|
|
|
|
|
|
|
|
|
| |
converted_imgfmt will be used by the renderer logic to build an
appropriate shader chain. It doesn't influence the format of any
textures. Thus it doesn't matter whether the hw video surface is mapped
as RGB or RGBA. What matters is if the video actually contains alpha or
not. Since virtually all hardware decoder do not support alpha in any
way, this can be hardcoded as "no alpha".
This avoids unnecessary GPU work.
|
|
|
|
|
|
|
|
| |
This also gets rid of the kind of hard to read texture swizzle setup and
turns it into something dumber.
Assumes that we don't create any FBOs with 2 channel formats. (Only the
video source textures are handled by this commit.)
|
|
|
|
|
|
|
|
| |
This is particularly useful for opus which allows only a fairly restrictive set
of samplerates. If the codec doesn't provide a list of samplerates, just
continue to try the requsted one and hope for the best.
fixes #2957
|
|
|
|
| |
It duplicates the logic that was previously used here.
|
|
|
|
|
|
| |
This function chooses the best match to a given samplerate from a provided
list. This can be used, for example, by the ao to decide what samplerate to use
for output.
|
|
|
|
| |
Not quite sure when/why exactly this was broken.
|
|
|
|
|
|
| |
Regression since commit 93546f0c.
Fixes #2956.
|
|
|
|
|
|
|
|
| |
* Use the update-core command
* Add --check-c-compiler=gcc to be safe
* Add warning about potential pitfalls of adding C:\msys2\mingw64\bin to %PATH%
* Recommend winpty
* Add note about ANGLE
|
| |
|
|
|
|
|
|
|
|
|
| |
Previously, gl->DXOpenDeviceNV was called twice using dxva2 with dxinterop. AMD
drivers refused to allow this. With this commit, context_dxinterop sets its own
implementation of MPGetNativeDisplay, which can return either a
IDirect3DDevice9Ex or a dxinterop_device_HANDLE depending on the "name" request
string. hwdec_dxva2gldx then requests both of these avoiding the need to call
gl->DXOpenDeviceNV a second time.
|
| |
|
|
|
|
|
| |
This will w |