| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Some libavformat muxers (e.g. matroskaenc.c) expect this field to be set
on the AVStream struct, and not only in the AVCodecParameters.
|
| | |
|
| |
|
|
|
|
|
| |
This is documented as required (although we did not do it in
the old GL codepath, with no visible problems) and I have seen
transient artifacts after seeking which _appear_ to have gone
away after introducing this.
|
| |
|
|
|
| |
Basically just to trigger a doc rebuild, but might as well do a useful
change, since angleproject-git is no longer a valid package in MSYS2.
|
| |
|
|
| |
Closes #6822
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
this migrates our current swift code to version 5 and 4. building is
support from 10.12.6 and xcode 9.1 onwards.
dynamic linking is the new default, since Apple removed static libs
from their new toolchains and it's the recommended way.
additionally the found macOS SDK version is printed since it's an
important information for finding possible errors now.
Fixes #6470
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Fixes #6621
|
| |
|
|
|
| |
this provides an easy way to check for a specific macOS SDK version and
with that the availability of features.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
this is in preparation for the upcoming swift 5 transition, where static
linking was replaced by dynamic linking the swift libraries as the
preferred way, by Apple. furthermore Apple removed the static swift libs
from their dev Tools starting with xcode 10.2/swift 5.
because of ABI incompatibility dynamic linking for swift versions prior
to 5 doesn't use the system lib path for the dynamic swift libs.
for now static linking is still the default, but that will be changed
when swift 5 support is added and swift 3 support is dropped.
Fixes #6232
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the xcode-select tool only properly works with Apple provided toolchains
but not with third party ones from swift.org. in the latter case the
swift compiler executable is found in the proper path but the swift libs
from the xcode or command line tools will be picked. this leads to a
not wanted discrepancy of the swift compiler and libs and possible
errors.
instead of relying on the xcode-select tool search for the libs relative
to the swift executable. that relative path seems to be the same for all
toolchains. if for any reasons a swift executable is not found in the
relative path, fall back to the old xcode-select method.
furthermore, both static and dynamic libs will be searched for but only
the former will be used for now. this is a preparation for the upcoming
swift 5 migration.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We saw a segfault when trying to use the intel-media-driver (iHD)
rather than the normal intel va driver. This happened because the
iHD driver reports P010 (and maybe other formats) with multiple
layers to represent the interleaved UV plane. The normal va driver
reports one UV layer to match the plane.
This threw off my logic which assumed that the number of layers
could not exceed the number of planes.
There's a way one could fix this in a fully generalised form, but
I'm just going to do what the EGL path does and assume that:
* Layer 'n' is on Plane 'n' for n < total number of planes
* These layers always start at offset 0 on the plane
You can imagine ways that these assumptions are violated, but at
least the failure will look the same for both EGL and Vulkan
paths.
|
| |
|
|
|
|
|
|
|
|
| |
Today, we normally see a format error when probing because yuyv422
cannot be used, but it's in the normal set of probed formats.
This error is distracting and confusing, so only log probing errors
at the VERBOSE level.
Fixes #6411
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change introduces a vulkan interop path for the vaapi hwdec.
The basic principles are mostly the same as for EGL, with the
exported dma_buf being imported by Vukan. The biggest difference
is that we cannot reuse the texture as we do with OpenGL - there's
no way to rebind a VkImage to a different piece of memory, as far
as I can see. So, a new texture is created on each map call.
I did not bother implementing a code path for the old libva API as
I think it's safe to assume any system with a working vulkan driver
will have access to a newer libva.
Note that we are using separate layers for the vaapi surface, just
as is done for EGL. This is because libplacebo doesn't support
multiplane images.
This change does not include format negotiation because no driver
implements the vk_ext_image_drm_format_modifier extension that
would be required to do that. In practice, the two formats we care
about (nv12, p010) work correctly, so we are not blocked. A separate
change had to be made in libplacebo to filter out non-fatal validation
errors related to surface sizes due to the lack of format negotiation.
|
| |
|
|
|
| |
In preparation for adding Vulkan interop support, let's rename
to remove the egl reference and move to an api neutral location.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
New releases of VDPAU support decoding 4:4:4 content, and that comes
back as NV24 when using 'direct mode' in OpenGL Interop. That means we
need to be a little bit smarter about how we set up the OpenGL
textures.
|
| |
|
|
|
|
|
|
|
| |
If the compositor sends a configure event before the surface is initially
mapped, resize gets called before the egl_window gets created, resulting
in a crash in wl_egl_window_resize.
This was fixed back in 618361c697, but was reintroduced when the wayland
code was rewritten in 68f9ee7e0b.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While `ra` supports the concept of a texture as a storage
destination, it does not support the concept of a texture format
being usable for a storage texture. This can lead to us attempting
to create a texture from an incompatible format, with undefined
results.
So, let's introduce an explicit format flag for storage and use
it. In `ra_pl` we can simply reflect the `storable` flag. For
GL and D3D, we'll need to write some new code to do the compatibility
checks. I'm not going to do it here because it's not a regression;
we were already implicitly assuming all formats were storable.
Fixes #6657
|
| |
|
|
|
|
|
| |
Obvious mistake. This reported 44 bytes more data than what was
available. Could cause out of bounds reads. Security researchers would
claim a major victory if they found something like this in more popular
software, and would create a website for it.
|
| |
|
|
|
|
|
|
| |
Support for Ada and Objective-C was removed from MSYS2, which made
pacman refuse to update GCC while the gcc-ada and gcc-objc packages were
installed. Remove those packages before updating the others. Also remove
ANGLE, which has been removed from MSYS2, and add libplacebo, which is
now needed for the Vulkan VO.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This started as a desperate attempt to lower the memory requirement
of error diffusion, but later it turns out that this change also
improved the rendering performance a lot (by 40% as I tested).
Errors was stored in three uint before this change, each with 24bit
precision. This change encoded them into a single uint, each with 8bit
precision. This reduced the shared memory usage, as well as number of
atomic operations, all by three times.
Before this change, with the minimum required 32kb shared memory, only
the `simple` kernel can be used to render 1080p video, which is mostly
useless compare to `--dither=fruit`. After this change, 32kb can
handle `burkes` kernel for 1080p, or `sierra-lite` for 4K resolution.
|
| |
|
|
|
|
|
| |
error diffusion requires two texture rendering pass. The existing code
reuses `screen_tex` and creates another for such purpose. This works
generally well for opengl, but could potentially be problematic for
vulkan, due to its async natural.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a straightforward parallel implementation of error diffusion
algorithms in compute shader. Basically we use single work group with
maximal possible size to process the whole image. After a shift
mapping we are able to process all pixels column by column.
A large ring buffer are allocated in shared memory to speed things up.
However the size of required shared memory depends linearly on the
height of video window (or screen height in fullscreen mode). In case
there is no enough shared memory, it will fallback to `--dither=fruit`.
The maximal allowed work group size is hardcoded as 1024. Ideally we
could query `GL_MAX_COMPUTE_WORK_GROUP_INVOCATIONS`. But for whatever
reason, it seems most high end card from nvidia and amd support only
the minimal required value, so I guess we can stick to it for now.
|
| |
|
|
|
| |
OBS isn’t really set up to support this. If needed, we should instead
git clone FFmpeg as part of the CI. I don’t think it is, though.
|
| |
|
|
|
| |
This assumes a non-upstream .pc file since upstream doesn’t seem
to give a fuck about this use case at all.
|
| |
|
|
|
|
| |
They might be needed for rendering subs from those sources.
Fixes #6009.
|
| |
|
|
|
|
|
|
|
|
| |
When the D3D11 backend was first written, SPIRV-Cross only had a C++ API
and no guarantee of API or ABI stability, so instead of using
SPIRV-Cross directly, mpv used an unofficial C wrapper called crossc.
Now that KhronosGroup/SPIRV-Cross#611 is resolved, SPIRV-Cross has an
official C API that can be used instead, so remove crossc and use
SPIRV-Cross directly.
|
| |
|
|
|
|
|
|
| |
The calculation of scale factor involves 32-bit float, and a strict
equality test will effectively ignore `--scaler-resizes-only` option
for some non-integer scale factor.
Fix this by using non-strict equality check.
|
| |
|
|
|
| |
It will provide low level access to coordinate mapping other than
texmap().
|
| |
|
|
|
| |
This commit essentially makes user shader able to fix offset (produced
by other prescaler, for example) like builtin `--scale`.
|
| |
|
|
| |
Probably the same issue as #6732
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
since the none native fs is a special legacy case it needs a special
quit routine. it indefinitely waited for an exit fs screen event to
shutdown properly, though that event only fires for the native fs.
now we check if we really are using a native fullscreen and if not
shutdown immediately.
Fixes #6704
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
These were unnecessary for a couple of reasons, but it seems like the
old code went through a lot of effort to avoid duplicating the code to
print a RECT, even though the windowrc gets printed anyway at the end of
the function.
Avoid printing the same windowrc twice by only printing it when it gets
changed (in the w32->current_fs branch.)
|
| |
|
|
|
|
|
|
|
|
|
|
| |
I assume (but cannot confirm) that VA-AP-API is in fact a typo, because
most if not all search engine results related to it are from mpv's manual
page.
By changing this to VA-API and clarifying that this requires VA-API support
on a system to use it, we can hopefully make it clear to unsuspecting
Windows users that this is not the filter they're looking for.
Concerns #6690.
|
| | |
|
| |
|
|
|
|
|
| |
This allows to select the drm mode using a string specification. You
can either select the the preferred mode, the mode with the highest
resolution, by specifying WxH[@R] or by its index in the list of modes
as before.
|
| |
|
|
|
| |
As far as I know none of these functions were being used outside of
drm_common, nor should there really be a need to use them.
|
| |
|
|
|
|
|
| |
This was implemented by using OPT_STRING_VALIDATE for drm-mode,
instead of OPT_INT. Using a string here also prepares for future
additions to drm-mode that aim to allow specifying a mode by its
resolution.
|
| |
|
|
|
|
| |
It is useful when debugging to be able to force atomic off, or as a
workaround if atomic breaks for some user. Legacy modesetting is less
likely to break by virtue of being a less complex API.
|
| |
|
|
|
|
|
|
| |
The amount of code now present that's specific to Vulkan or OpenGL
has reached the point where we really want to split it out to
avoid a mess of #ifdefs.
At the same time, I'm moving the code to an api neutral location.
|
| |
|
|
|
| |
This implements presentation feedback for context_drm_egl using the
values that get fed to the page flip handler.
|
| |
|
|
|
|
| |
the force unwrapping of optionals caused many unpredictable segfaults
instead of gracefully exiting or falling back. besides that, it is bad
practice and the code is a lot more stable now.
|
| |
|
|
|
|
|
| |
The actual code utilizing this enum was seemingly properly if'd,
but not the enum in the struct itself.
Fixes compilation.
|
| |
|
|
| |
From internal to libplacebo.
|
| |
|
|
|
| |
This tries to tidy up the GL vs Vulkan code to be a bit cleaner
and easier to read.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change updates the vulkan interop code to work with the
libplacebo based ra_vk, but also introduces direct VkImage
sharing to avoid the use of the intermediate buffer.
It is also necessary and desirable to introduce explicit
semaphore bsed synchronisation for operations on the shared
images.
Synchronisation means we can safely reuse the same VkImage for every
mapped frame, by ensuring the frame is copied to the VkImage before
mapping the next frame.
This functionality requires a 417.xx or newer nvidia driver, due to
bugs in the VkImage interop in the earlier 411 and 415 drivers.
It's definitely worth the effort, as the raw throughput is about
twice that of implementation using an intermediate buffer.
|
| |
|
|
|
|
|
| |
When interacting directly with libplacebo, we may need to pass a
pl_fmt based on an ra_format. Although the mapping is currently
trivial, it's worth wrapping to make it easy to adapt if this
changes in the future.
|
| |
|
|
|
| |
We need access to the underlying pl_gpu to make libplacebo calls
from hwdecs.
|
| |
|
|
|
| |
Feature parity with the original ra_vk obviously requires win32 support,
so let's put it back in.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit rips out the entire mpv vulkan implementation in favor of
exposing lightweight wrappers on top of libplacebo instead, which
provides much of the same except in a more up-to-date and polished form.
This (finally) unifies the code base between mpv and libplacebo, which
is something I've been hoping to do for a long time.
Note: The ra_pl wrappers are abstract enough from the actual libplacebo
device type that we can in theory re-use them for other devices like
d3d11 or even opengl in the future, so I moved them to a separate
directory for the time being. However, the rest of the code is still
vulkan-specific, so I've kept the "vulkan" naming and file paths, rather
than introducing a new `--gpu-api` type. (Which would have been ended up
with significantly more code duplicaiton)
Plus, the code and functionality is similar enough that for most users
this should just be a straight-up drop-in replacement.
Note: This commit excludes some changes; specifically, the updates to
context_win and hwdec_cuda are deferred to separate commits for
authorship reasons.
|
| |
|
|
|
|
|
| |
This helps with compatibility and/or performance in particular for
oddly-sized formats like rgb24. We use a loop to avoid having to
calculate the lcm (or waste bytes in the extremely common case of the
byte size and the stride align having shared factors).
|
| |
|
|
| |
If !osd->texture, then mpgl_osd_draw_prepare fails.
|
| |
|
|
|
| |
No reason to require them be constant. This allows them to depend on
runtime characteristics of the `ra`.
|
| |
|
|
|
|
| |
Shaderc comes with a Python script that automatically fetches
"known-good" versions of its dependencies. Use that instead of manually
cloning dependencies to third-party.
|
| | |
|
| | |
|
| |
|
|
| |
Signed-off-by: Aman Gupta <aman@tmm1.net>
|
| |
|
|
|
|
|
| |
This more closely mimics ao_coreaudio, on which this driver was
originally based.
Signed-off-by: Aman Gupta <aman@tmm1.net>
|
| |
|
|
|
|
| |
As discussed here:
https://github.com/mpv-player/mpv/issues/6545#issuecomment-476015318
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
half of the materials we used were deprecated with macOS 10.14, broken
and not supported by run time changes of the macOS theme. furthermore
our styling names were completely inconsistent with the actually look
since macOS 10.14, eg ultradark got a lot brighter and couldn't be
considered ultradark anymore.
i decided to drop the old option --macos-title-bar-style and rework
the whole mechanism to allow more freedom. now materials and appearance
can be set separately. even if apple changes the look or semantics in
the future the new options can be easily adapted.
|
| |
|
|
|
|
| |
setting the appearance of the window to nil will always use the system
setting and changes on run time switches too. this is only the case for
macOS 10.14.
|
| |
|
|
|
|
|
|
|
| |
quite a lot of the title bar functionality and logic was within our
window. since we recently added a custom title bar class to our window
i decided to move all that functionality into that class and in its
own file.
this is also a preparation for the next commits.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
i found the old pixel format creation a bit too messy. pixel format
attribute arrays and look ups were all over the place, the actual logic
what kind of format was created was inscrutable, the software pixel
format was hardcoded and no probing was done.
i split the attributes into mandatory and optional ones, one mandatory
for a hardware and software pixel format each, and moved those to the
top of the class. that way new attributes can be easily added to either
the mandatory or optional attributes and they don't mess up the actual
pixel creation logic any more. furthermore both hardware and software
pixel formats are being probed the same way now. to minimise code
duplications the probing was moved into its own function.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
only the dragged types NSFilenamesPboardType and NSURLPboardType were
supported to be dropped on the window, which was inconsistent with the
dragged types the dock icon supports. the dock icon additional supports
strings that represents an URL or a path. the system takes care of
validating the strings properly in the case of the dock icon, but in the
case of dropping on the window it needs to be done manually.
support for strings is added by also allowing the NSPasteboardTypeString
type and manually validating the strings. strings are split by new lines
and trimmed, to also support a list of URLs and paths. every new element
is checked if being an URL or path and only then being added to the
playlist.
|
| |
|
|
|
|
|
| |
this could lead to a crash on deinit when flush
was called while the opengl state was cleaned up.
Fixes #6323
|
| |
|
|
|
|
|
|
|
|
|
|
| |
on init an NSWindow can't be placed on a none Main screen NSScreen
outside the Main screen's frame bounds.
To fix this we just check if the target screen is different from the
main screen and if that is the case we check the actual position with
the expect one. if they are different we try to reposition the window
to the wanted position.
Fixes #6453
|
| |
|
|
|
|
|
| |
when quitting mpv in fullscreen the System always switchs to Space 1
regardless of which Space mpv was on previous to switching to fs. to fix
this we close the window before quitting fs. that way the System
switches back the the Space mpv was previous on before fs.
|
| | |
|
| |
|
|
| |
Fixes #6489
|
| |
|
|
|
|
|
| |
new events were added but not fetched by the vo, because we didn't
signal the vo that new events were available.
actually wakeup the vo when new events are available.
|
| |
|
|
|
|
|
|
|
|
| |
#6299 reported problems with earlier 3.0.x swift versions. i tested with
3.0.2/SDK 10.12.2 and just assumed it also works with the older 3.0.x
swift and 10.12.x SDK versions. due to the unstable nature of swift
there were slight API differences that caused build problems.
since swift is bundled with the SDK we just bump the minimum swift
version.
|
| |
|
|
| |
to make it consistent with the other checks and their output messages.
|
| | |
|
| |
|
|
|
|
|
| |
Remove the 2-digit-number restriction when reading the number of
minutes in the cue sheet INDEX command.
Fixes #6481
|
| |
|
|
| |
Signed-off-by: Aman Gupta <aman@tmm1.net>
|
| |
|
|
|
|
| |
The cache options were changed, and this commit
fixes the example big-cache profile to use the
new cache options.
|
| |
|
|
|
|
|
|
|
| |
Regression from 8e3308d687c3acdd0d572015b06efd5b492d93ee.
Broken cases were:
* --no-cursor-autohide acted like --cursor-autohide=always.
* --cursor-autohide-fs-only always hid the cursor if starting
non-fullscreen; entering fullscreen at least once fixed it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The old size limit was chosen before LUT texture was supported in user
shader. At that time, the whole user shader will be compiled and run
on GPU, which makes large user shader impractical to be used.
With the introduction of LUT texture, the old size limit doesn't make
any sense. For example, a 1024x1024 rgba16f LUT will cost 32MB shader
size.
Fix this by increasing the size limit to a value that's unlikely be
reached.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
this was meant to be fixed by 546f038, but with --disable-cplugins the
do_the_symbol_stuff function was never called and the handle_add_object
function was again always called before the actual linking task was
created.
to fix this we explicitly call handle_add_object only after all the
tasks the do_the_symbol_stuff function is called after too.
Fixes #6028
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Adds the negation missed in 8816e1117ee65039dbb5700219ba3537d3e5290e
when moving from a positive-is-active to positive-is-idle variable.
This leads to proper updates to properties such as "eof-reached",
as well as fixes screensaver state updates.
Separately found and fixed by avih and wnoun.
Co-authored-by: wnoun <wnoun@outlook.com>
|
| |
|
|
| |
Closes: #6507
|
| |\
| |
| |
| |
| |
| | |
Manual changes done:
* Merged the interface-changes under the already master'd changes.
* Moved the hwdec-related option changes to video/decode/vd_lavc.c.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
modulo operator could be used to check if size is multiple of a
certain number.
equal operator could be used to verify if size of different textures
aligns.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Before this commit, texture offset is set after all source textures
are finalized. Which means CHROMA hooks won't be able to align with
luma planes. This could be problematic for chroma prescalers utilizing
information from luma plane.
Fix this by find the reference texture early, and set global texture
offset early.
|
| | |
| |
| |
| | |
Fixes #5980
|
| | |
| |
| |
| |
| |
| | |
There could be another comment line or the end of the file.
Fixes #6529.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Only printable ASCII characters were considered to be valid texts. Make
it possible that UTF-8 contents are also considered valid.
This does not make the SDH subtitle filter support non-English
languages. This just prevents the filter from blindly marking lines that
have only UTF-8 characters as empty.
Fixes #6502
|
| | |
| |
| |
| |
| |
| | |
Crashes NVIDIA, probably buggy on others. No one ever tests this shit.
See #2192
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The seek range update was to early and did not take the removed head
packets into account. And therefore missed that the queue was not
BOF anymore.
This led to not be able to backward seek before the first packet of
the first seek range.
Fix it by moving the seek range update after the possible removal and
the change of the BOF flag.
Fixes: #6522
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
As stated in the original commit message, if the demuxer set the start
time to the first subtitle packet, the subtitles would be shifted
incorrectly. It appears that it is the case for external PGS subtitles.
This reverts commit 520fc7403621156676b1ca183aed4911bf6c47b5.
Fixes #5485
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This allows context_drm_egl to use as many buffers as libgbm or the
swapchain_depth setting allows (whichever is smaller).
On pause and on still images (cover art etc.) to make sure that output does not
lag behind user input, the swapchain is drained and reverts to working in a dual
buffered (equivalent to swapchain-depth=1) manner.
When possible (swapchain-depth>=2), the wait on the page flip event is now not
done immediately after queueing, but is deferred to the next invocation of
swap_buffers. Which should give us more CPU time between invocations.
Although, since gbm_surface_has_free_buffers() can only tell us a boolean value
and not how many buffers we have left, we are forced to do this contortionist
dance where we first overshoot until gbm_surface_has_free_buffers() reports 0,
followed by immediately waiting so we can free a buffer, to be able to get the
deferred wait on page flip rolling.
With this commit we do not rely on the default vsync fences/latency emulation of
video/out/opengl/context.c, but supply our own, since the places we create and
wait for the fences needs to be somewhat different for best performance.
Minor fixes:
* According to GBM documentation all BO:s gotten with
gbm_surface_lock_front_buffer must be released before gbm_surface_destroy is
called on the surface.
* We let the page flip handler function handle the waiting_for_flip flag.
|
| | |
| |
| |
| |
| | |
OpenGL ES 3.0 and up has suppport for for GL_ARB_sync style fences.
Make sure that mpv can use them.
|
| | |
| |
| |
| |
| |
| |
| | |
Use `mp_aframe_get_planes` to properly get the number of planes, instead
of assuming it to be the number of channels.
Fixes #6092
|
| | |
| |
| |
| |
| |
| |
| | |
This solves some edge cases when using files with very weird metadata
(e.g. MaxCLL 10k and so forth). Instead of just blindly seeding it with
the tagged metadata, forcibly set the initial state from the detected
values.
|
| | |
| |
| |
| |
| |
| |
| | |
Rather than the linear cd/m^2 units, these (relative) logarithmic units
lend themselves much better to actually detecting scene changes,
especially since the scene averaging was changed to also work
logarithmically.
|
| | |
| |
| |
| | |
Can explode on some clips otherwise
|
| | |
| |
| |
| |
| |
| | |
Gamut mapping can take very bright out-of-gamut colors into the
negatives, which completely destroys the color balance (which tone
mapping tries its best to preserve).
|
| | |
| |
| |
| |
| | |
As is the case for actually out-of-gamut colors (rather than just too
bright colors).
|
| | |
| |
| |
| |
| | |
Not a huge deal, but we can do the division in C, which makes the float
constant larger.
|
| | |
| |
| |
| |
| | |
There's no point to disallow target-trc/prim in dumb mode, since they
still work fine.
|
| | |
| |
| |
| |
| |
| |
| | |
This change switches to a logarithmic mean to estimate the average
signal brightness. This handles dark scenes with isolated highlights
much more faithfully than the linear mean did, since the log of the
signal roughly corresponds to the perceptual brightness.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In theory our "eye adaptation" algorithm works in both ways, both
darkening bright scenes and brightening dark scenes. But I've always
just prevented the latter with a hard clamp, since I wanted to avoid
blowing up dark scenes into looking funny (and full of noise).
But allowing a tiny bit of over-exposure might be a good thing. I won't
change the default just yet (better let users test), but a moderate
value of 1.2 might be better than the current 1.0 limit. Needs testing
especially on dark scenes.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The previous approach of using an FIR with tunable hard threshold for
scene changes had several problems:
- the FIR involved annoying hard-coded buffer sizes, high VRAM usage,
and the FIR sum was prone to numerical overflow which limited the
number of frames we could average over. We also totally redesign the
scene change detection.
- the hard scene change detection was prone to both false positives and
false negatives, each with their own (annoying) issues.
Scrap this entirely and switch to a dual approach of using a simple
single-pole IIR low pass filter to smooth out noise, while using a
softer scene change curve (with tunable low and high thresholds), based
on `smoothstep`. The IIR filter is extremely simple in its
implementation and has an arbitrarily user-tunable cutoff frequency,
while the smoothstep-based scene change curve provides a good, tunable
tradeoff between adaptation speed and stability - without exhibiting
either of the traditional issues associated with the hard cutoff.
Another way to think about the new options is that the "low threshold"
provides a margin of error within which we don't care about small
fluctuations in the scene (which will therefore be smoothed out by the
IIR filter).
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Instead of desaturating towards luma, we desaturate towards the
per-channel tone mapped version. This essentially proves a smooth
roll-off towards the "hollywood"-style (non-chromatic) tone mapping
algorithm, which works better for bright content, while continuing to
use the "linear" style (chromatic) tone mapping algorithm for primarily
in-gamut content.
We also split up the desaturation algorithm into strength and exponent,
which allows users to use less aggressive desaturation settings without
affecting the overall curve.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
This is the naming xdg-shell stable adopted, it doesn’t make much sense
to keep using “shell” everywhere with all functions calling it
“wm_base”.
Finishes what 76211609e3c589dafe3ef9a36cacc06e8f56de09 started.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Too many broken hardware decoders. Noticed wrong decoding of a video
file encoded with x262 on RX Vega when using VAAPI (Mesa 18.3.2).
Looks fine with swdec and a cheap hardware BD player.
Reverts 017f3d0674e48a587b9e6cd7a48f15519c799c3e
|
| | |
| |
| |
| | |
Fixes #6241
|
| | | |
|
| | |
| |
| |
| | |
preparations for the following commit.
|
| | |
| |
| |
| | |
fixes build on older systems
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
some safety mechanism for the async fs animation aren't needed anymore,
due to possible improved logic and slightly different behaviour on new
macOS versions. that safety fallback prevented the Split View because
it always returned a rectangle of the whole screen, instead of just
part/half of it.
Fixes #6443
|
| | |
| |
| |
| |
| | |
List auto as an option for target-peak, and state that auto is its
default operation.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Add "auto" the possible values of target-peak. The default value
for target_peak is to calculate the target using mp_trc_nom_peak.
Unfortunately, this default was outside the acceptable range of
10-10000 nits, which prevented its later reassignment. So add an
"auto" choice to target-peak which lets clients and scripts go back
to using the trc default after assigning a value.
|
| | |
| |
| |
| |
| |
| |
| | |
this lead to an unexpected videotoolbox-copy hwdec name due to the last
two chars being cut off. since selection is also done by that name one
had to use "videotoolbox-co" to explicitly use the copy mode of
videotoolbox.
|
| | |
| |
| |
| |
| |
| |
| | |
Merge file-size/file-format and audio channel-count/format into one line
respectively. This fixes stats overflowing the screen in larger than
19:6 aspect ratios. In this case a problem was reported for ~21:9 which
should be common enough for us to "support" it.
|
| | |
| |
| |
| |
| |
| |
| | |
Idle handlers used to not be executed when timers were active
Now they are executed:
* After all expired timers have been executed
* After all events have been processed (same as when there are no timers)
|
| | |
| |
| |
| |
| |
| | |
Describe ReplayGain album-to-track fallback behavior introduced in
commits e392d6610d1e35cc0190c794c151211b0aae83e6 and
be90f2c8dd0431e252e43d5249e89446309113af.
|
| | |
| |
| |
| |
| |
| |
| | |
Commit e392d6610d1e35cc0190c794c151211b0aae83e6 modified the native
demuxer to use track gain as a fallback for album gain if the latter is
not present. This commit makes functionally equivalent changes in the
libavformat demuxer.
|
| | |
| |
| |
| |
| | |
doing multiply on a property is also a set property command
and the change should be notified so others can observe the change
|
| | |
| |
| |
| |
| |
| | |
Adapt documentation accordingly and
also, fix an off-by-one check in the code.
closes #6371
|
| | | |
|
| | |
| |
| |
| | |
The stream cache no longer exists, so there is no need to show the demuxer cache separately anymore.
|
| | |
| |
| |
| |
| | |
The `streaming` flag covers more cases than just networked streams,
such as files read from NFS, SMB or FUSE mountpoints.
|
| | |
| |
| |
| |
| | |
The default behavior for `does not own stream` should be false, but this
condition is inverted so we need to default the base case to `true`.
|
| | |
| |
| |
| |
| | |
The pointer could be NULL if the number of bytes to copy was 0. In a
sane world, this would be fine, but not the current world.
|
| | |
| |
| |
| |
| |
| | |
If the number of chapters is 0, the chapter list can be NULL. clang
complains that we pass NULL to qsort(). This is yet another pointless UB
that exists for no reason other than wasting your time.
|
| | |
| |
| |
| |
| |
| |
| | |
I found this sort of annoying.
You could argue that the "frontend" should maybe contain this logic, but
who cares.
|
| | |
| |
| |
| |
| |
| | |
Seems to happen often with ytdl pseudo-DASH streams, so whatever. I
couldn't reproduce it and check what triggers it, I just remember seeing
the error message and found it annoying.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I misunderstood how this extension works. If I understand it correctly
now, it's worse than I thought. They key thing is that the (ust, msc,
sbc) tripple is not for a single swap event. Instead, (ust, msc) run
independently from sbc. Assuming a CFR display/compositor, this means
you can at best know the vsync phase and frequency, but not the exact
time a sbc changed value.
There is GLX_INTEL_swap_event, which might work as expected, but it has
no EGL equivalent (while GLX_OML_sync_control does, in theory).
Redo the context_glx sync code. Now it's either more correct or less
correct. I wanted to add proper skip detection (if a vsync gets skipped
due to rendering taking too long and other problems), but it turned out
to be too complex, so only some unused fields in vo.h are left of it.
The "generic" skip detection has to do.
The vsync_duration field is also unused by vo.c.
Actually this seems to be an improvement. In cases where the flip call
timing is off, but the real driver-level timing apparently still works,
this will not report vsync skips or higher vsync jitter anymore. I could
observe this with screenshots and fullscreen switching. On the other
hand, maybe it just introduces an A/V offset or so.
Why the fuck can't there be a proper API for retrieving these
statistics? I'm not even asking for much.
|
| | |
| |
| |
| |
| |
| |
| | |
The redundancy here always annoyed me. Back then I didn't change it
because it's hard to test and I just had fixed something. This doesn't
matter anymore, so simplify it, without testing and with the risk that
something breaks (why care).
|
| | |
| |
| |
| |
| | |
No idea what that shit is. Likely forgotten when timed metadata was
introduced, and some of the old mechanisms were replaced.
|
| | |
| |
| |
| |
| |
| | |
--record-file is nice, but only sometimes. If you watch some sort of
livestream which you want to record, it's actually much nicer not to
record what you're currently "seeing", but anything you're receiving.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In theory, this could be easily done with custom I/O. In practice, all
the halfassed garbage in FFmpeg shits itself and fucks up like there's
no tomorrow. There are several problems:
1. FFmpeg pretends you can do custom I/O, but in reality there's a lot
that custom I/O can do. hls.c even contains explicit checks to disable
important things if custom I/O is used! In particular, you can't use the
HTTP keepalive functionality (needed for somewhat decent HLS
performance), because some cranky asshole in the cursed FFmpeg dev.
community blocked it.
2. The implementation of nested I/O callbacks (io_open/io_close) is
bogus and halfassed (like everything in FFmpeg, really). It will call
io_open on some URLs without ever calling io_close. Instead, it'll call
avio_close() on the context directly. From what I can tell, avio_close()
is incompable to custom I/O anyway (overwhelmed by their own garbage,
the fFmpeg devs created the io_close callback for this reason, because
they couldn't fix their own fucking garbage). This commit adds some
shitty workaround for this (technically triggers UB, but with that
garbage heap of a library we depend on it's not like it matters).
3. Even then, you can't proxy I/O contexts (see 1.), but we can just
keep track of the opened nested I/O contexts. The bytes_read is
documented as not public, but reading it is literally the only way to
get what we want.
A more reasonable approach would probably be using curl. It could
transparently handle the keep-alive thing, as well as propagating
cookies etc. (which doesn't work with the FFmpeg approach if you use
custom I/O). Of course even better if there were an independent HLS
implementation anywhere. FFmpeg's HLS support is so embarrassing
pathetic and just goes to show that they belong into the past
(multimedia from 2000-2010) and should either modernize or fuck off.
With FFmpeg's shit-crusted structures, todic communities, and retarded
assholes denying progress, probably the latter. Did I already mention
that FFmpeg is a shit fucked steaming pile of garbage shit?
And all just to get some basic I/O stats, that any proper HLS consumer
requires in order to implement adaptive streaming correctly (i.e.
browser based players, and nothing FFmshit based).
|
| | |
| |
| |
| | |
it's more like an input speed rather than a cache speed, but who cares.
|
| | |
| |
| |
| | |
So new useless stuff can be easily added.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Use the extension to compute the (hopefully correct) video delay and
vsync phase.
This is very fuzzy, because the latency will suddenly be applied after
some frames have already been shown. This means there _will_ be "jumps"
in the time accounting, which can lead to strange effects at start of
playback (such as making initial "dropped" etc. frames worse). The only
reasonable way to fix this would be running a few dummy frame swaps at
start of playback until the latency is known. The same happens when
unpausing.
This only affects display-sync mode.
Correct function was not confirmed. It only "looks right". I don't have
the equipment to make scientifically correct measurements.
A potentially bad thing is that we trust the timestamps we're receiving.
Out of bounds timestamps could wreak havoc. On the other hand, this will
probably cause the higher level code to panic and just disable DS.
As a further caveat, this makes a bunch of assumptions about UST
timestamps. If there are delayed frames (i.e. we skipped one or more
vsyncs), the latency logic is mostly reset. There is no attempt to make
the vo.c skipped vsync logic to use this. Also, the latency computation
determines a vsync duration, and there's no effort to reconcile or share
the vo.c logic for determining vsync duration.
|
| |\ \
| |/
|/|
| |
| |
| | |
wm4-commits--merge-edition
This bumps libmpv version to 1.103
|
| | |
| |
| |
| |
| |
| | |
The demuxer cache is the only cache now. Might need another change to
combat seeking failures in mp4 etc. The only bad thing is the loss of
cache-speed, which was sort of nice to have.
|
| | | |
|
| | |
| |
| |
| |
| | |
There was no reason to limit this. Only some int fields had to be
changed to size_t.
|
| | |
| |
| |
| |
| |
| |
| | |
FFmpeg is retarded enough not to give us any indication whether it is
(unless we query fields not in the ABI/API). I bet FFmpeg developers
love it when library users have to litter their code with duplicated
information.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Quitting is slightly asynchronous, so the status line can be updated
again. Normally, that's fine, but if quitting comes with a message (such
as with quit_watch_later), it will print the status line again after the
message, which looks annoying. So flush and clear the status message if
it's updated during quitting.
|
| | |
| |
| |
| | |
To get overlapping shit etc.
|
| | |
| |
| |
| |
| | |
This means reselection triggers full reinit. This is better if you have
options that "edit" subtitles or whatever.
|
| | |
| |
| |
| |
| | |
I'm also not sure whether this condition doesn't subtly break a lot of
things.
|
| | |
| |
| |
| | |
Always true, because a few lines above it checks for the same thing.
|
| | |
| |
| |
| |
| | |
This code shouldn't even exist in libavformat. If you still need it, you
can enable it via --demuxer-lavf-o.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If anyone happened to build with GL disabled, this could lead to option
changes not always refreshing the screen. Since vo_gpu is always enabled
now (just not necessarily any backend for it), we can drop the #if
completely.
(The way this works is a bit idiotic - the option cache exists only to
grab the change notification, which will trigger a redraw and make
vo_gpu update its own second copy of them. But at least it avoids some
layering issues for now.)
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Avoids 100% CPU usage due to terminal code retrying read(). Seems like
this was "forgotten" (or there was somehow the assumption poll() would
not signal POLLIN anymore).
Fixes #5842.
|
| | |
| |
| |
| | |
Often requested, trivial.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is working towards a change intended in the future: nothing should
write to the option struct directly, but use functions that raise proper
notifications. Until this is complete it will take a while, and this
commit does not change all cases of direct access, just some simple
ones.
In all of these 3 changes, the actual write access is done by the
generic property-option bridge.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
C11 can access atomic variables normally (in which case they use the
strictest memory access semantics). But the mpv stdatomic wrapper for
C99 compilers does not allow it, because it couldn't give any
guarantees. This means we always need to access them with atomic macros.
While we're at, use relaxed semantics for the m_config_cache field,
since because it's accessed from a single thread only (essentially
used in a non-atomic way). Switch the comparison arguments to make the
formatting look slightly less weird.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Although the new code actually fires update notifications only when
needed, m_config_cache_update() itself returned a rather coarse change
value, which could indicate change even if none of the cached options
were changed. On top of that, some code (like vo_gpu) calls the update
function on every frame, which would reconfigure the renderer even on
unrelated option changes.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
This was always a legacy thing. Remove it by applying an orgy of
mp_get_config_group() calls, and sometimes m_config_cache_alloc() or
mp_read_option_raw().
win32 changes untested.
|
| | |
| |
| |
| |
| |
| |
| | |
The --hwdec* options are a good fit for the vd_lavc local option
struct. This annoyingly requires manual prefixing of most of these
options with --vd-lavc (could be avoided by using more sub-struct
craziness, but let's not).
|
| | |
| |
| |
| |
| |
| |
| | |
The path functions need to access the option that forces non-default
config directories. Just add it as a field to mpv_global - it seems
justified. The accessed options were always enforced as immutable after
init, so there's not much of a change.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Passing NULL to mp_get_config_group() returns the main option struct.
This is just a dumb hack to deal with inconsistencies caused by legacy
things (as I'll claim), and will probably be changed in the future. So
before littering the whole code base with hard to find NULL parameters,
require using callers an easy to find separate define.
|
| | |
| |
| |
| | |
Instead of accessing MPOpts.
|
| | |
| |
| |
| |
| | |
These were deprecated almost 2 years ago. Now they happen to be in the
way.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Options with dynamic memory allocations (such as strings) require some
care. They need to be fully copied on initialization, and if a static
default value was declared, we must not free that value either.
Instead of going through the entire thing even for simple types like
integers, really run it only for options with dynamic allocations. To
distinguish types which use dynamic allocations, we can use the fact
that they require a free callback (otherwise they would leak). As a
result initialization of simple types becomes chaper, and the init
function does nothing at all if src==dst for a simple type.
(It's funny how mplayer had M_OPT_TYPE_DYNAMIC since 2002, until we
replaced it by the same heuristic as used here in commit 3bb134969eb6.
It's also funny how the new check was used only for some asserts, and
finally removed in commit 7539928c1c. I guess at this time I felt like
having uniform code was more important than pointless
micro-optimizations.)
The src==NULL case is removed because it can't happen.
|
| | |
| |
| |
| | |
Just wastes memory (a few KB, because there are so many options).
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
C99 still works, but in theory we're using C11 features already, such as
stdatomic.h. gcc/clang let us use it in C99 mode too, but using C11 is
at least more proper.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Actually rewrite most of the option management code. This affects how
options are allocated, and how thread-safe access to them is done.
One thing that is nicer is that creating m_config_cache does not need to
ridiculously recreate and store the entire option list again. Instead,
option metadata and option storage are now separated. m_config contains
the metadata, and m_config_data all or parts of the actual option
values. (m_config_cache simply uses the metadata part of m_config, which
is immutable after creation.)
The mentioned hack was introduced in commit 1a2319f3e4cc4, and is the
global state around g_group_mutex. Although it was "benign" global
state, it's good that it's finally removed.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
For some reason shadow_offset is a int16_t variable (to save some space
or something), which means the static part of the entire option list
must be below 32KB. This is fine, but still add a check against
overflows. (Currently it's 3.6KB. This does not include dynamic
allocations like strings.)
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
The previous commit removed all uses.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Until now, stopping playback aborted the demuxer and I/O layer violently
by signaling mp_cancel (bound to libavformat's AVIOInterruptCB
mechanism). Change it to try closing them gracefully.
The main purpose is to silence those libavformat errors that happen when
you request termination. Most of libavformat barely cares about the
termination mechanism (AVIOInterruptCB), and essentially it's like the
network connection is abruptly severed, or file I/O suddenly returns I/O
errors. There were issues with dumb TLS warnings, parsers complaining
about incomplete data, and some special protocols that require server
communication to gracefully disconnect.
We still want to abort it forcefully if it refuses to terminate on its
own, so a timeout is required. Users can set the timeout to 0, which
should give them the old behavior.
This also removes the old mechanism that treats certain commands (like
"quit") specially, and tries to terminate the demuxers even if the core
is currently frozen. This is for situations where the core synchronized
to the demuxer or stream layer while network is unresponsive. This in
turn can only happen due to the "program" or "cache-size" properties in
the current code (see one of the previous commits). Also, the old
mechanism doesn't fit particularly well with the new one. We wouldn't
want to abort playback immediately on a "quit" command - the new code is
all about giving it a chance to end it gracefully. We'd need some sort
of watchdog thread or something equally complicated to handle this. So
just remove it.
The change in osd.c is to prevent that it clears the status line while
waiting for termination. The normal status line code doesn't output
anything useful at this point, and the code path taken clears it, both
of which is an annoying behavior change, so just let it show the old
one.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Before this, mpctx->playing was often used to determine whether certain
new state could be added to the playback state. In particular this
affected external files (which added tracks and demuxers). The variable
was checked to prevent that they were added before the corresponding
uninit code. We want to make a small part of uninit asynchronous, but
mpctx->playing needs to stay in the place where it is. It can't be used
for this purpose anymore.
Use mpctx->stop_play instead. Make it never have the value 0 outside of
loading/playback. On unloading, it obviously has to be non-0.
Change some other code in playloop.c to use this, because it seems
slightly more correct. But mostly this is preparation for the following
commit.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This will enable the player core to terminate the demuxers in a "nicer"
way without having to block on network. If it just used demux_free(), it
would either have to block on network, or like currently, essentially
kill all I/O forcefully.
The API is slightly awkward, because demuxer lifetime is bound to its
allocation. On the other hand, changing that would also be awkward, and
introduce weird in-between states that would have to be handled in tons
of places.
Currently unused, to be user later.
|
| | | |
|
| | |
| |
| |
| | |
Be a bit more detailed, and discourage disabling it.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Alway give each demuxer its own mp_cancel instance. This makes
management of the mp_cancel things much easier. Also, instead of having
add/remove functions for mp_cancel slaves, replace them with a simpler
to use set_parent function. Remove cancel_and_free_demuxer(), which had
mpctx as parameter only to check an assumption. With this commit,
demuxers have their own mp_cancel, so add demux_cancel_and_free() which
makes use of it.
|
| | |
| |
| |
| |
| |
| |
| | |
Them being separate is just dumb. Replace them with a single
demux_free() function, and free its stream by default. Not freeing the
stream is only needed in 1 special case (demux_disc.c), use a special
flag to not free the stream in this case.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The player fully restarts playback when the edition or disk title is
changed. Before this, the player tried to reinitialized playback
partially. For example, it did not print a new "Playing: <file>"
message, and did not send playback end to libmpv users (scripts or
applications).
This playback restart code was a bit messy and could have unforeseen
interactions with various state. There have been bugs before. Since it's
a mostly cosmetic thing for an obscure feature, just change it to a full
restart. This works well, though since it may have consequences for
scripts or client API users, mention it in interface-changes.rst.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The properties/commands touched in this commit are all for obscure
special inputs (BD/DVD/DVB/TV), and they all block on the demuxer/stream
layer. For network streams, this blocking is very unwelcome. They will
affect playback and probably introduce pauses and frame drops. The
player can even freeze fully, and the logic that tries to make playback
abortable even if frozen complicates the player.
Since the mentioned accesses are not needed for network streams, but
they will block on network streams even though they're going to fail,
add a flag that coarsely enables/disables these accesses. Essentially it
establishes a whitelist of demuxers/streams which support them.
In theory you could to access BD/DVD images over network (or add such
support, I don't think it's a thing in mpv). In these cases these
controls still can block and could even "freeze" the player completely.
Writing to the "program" and "cache-size" properties still can block
even for network streams. Just don't use them if you don't want freezes.
|
| | |
| |
| |
| | |
It's also dumb.
|
| | |
| |
| |
| |
| | |
The behavior of mp_thread_pool_queue() doesn't or shouldn't change, but
the new helper function requires touching its logic.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Don't allow it to freeze everything when loading a playlist from network
(although you definitely shouldn't do that, but whatever).
This also affects the really obscure --ordered-chapters-files option.
The --playlist option on the other hand has no choice but to freeze the
shit, because there's no concept of aborting the player during command
line parsing.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Until now, they could be aborted only by ending playback, and calling
mpv_abort_async_command didn't do anything.
This requires furthering the mess how playback abort is done. The main
reason why mp_cancel exists at all is to avoid that a "frozen" demuxer
(blocked on network I/O or whatever) cannot freeze the core. The core
should always get its way. Previously, there was a single mp_cancel
handle, that could be signaled, and all demuxers would unfreeze. With
external files, we might want to abort loading of a certain external
file, which automatically means they need a separate mp_cancel. So give
every demuxer its own mp_cancel, and "slave" it to whatever parent
mp_cancel handles aborting.
Since the mpv demuxer API conflates creating the demuxer and reading the
file headers, mp_cancel strictly need to be created before the demuxer
is created (or we couldn't abort loading). Although we give every
demuxer its own mp_cancel (as "enforced" by cancel_and_free_demuxer),
it's still rather messy to create/destroy it along with the demuxer.
|
| | |
| |
| |
| |
| | |
Instead of relying on demuxer->stream->cancel. This is better because
the stream is potentially closed and replaced.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The intention is to avoid that the parent mp_cancel retains the
internally allocated wakeup pipe. File FDs are a relatively scarce
resource, so try to avoid having too many. This might matter for
subtitle files, for which it is relatively likely that they are loaded
in large quantities.
demux_lavf.c will close the underlying stream for most subtitle files,
and now it will free the wakeup pipe too. Actually, there are currently
only 1 or 2 mp_cancel objects per mpv core, but this could change if
every external subtitle track gets its own mp_cancel in later commits.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The OS specifics are merged because the resulting ifdeffery is not much
worse than the old ifdeffery, but the logic that is now shared is
becoming more complex.
Create all objects lazily. The intention is to make mp_cancel instances
cheaper. POSIX pipes and win32 Events are pretty heavy weight, and are
only needed in special situations.
Add a mechanism to "chain" mp_cancel instances. Needed by the later
commits for whatever reasons.
Untested on win32.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This provides macros for managing intrusive doubly linked lists.
There are many ways how to do those in a "generic" way in C. For example
Solaris style lists are pretty nice:
https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/common/sys/list.h
https://github.com/illumos/illumos-gate/blob/master/usr/src/common/list/list.c
I even have an independent implementation of this, which could be ISC
licensed. But I think it's easier to vomit ~100 lines of preprocessor
garbage, which has a lower footprint, and I think it wins slightly on
the side of type safety, simplicity, and ease of use, even if it doesn't
look as magically nice.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
It seems a bit inappropriate to have dumped this into stream.c, even if
it's roughly speaking its main user. At least it made its way somewhat
unfortunately to other components not related to the stream or demuxer
layer at all.
I'm too greedy to give this weird helper its own file, so dump it into
thread_tools.c.
Probably a somewhat pointless change.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This flag is used only by the command parser. Its value overlapped with
some of the existing m_option flags, but only flags that did not matter
for the command parser (i.e. the flag bits used had mostly private uses
in each component). It's still a bit unclean and dangerous to use an
essentially random value, so reuse M_OPT_OPTIONAL_PARAM for it.
Since M_OPT_OPTIONAL_PARAM has a slightly longer name than
MP_CMD_OPT_ARG, I'm going to keep the old name.
|
| | |
| |
| |
| |
| | |
Output argument names, whether varargs are used, and indicate optional
arguments correctly (instead of only half of them).
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Before this change, only 1 command or so had named arguments. There is
no reason why other commands can't have them, except that it's a bit of
work to add them.
Commands with variable number of arguments are inherently incompatible
to named arguments, such as the "run" command. They still have dummy
names, but obviously you can't assign multiple values to a single named
argument (unless the argument has an array type, which would be
something different). For now, disallow using named argument APIs with
these commands. This might change later.
2 commands are adjusted to not need a separate default value by changing
flag constants. (The numeric values are C only and can't be set by
users.)
Make the command syntax in the manpage more consistent. Now none of the
allowed choice/flag names are in the command header, and all arguments
are shown with their proper name and quoted with <...>.
Some places in the manpage and the client.h doxygen are updated to
reflect that most commands support named arguments. In addition, try to
improve the documentation of the syntax and need for escaping etc. as
well.
(Or actually most uses of the word "argument" should be "parameter".)
|
| | |
| |
| |
| |
| | |
Also clarify this and previously existing differences to standard JSON
in ipc.rst.
|
| | |
| |
| |
| |
| |
| | |
Make use the escape sequences allowed by JSON.
Also update the linked RFC to the newest one.
|
| | |
| |
| |
| | |
This should have been done sooner.
|
| | |
| |
| |
| |
| | |
(Slightly oddly function names, because I want to avoid starting them
with mpv_*, which is reserved for public API.)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When changing video filters during initialization, there was a small
time window where video was initialized, but playback restart was not
complete yet. In this time window, playback_pts is not set. But since
issue_refresh_seek() was using this, it could lead to no refresh being
done _if_ the "video" had only 1 frame (such as cover art).
Fix this by using get_current_time() instead, which is the current time
with corner cases such as ongoing loading or seeks taken into account.
See also the previous commit. Without that, get_current_time() could
return NOPTS during init.
Fixes #5831.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is nonsense. Didn't matter in most situations, because seeking
itself set this after it was cleared. But some callers don't do this,
see e.g. commit ed73ba89644fc6. There is no need to clear it at all, and
it causes issues with the next commit. It only needs to be reset on
loading.
Also move the initialization on loading up, which doesn't change
behavior, but makes the intention clearer.
|
| | |
| |
| |
| |
| | |
For example, we call setmode() to switch a FD from text to binary mode
on garbage OSes.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There is some code that checks a FD for whether it is a regular file or
not. If it's not a regular file, it e.g. enables use of poll() to avoid
blocking forever.
But this was done only for FDs that were open()ed by us, not from stdin
special handling or fd://. Consequently, " | mpv -" could block the
player. Fix this by moving the code and running for it on all FDs.
Also, set p->regular_file even on mingw.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The default get_format does exactly do this, so we don't need to
duplicate it.
The only potential problem with this is that the logic doesn't entirely
prevent that the avcodec_default_get_format hw_device_ctx path is
triggered, which would probably work, but has unknown consequences and
interactions. But the way the logic currently works it can't happen,
provided the hwaccel metadata libavcodec provides is correct.
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
If a stream starts later than the others at the start of the file, it
shouldn't restrict the seek range to the time stamp where it begins.
This is similar to the previous commit, just for the other end.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Normally, the seek range is the minimum overlap of the cached ranges of
each stream. But if one of the streams ends earlier, this leads to the
seek range getting cut off, even if you could seek there.
Change it so that EOF streams cannot restrict the end of the seek range.
They can only extend it. This is the opposite from not-EOF streams, so
they need to be handled separately. In particular, they get exluded from
normal end range calculation, but when full EOF is reached, all streams
are EOF, and the maximum end time can be used to set the seek end time.
(In theory we could also take the max with the demuxer signaled total
file duration, but let's not for now.)
Also, if a stream is completely empty, essentially skip it, instead of
considering the range unseekable. (Also, we don't need to mess with
seek_start in this case, because it will be NOPTS and is skipped
anyway.)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When the current packet queue was completely empty, and EOF was reached,
the queue->is_eof flag was not correctly set to true. Change this by
reading ds->eof to check whether the stream is considered EOF. We also
need to make sure update_seek_ranges() is called in this case, so change
the code to simply call it when queue->is_eof changes.
Also, read_packet() needs to call adjust_seek_range_on_packet() if
ds->eof changes. In that case, the decoder also needs to be notified
about EOF. So both of these should be called when ds->eof changes to
true. (Other code outside of this function deals with the case when
ds->eof is changed to false.)
In addition, this code was kind of shoddy about calling wakeup_ds()
correctly. It looks like there was an inverted condition, and sent a
wakeup to the decoder only when ds->eof was already true, which is
obviously bogus. The final EOF case tried to be somehow clever about
checking in->last_eof for notifying the codec, which is sort of OK, but
seems to be strictly worse than just checking whether ds->eof changed.
Fix these things.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This affects async commands started by client API, commands with async
capability run in a sync way by client API (think mpv_command_node()
with "subprocess"), and detached async work.
Since scripts might want to do some cleanup work (that might involve
launching processes, don't ask), we don't unconditionally kill
everything on exit, but apply an arbitrary timeout of 2 seconds until
async commands are aborted.
|
| | |
| |
| |
| | |
ffm (ffserver) was removed from ffmpeg.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I wanted to put all commands through mpv_command_node_async() instead of
mpv_command_node(). Using synchronous commands over a synchronous
transport doesn't make sense anyway.
This would have used the request_id field in IPC requests as reply ID
for the async commands. But the latter need to be [u]int64, while the
former can be any type. To avoid that we need an extra lookup table for
mapping reply IDs to request_id values, we now require that request_id
fields are integers.
Since this would be an incompatible change, just deprecate non-integers
for now, and plan the change for a later time.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
The only effective difference is that the former explicitly checks
whether the JSON value type is string, and errors out if not. The rest
is exactly the same (mpv_set_property_string is mpv_set_property with
MPV_FORMAT_STRING).
It seems silly to keep this, so just remove it.
|
| | |
| |
| |
| | |
Also somewhat cleans up mp.command_native_async() error handling.
|
| | |
| |
| |
| | |
Now mpv_abort_async_command() can be used to stop the process.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Many asynchronous commands are potentially long running operations, such
as loading something from network or running a foreign process.
Obviously it shouldn't just be possible for them to freeze the player if
they don't terminate as expected. Also, there will be situations where
you want to explicitly stop some of those operations explicitly. So add
an infrastructure for this.
Commands have to support this explicitly. The next commit uses this to
actually add support to a command.
|
| | |
| |
| |
| |
| |
| | |
If a struct as large as MPContext contains a field named "lock", it
creates the impression that it is the primary lock for MPContext. This
is wrong, the lock just protects a single field.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
The "run" command is old. I'm not sure why the separate Lua
implementation was added. But maybe it as because the "run" command used
to be limited to a small number of arguments. This limit has been
removed a while ago. In any case, the old implementation is not needed
anymore.
|
| | |
| |
| |
| |
| |
| |
| | |
We keep mp.subprocess() with roughly the same semantics for
compatibility with scripts (including the internal ytdl script).
Seems to work with rhe ytdl wrapper. Not tested further.
|
| | |
| |
| |
| |
| |
| |
| | |
This supports named arguments. It benefits from the infrastructure of
async commands.
The plan is to reimplement Lua's utils.subprocess() on top of it.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Named arguments should make it easier to have long time compatibility,
even if command arguments get added or removed. They're also much nicer
for commands with a large number of arguments, especially if many
arguments are optional.
As of this commit, this can not be used, because there is no command yet
which supports them. See the following commit.
|
| | |
| |
| |
| | |
This particular one is needed in a following commit.
|
| | | |
|
| | |
| |
| |
| |
| | |
If the container FPS is correct, this can help getting ideal mix factors
for vo_gpu interpolation mode. Otherwise, it doesn't matter.
|
| | |
| |
| |
| | |
(Why the fuck are there up to 20 mouse buttons?)
|
| | | |
|
| | |
| |
| |
| | |
Might be useful for some.
|
| | |
| |
| |
| | |
Matters only to API callers, but still nice to have.
|
| | |
| |
| |
| |
| | |
All other callers had to be changed, so there's no point in keeping this
helper function around. It's just another unnecessary indirection.
|
| | |
| |
| |
| | |
This was not done sooner out of laziness.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Both asynchronous and synchronous calls used to be put into the core's
dispatch queue. Also, asynchronous calls were actually synchronous, just
without forcing a wait on the client's thread. This meant that both
kinds of calls were always strictly ordered.
A longer time ago, synchronous calls were changed to simply lock the
core. This could possibly lead to reordering. Recently, some commands
were changed to run on worker threads, which made the order even looser.
Also remove another now incorrect doxygen comment regarding async
commands.
|
| | |
| |
| |
| | |
This was forgotten in commit fb9bbf2a0d7f8.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Basically reimplement the async behavior on top of the async command
code. With this, all screenshot commands are async, and the "async"
prefix basically does nothing. The prefix now behaves exactly like with
other commands that use spawn_thread.
This also means using the prefix in the preset input.conf is pointless
(without effect) and misleading, so remove that.
The each_frame mode was actually particularly painful in making this
change, since the player wants to block for it when writing a
screenshot, and generally doesn't fit into the new infrastructure. It
was still relatively easy to reimplement by copying the original command
and then repeating it on each frame. The waiting is reentrant now, so
move the call in video.c to a "safer" spot.
One way to observe how the new semantics interact with everything is
using the mpv repl script and sending a screenshot command through it.
Without async flag, the script will freeze while writing the screenshot
(while playback continues), while with async flag it continues.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Commands are not a monolithic giant switch() statement anymore, but
individual functions. There's no reason to have the command handlers
themselves in command.c, with a weird under-defined API in between.
(In the future, I'd like to split up command.c further, and when I do
that, scrrenshot.c will probably gets its own mp_cmd_def[] array, and
define the commands locally instead of exporting the raw handlers.)
|
| | | |
|
| | |
| |
| |
| |
| | |
Still missing: not freezing when removing a track (i.e. closing demuxer)
with the sub-remove/audio-remove/rescan-external-files commands.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Basically, the ytdl_hook script will not terminate the script, even if
you change to a new playlist entry. This happens because ytdl_hook keeps
the player core in an early loading stage, and the forceful playback
abort is done only in the ermination code.
This does not handle the "stop" and "quit" commands, which can still
take longer than expected, but on the other hand have some weird special
handling (see below). I'm not doing this out of laziness. Playback
stopping will have to be somewhat redone anyway. Basically we want to
give everything a chance to terminate, and if it doesn't work, we want
to stop loading or playback forcefully after a small timeout. We also
want to remove the mess with input.c's special handling of "quit" and
some other commands (see abort_playback_cb stuff).
|
| | |
| |
| |
| |
| |
| | |
It seems the ytdl script like to continue loading external tracks even
if loading was aborted. Trying to do so will still quickly fail, but not
without a load of log noise. So check and error out early.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Pretty trivial, since commands can be async now, and the common code
even provides convenience like running commands on a worker thread.
The only ugly thing is that mp_add_external_file() needs an extra flag
for locking. This is because there's still some code which calls this
synchronously from the main thread, and unlocking the core makes no
sense there.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This enables two types of command behavior:
1. Plain async behavior, like "loadfile" not completing until the file
is fully loaded.
2. Running parts of the command on worker threads, e.g. for I/O, such as
"sub-add" doing network accesses on a thread while the core
continues.
Both have no implementation yet, and most new code is actually inactive.
The plan is to implement a number of useful cases in the following
commits.
The most tricky part is handling internal keybindings (input.conf) and
the multi-command feature (concatenating commands with ";"). It requires
a bunch of roundabout code to make it do the expected thing in
combination with async commands.
There is the question how commands should be handled that come in at a
higher rate than what can be handled by the core. Currently, it will
simply queue up input.conf commands as long as memory lasts. The client
API is limited by the size of the reply queue per client. For commands
which require a worker thread, the thread pool is limited to 30 threads,
and then will queue up work in memory. The number is completely
arbitrary.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The existing thread pool code is the most primitive thread pool
possible. That's fine, but one annoying thing was that it used a static
number of threads. Make it dynamic, so we don't need to "waste" idle
threads.
This tries to add threads as needed. If threads are idle for some time,
destroy them again until a minimum number of threads is reached.
Also change the license to ISC.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This has some tricky interactions. In particular, it requires the core
to be locked due to reading outstanding_async, which is documented on
the only caller only. It's probably better to merge it with its only
caller.
The new code should be strictly equivalent, other than the fact that it
doesn't temporarily unlock+lock when entering the loop for the first
time (which doesn't matter here).
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is almost like rendezvous(), except it allows async wakeup, and
does not require global state. It will be used by a later commit.
struct mp_waiter is intended to be allocated on the stack, and uses an
initializer including PTHREAD_MUTEX_INITIALIZER. This is the first case
in mpv that it uses PTHREAD_MUTEX_INITIALIZER for stack-allocated
mutexes. It seems POSIX still does not allow this formally, but since
POSIX is worth less than used toilet paper, I don't really care. Modern
OSes use futexes, which means you can make _every_ memory location a
lock, and this code tries to make use of it, without using OS specific
code.
The name of the source file is rather generic, because I intend to dump
further small helpers there (or maybe move mp_rendezvous() to it).
|
| | |
| |
| |
| | |
This was accidentally moved together with the cmd stuff.
|
| | |
| |
| |
| | |
Pretty annoying.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This option has been deprecated upstream for a long time, probably
doesn't even work anymore, and won't work moving forwards as we replace
the vulkan code by libplacebo wrappers.
I haven't removed the option completely yet since in theory we could
still add support for e.g. a native glslang wrapper in the future. But
most likely the future of this code is deletion.
As an aside, fix an issue where the man page didn't mention d3d11.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This commit bumps the libmpv version to 1.102
drm-osd-plane -> drm-draw-plane
drm-video-plane -> drm-drmprime-video-plane
drm-osd-size -> drm-draw-surface-size
"draw plane", as in the plane that OpenGL draws to, whether it be
video + OSD or just OSD.
"drmprime video plane", as in the plane used for hwdec video imported
via drmprime.
"draw surface size", as in the size of the surface used for the draw plane
The new names are invariant whether or not hwdec_drmprime_drm is being
used or not. The original naming was very confusing, as when doing
regular rendering (swdec or vaapi) the video would be displayed on the
"OSD plane", and the "Video plane" would remain unused.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add general primary/overlay plane option to drm-osd-plane-id and
drm-video-plane-id, so that the user can just request any usable
primary or overlay plane for either of these two options. This should
be somewhat more user-friendly (especially as neither of these two
options currently have a useful help function), as usually you would
only be interested in the type of the plane, and not exactly which
plane gets picked.
|
| | |
| |
| |
| |
| | |
Extra line prevents the sub-title formatting.
Removing it, the option is formatted like the others.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
By design, some vulkan implementations block until vsync during
vkAcquireNextImageKHR. Since mpv only considers the time that
`swap_buffers` spent blocking as constituting part of the vsync, we can
help it out a bit by pre-emptively calling this function here in order
to improve the accuracy of vsync jitter measurements on vulkan.
(If it fails, we just ignore the error and have the user call it a
second time later - maybe it will work then)
On my system this drops vsync-jitter from ~0.030 to ~0.007, an accuracy
of +/- 100μs. (Which *might* have something to do with the fact that
this is the polling interval for command polling)
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Makes performance slightly better when using multiple queues by avoiding
unnecessary semaphores due to bad queue selection.
Also remove an aeons-old workaround for an nvidia bug that only ever
existed in the earliest beta vulkan drivers anyway.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Historically, there's been no way to offer deinterlacing with nvdec,
and for cuviddec, it required a command line flag, with no way to
toggle while playing.
Now that we have a cuda deinterlacing filter in ffmpeg, we can hook
it up hook it up as the cuda auto-deinterlacer. In practice, this
isn't going to be present very often, due to the licensing mess with
the cuda sdk, but we can support it when it is there.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
We are currently unnecessarily including vulkan headers even when
not building with vulkan support. I also guarded the GL header
inclusion even though this doesn't appear to break anything today.
Fixes #6330.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This makes the default fit on screen, autofit and window-scale
changing behavior to use the screen working area, instead of
the whole screen area.
As a result mpv window doesn't cover the taskbar now when opening
videos with size larger than the screen size.
The actual behavior now is the same as expected behavior for
usecases 1-4 from #4363.
This commit also removes the screenrc from w32 struct.
The screen rect can now be retrieved via `get_screen_area` function,
which was renamed from `update_screen_rect`.
On a multi-monitor system, if the user moved the window between
monitors, this function will return the current screen area under
the window, and not the screen area from monitor specified by
`--screen` option. The `--screen` option sets the initial monitor
the mpv window is displayed on.
|
| | |
| |
| |
| |
| |
| | |
Returning -1 in a function with return type bool is the same as
returning true. In the error paths, false should be returned to
indicate that something went wrong.
|
| | |
| |
| |
| | |
Fixes #6272.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
depending on the capabilities of the system and testing of various
attributes the resulting CGL pixel format can change. due to that
probing it can be helpful to know which pixel format is used to create
the CGL context. added some verbose logging that outputs final pixel
format.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
this adds support for GPU rendered screenshots, DR (theoretically) and
possible other advanced functions in the future that need to be executed
from the rendering thread.
additionally frames that would be off screen or not be displayed when on
screen are being dropped now.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
`vkGetPhysicalDeviceProperties2KHR` was added in Vulkan 1.0.39,
but 1.0.61 from Ubuntu Xenial (16.04) was the lowest anyone tried
to build mpv with as of late, so we are marking that as the minimum
required version.
This fixes issues arising during build time from having too old
version of vulkan available on a system, instead of causing a failure
to build.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
I was inconsistent about this originally, as the functionality was
moved into the core spec in 1.1 and so both suffixed and unsuffixed
versions of everything exist and can be mixed together.
There's no reason to fail to build with 1.0.39+ so I'm fixing the
names.
|
| | |
| |
| |
| |
| |
| | |
On my system, when trying to use mpv with a read-only fd created by
python 3.7, `send` triggers ENOTSOCK, not EBADF. Extend the logic to
detect non-writable fds by this `errno`.
|
| | |
| |
| |
| |
| |
| | |
The buffer is written to in `audio_config_to_str_buf` using `snprintf`
with a `%s` formatting of a 128-byte buffer. This can overflow the
target buffer of 80 causing a truncated output.
|
| | |
| |
| |
| |
| |
| |
| | |
The `strncpy` function will not always place a terminating `NUL` if the
source is longer than the destination buffer. Instead, let `strncpy`
truncate as it normally would, but leave the last byte alone (it is
zero-initialized when declared).
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Currently, the error paths in init() are a bit confusing, and we can
end up trying to pop the current context when there is no context,
which leads to distracting error messages.
I also added an explicit path to return early if the GPU backend is
not OpenGL or Vulkan. It's pointless to do any other cuda init
after that point. (Of course, someone could write more interops.)
Fixes #6256
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Apparently, for bit streaming DTS-HD MA is specified to be handled as an
eight channel (7.1) bit stream, while DTS-HD HRA is specified to be
handled as a stereo bit stream.
Define a variable for this, and utilize it to set the correct values
for both the DTS-HD bit streaming rate, as well as the channel count
for the SPDIF encoder.
Fixes #6148
|
| | |
| |
| |
| |
| |
| | |
when passed as a string check_cc tries to split that string, since it
assumes that several include paths can be passed to it. instead we just
use a list to make it unambiguous.
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
that way we don't need to quote or escape anything.
Fixes #6220
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Since 810acf32d6cf0dfbad66c602689ef1218fc0a6e3 video_plane can be NULL
under some circumstances. While there is a check in init, init treats
this as an error condition and would call uninit, which in turn calls
disable_video_plane, which would then segfault. Fix this by including
a NULL check inside disable_video_plane, so that it doesn't try to
disable what isnt' there.
|
| | |
| |
| |
| | |
strncpy does not guarantee that the string will be NULL-terminated.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Despite their place in the tree, hwdecs can be loaded and used just
fine by the vulkan GPU backend.
In this change we add Vulkan interop support to the cuda/nvdec hwdec.
The overall process is mostly straight forward, so the main observation
here is that I had to implement it using an intermediate Vulkan buffer
because the direct VkImage usage is blocked by a bug in the nvidia
driver. When that gets fixed, I will revist this.
Nevertheless, the intermediate buffer copy is very cheap as it's all
device memory from start to finish. Overall CPU utilisiation is pretty
much the same as with the OpenGL GPU backend.
Note that we cannot use a single intermediate buffer - rather there
is a pool of them. This is done because the cuda memcpys are not
explicitly synchronised with the texture uploads.
In the basic case, this doesn't matter because the hwdec is not
asked to map and copy the next frame until after the previous one
is rendered. In the interpolation case, we need extra future frames
available immediately, so we'll be asked to map/copy those frames
and vulkan will be asked to render them. So far, harmless right? No.
All the vulkan rendering, including the upload steps, are batched
together and end up running very asynchronously from the CUDA copies.
The end result is that all the copies happen one after another, and
only then do the uploads happen, which means all textures are uploaded
the same, final, frame data. Whoops. Unsurprisingly this results in
the jerky motion because every 3/4 frames are identical.
The buffer pool ensures that we do not overwrite a buffer that is
still waiting to be uploaded. The ra_buf_pool implementation
automatically checks if existing buffers are available for use and
only creates a new one if it really has to. It's hard to say for sure
what the maximum number of buffers might be but we believe it won't
be so large as to make this strategy unusable. The highest I've seen
is 12 when using interpolation with tscale=bicubic.
A future optimisation here is to synchronise the CUDA copies with
respect to the vulkan uploads. This can be done with shared semaphores
that would ensure the copy of the second frames only happens after the
upload of the first frame, and so on. This isn't trivial to implement
as I'd have to first adjust the hwdec code to use asynchronous cuda;
without that, there's no way to use the semaphore for synchronisation.
This should result in fewer intermediate buffers being required.
|
| | |
| |
| |
| | |
We need this to do device matching for the cuda interop.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
This is arguably a little contrived, but in the case of CUDA interop,
we have to track additional state on the cuda side for each exported
buffer. If we want to be able to manage buffers with an ra_buf_pool,
we need some way to keep that CUDA state associated with each created
buffer. The easiest way to do that is to attach it directly to the
buffers.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The CUDA/Vulkan interop works on the basis of memory being exported
from Vulkan and then imported by CUDA. To enable this, we add a way
to declare a buffer as being intended for export, and then add a
function to do the export.
For now, we support the fd and Handle based exports on Linux and
Windows respectively. There are others, which we can support when
a need arises.
Also note that this is just for exporting buffers, rather than
textures (VkImages). Image import on the CUDA side is supposed to
work, but it is currently buggy and waiting for a new driver release.
Finally, at least with my nvidia hardware and drivers, everything
seems to work even if we don't initialise the buffer with the right
exportability options. Nevertheless I'm enforcing it so that we're
following the spec.
|
| | |
| |
| |
| | |
Fixes #6212
|
| | |
| |
| |
| |
| |
| | |
Since the code just broke out of the loop on a match rather than jumping
straight to the end of the function body, it ended up hitting the code
path for when the end of the list was reached.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
since we draw our own title bar we lose the standard functionality of
the system provided title bar. because of that we have to reimplement
the functionality of double clicking the title bar. depending on the
system preferences we want to minimize, zoom or do nothing.
Fixes #6223
|
| | |
| |
| |
| |
| |
| | |
Fixes GCC8 warning
../video/out/gpu/spirv.c: In function 'spirv_compiler_init':
../video/out/gpu/spirv.c:68:9: warning: 'strncpy' specified bound 32 equals destination size [-Wstringop-truncation]
|
| | |
| |
| |
| |
| |
| |
| |
| | |
On a multi monitor setup, when the center of the window was going off
screen, the icc profile would always switch to the profile of the first
screen.
This fixes the issue by defaulting the value to the current screen.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This was pased on the texture height, which was a mistake. In some cases
it could exceed the actual size of the buffer, leading to a vulkan API
error. This didn't seem to cause any problems in practice, since a
too-large synchronization is just bad for performance and shouldn't do
any harm internally, but either way, it was still undefined behavior to
submit a barrier outside of the buffer size.
Fix the calculation, thus fixing this issue.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Since linear downscaling makes sense to handle independently from
linear/sigmoid upscaling, we split this option up. Now,
linear-downscaling is its own option that only controls linearization
when downscaling and nothing more. Likewise, linear-upscaling /
sigmoid-upscaling are two mutually exclusive options (the latter
overriding the former) that apply only to upscaling and no longer
implicitly enable linear light downscaling as well.
The old behavior was very confusing, as evidenced by issues such
as #6213. The current behavior should make much more sense, and only
minimally breaks backwards compatibility (since using linear-scaling
directly was very uncommon - most users got this for free as part of
gpu-hq and relied only on that).
Closes #6213.
|
| | |
| |
| |
| |
| |
| | |
Using strtol and strtoul is allegedly better practice, and I'm going
for strtoul here because I'm pretty sure X11 displays cannot be in
the negative.
|
| | |
| |
| |
| |
| |
| |
| | |
This deinit code was never checked, so this line would always crash on
implementations without support for sync objects.
Fixes #6197.
|
| | |
| |
| |
| |
| |
| |
| | |
Someone on IRC pointed out that the default stats bindings weren't
documented in the interactive control section of the manual, so
let's add them with a short mention and a reference to the STATS
section of the manual.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
when entering a Split View a windowDidEnterFullScreen event happens
without a previous toggleFullScreen call. in that case it tries to stop
an animation that was never initiated by us and basically breaks the
system initiated fullscreen, or in this case the Split View. immediately
after entering the fullscreen it tries top stop the animation and
resizes the window, which causes the window to exit fullscreen. only
try to stop an animation that was initiated by us and is safe to stop.
|
| | |
| |
| |
| |
| |
| | |
This prevents crashes when loading the application icon image.
Suggested-by: Akemi <der.richter@gmx.de>
|
| | |
| |
| |
| |
| |
| |
| |
| | |
without assistive-device permissions the event tap can't be create on
10.14 any more which lead to an assertion.
System Preferences > Security & Privacy > Privacy > Accessibility and
add mpv or your terminal App to the list.
|
| | |
| |
| |
| |
| | |
We're doing the same thing as the primary path - just that we log
and set 'failed' to true.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Since this function is called with packets on the stack, trying to free
them makes no sense. Instead, it should unref (which is what
`av_interleaved_write_frame` does anyway, rather than freeing).
Also, the calling code tried unreffing the packet a second time, even
after it was "freed" by the callee in the failure case - and after
ownership was taken over by `av_interleaved_write_frame` in the
successful case. Both of these cases were wrong.
|
| | |
| |
| |
| | |
Useful in particular with ytdl, where you never know what you get.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I encountered a stream that fails with "Could not demux init fragment.".
It turns out this is a regression from the recent change to that code.
The assumption was that demux_lavf.c would treat this as concatenated
stream - which it does, but not for probing.
Doing this transparently is hard without doing it properly. Doing it
properly would mean creating some sort of stream_concat (reminiscent of
that FFmpeg security bug). I probably don't want to go there, and I
think libavformat should just support this directly, so whatever.
Hack-fix this with the knowledge that the init segment will always
contain the headers.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This happened with a .flac file inside an archive. It tried to seek
beyond the end of the archive entry in a format where seeking isn't
supported. stream_libarchive handles these situations by skipping data.
But when the end of the archive is reached, archive_read_data() returns
0. While libarchive didn't bother to fucking document this, they do say
it's supposed to work like read(), so I guess a return value of 0 really
means EOF. So change the "< 0" to "<= 0". Also add some error logging.
The same file actually worked without out of bounds reads when
extracted, so there still might be something very wrong.
|
| | | |
|
| | |
| |
| |
| |
| | |
There was no reason to limit this. Only some int fields had to be
changed to size_t.
|
| | |
| |
| |
| |
| |
| |
| | |
FFmpeg is retarded enough not to give us any indication whether it is
(unless we query fields not in the ABI/API). I bet FFmpeg developers
love it when library users have to litter their code with duplicated
information.
|
| | |
| |
| |
| |
| | |
AudioUnit output driver uses the pull based api so it should have
a reset function instead of a pause function.
|
| | |
| |
| |
| |
| |
| | |
by default the pixel format creation falls back to software renderer
when everything fails. this is mostly needed for VMs. additionally one
can directly request an sw renderer or exclude it entirely.
|
| | |
| |
| |
| |
| |
| |
| | |
moved the retrieval of the macOS specific options from the backend
initialisation to the initialisation of the CocoaCB class, the earliest
point possible. this way macOS specific options can be used for the
opengl context creation for example.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
This fixes the line under the header, creates a title header, and
slightly improves list formatting.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is to improve the experience when running with default settings
on a driver that doesn't have any overlay planes (or indeed only one
plane), but still supports DRM atomic. Since the drmprime video plane
is set to pick an overlay plane by default it would fail on these
drivers due to not being able to create any atomic context. Users with
such cards had to specify --drm-video-plane-id manually to some bogus
value (it's not used after all).
The "video" plane is only ever used by the drmprime-drm hwdec interop,
which is not used at all in the typical usecase where everything is
actually rendered on to the "OSD" plane using EGL, so having an atomic
context without the "video" plane should be fine most of the time.
|
| | |
| |
| |
| | |
Looking at other examples, a bar should be used when listing OPT_CHOICE options.
|
| | |
| |
| |
| | |
for the rawaudio demuxer to do the expected gapless playback
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
For vec3, the alignment and size differ. The current code will pack a
struct like { vec3; float; vec2 } into 8 machine words, whereas the spec
would only use 6.
This actually fixes a real bug: The only place in the code I could find
where it was conceivably possible that a vec3 is followed by a float was
when using --gpu-dumb-mode in combination with --gamma-factor, and only
when --gpu-api=vulkan. So it's no surprised nobody ran into it yet.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
These used to be unsupported long ago, but it seems glslang added
support in the meantime. (I don't know which version, but I'm guessing
it was long enough ago that we don't have to add a feature check)
Should hopefully help make push constant layouts more robust against
possible bugs either in our code or in the driver.
|
| | |
| |
| |
| |
| | |
The ALSA state generally can tell us more information in case we
get an unexpected error.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
According to ALSA doxy, EPIPE is a synonym to SND_PCM_STATE_XRUN,
and that is a state that we should attempt to automatically recover
from. In case recovery fails, log an error and return zero.
A warning message will still be output for each XRUN since those
are not something we should generally be receiving.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This has been way too long coming, and for me to notice that a
whole lot of ao_alsa functions do an early return if the AO is
paused.
For the STATE_SETUP case, I had this reproduced once, and never
since. Still, seems like we can start calling this function before
the ALSA device has been fully initialized so we might as well
early exit in that case.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Certain low-end Mali GPUs have a rather low precision and overflow
during the PRNG calculations, thereby breaking e.g. deband-grain.
Modify the permute() to avoid this, this does not impact the
quality of PRNG output (noticeably).
This problem was observed on:
GL_VENDOR='ARM', GL_RENDERER='Mali-T720'
GL_VERSION='OpenGL ES 3.1 v1.r15p0-00rel0.bdd9e62cdc8c88e0610a16b5901161e9'
|
| | | |
|
| | |
| |
| |
| |
| | |
This prevents ao_jack from auto-connecting to MIDI ports (or other,
hypothetical future port types).
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
mpctx->current_track[0][STREAM_VIDEO] (and STREAM_AUDIO) are empty when
using --lavfi-complex. Moving the muxer stream hinting after audio/video chain
initialization and checking if the chains exist fixes encoding with --lavfi-complex.
Previously, the output audio/video streams did not get prepared and the encode
would fail due to unexpected stream addition.
|
| | |
| |
| |
| |
| |
| | |
Python 2 may not be present in the CI images in the future,
but waf’s shebang line still uses its executable name.
Explicitly call the right major version of the interpreter.
|
| | |
| |
| |
| |
| |
| |
| | |
By overriding it with 1.0 (aka SDR). This prevents blowing up on
mistagged clips.
Fixes #6111
|
| | |
| |
| |
| |
| |
| | |
Upstream has this now. Didn't really make any different for me (except
making the polar compute shader 2%-3% faster), but maybe it does for
somebody else.
|
| | |
| |
| |
| | |
also remove the now unused non-sensical af_fmt_seconds_to_bytes.
|
| | |
| |
| |
| |
| |
| | |
This reverts commit af6126adbe61fb2b6cc780025246d33df93072e6. Apple's
OpenAL support is ridiculously out of date, revert back to just using
OpenAL Soft on macOS (fixes #4645).
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When using multiple compute shaders as part of the same pass, there can
be a conflict in the block sizes. In the problematic case, the HDR
detection shader can collide with the polar sampling shader. In this
case, the solution is clear - the passes that can handle any size should
"give in" and not overwrite the block sizes.
Fixes #6083.
|
| | |
| |
| |
| | |
This fixes A-V drift on seeking
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
Suggested in IRC by sfan5.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Apparently some Android builds/forks require this for Bluetooth
audio to work as they unexpectedly accept fast flag for it.
Shouldn't cause any side-effect (e.g. buffer requirement increased
when on wired audio). It's a hardcoded default in the upstream
AAudio implementation anyway.
Ref.:
https://android.googlesource.com/platform/frameworks/av/+/android-8.0.0_r1/media/libaaudio/src/legacy/AudioStreamTrack.cpp#109
https://android.googlesource.com/platform/frameworks/wilhelm/+/android-8.0.0_r1/src/android/AudioPlayer_to_android.cpp#1680
https://android.googlesource.com/platform/frameworks/av/+/android-8.0.0_r1/media/libaudioclient/AudioTrack.cpp#488
|
| | | |
|
| | |
| |
| |
| | |
Signed-off-by: Aman Gupta <aman@tmm1.net>
|
| | |
| |
| |
| |
| |
| |
| | |
With this option, the script will check that the expected waf version is
present, but will simply fail if it's not, rather than trying to
download it. This allows a package build script to avoid compile-time
network access but still ensure it's using the right waf version.
|
| | |
| |
| |
| |
| | |
Replace dot syntax with accessor syntax so that clang no longer errors
out due to not finding the property servicesMenu on NSApp.
|
| | |
| |
| |
| |
| |
| | |
the colorspace of the layer is only available on 10.11 and upwards.
Fixes #6041
|
| | |
| |
| |
| |
| |
| |
| |
| | |
instead of force unwrapping and chaining the optional vars in our
containsMouseLocation function, safely unwrap and guard the resulting
var.
Fixes #6062
|
| | |
| |
| |
| |
| | |
so that af_fmt_to_planar (and hence af_fmt_from_planar) can just
return the input when it is not an interleaved (planar) format.
|
| | |
| |
| | |
duration is parsed as an integer, and the default value is used if ```-1``` is passed. Passing ```-``` as described here causes a parameter value error.
|
| | |
| |
| |
| |
| | |
An exclamation mark disables the filter by default instead of
enabling it.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
ao->device_buffer will only affect the enqueue size if the latter
is not specified. In other word, its intended purpose will solely
be setting/guarding the soft buffer size.
This guarantees that the soft buffer size will be consistent no
matter a specific enqueue size is set or not. (In the past it
would drop to the default of the generic audio-buffer option.)
opensles-frames-per-buffer has been renamed to opensles-frames-per
-enqueue, as it was never purposed to set the soft buffer size. It
will only make sure the size is never smaller than itself, just as
before.
opensles-buffer-size-in-ms is introduced to allow easy tuning of
the relative (i.e. in time) soft buffer size (and enqueue size,
unless the aforementioned option is set). As "device buffer" never
really made sense in this AO, this option OVERRIDES audio-buffer
whenever its value (including the default) is larger than 0.
Setting opensl-buffer-size-in-ms to 1 allows you to equate the soft
buffer size to the absolute enqueue size set with opensl-frames-per
-enqueue conveniently (unless it is less than 1ms).
When both are set to 0, audio-buffer will be the ultimate fallback.
If audio-buffer is also 0, the AO errors out.
|
| | |
| |
| |
| |
| | |
OpenSLES (and its AudioTrack backend) in Android can take 32-bit
fixed and floating point input since Android L (API 21).
|
| | |
| |
| |
| | |
See af_fmt_to_planar.
|
| | |
| |
| |
| |
| |
| |
| | |
Functions `write` and `smbc_write` are given a diminishing buffer of
incorrect constant size. After partial writes, the code would do another
write of the full original length, failing to subtract the amount
already written.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Thread-unsafe libsmbclient is likely to crash when used simultaneously
across threads. For example, by:
mpv "smb://...mkv" --sub-file "smb://...srt"
Work around this by locking all calls to this library under a single
global mutex. This is a temporary solution. When the libsmbclient bug
[1] is fixed, switch to the code from branch [2] which uses a new api to
create per-thread smb contexts. Fixes [3].
[1] https://bugzilla.samba.org/show_bug.cgi?id=11413
[2] https://github.com/orbisvicis/mpv/tree/smbclient_threaded_api
[3] https://github.com/mpv-player/mpv/issues/5936
|
| | |
| |
| |
| |
| |
| |
| | |
This way the docker container in itself does no networking.
It seems like travis disabled network access from the actual docker
containers.
|
| | |
| |
| |
| |
| | |
This was mistaken in 496b13227b7f4b47a660bbf4e314f9a55b7e8867 and
not noticed in review.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
mpv.com fails to build when cross-compiling with a multilib version
of GCC, because the -m32 flags aren't getting passed to the build
process for osdep/win32-console-wrapper.c or the link phase for
mpv.com itself.
|
| | |
| |
| |
| |
| | |
This way the behavior of default libdir stays consistent before and
after switching to gnu_dirs from waf itself.
|
| | |
| |
| |
| | |
Among other things, fixes compatibility with python 3.7.x.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This started breaking with newer (2.0.x) waf versions, and it was
noticed that a built-in waf module was providing very similar
functionality.
APPNAME definition was required to have `gnu_dirs`' PACKAGE
variable to be defined in order to have f.ex. documentation
installed to the correct directory.
Currently unused options added by `gnu_dirs` were removed to clean
up the output of the help command.
Effective changes to behavior:
- `gnu_dirs` will attempt to figure out if it needs to use lib64
instead of lib within your installation prefix. If you would
like it to not do that, set `--libdir` during configuration.
The way it tries to figure lib/lib64 out is if there's a
`/usr/lib64` and no `/usr/lib32`.
- `--incdir` is now `--includedir` as per standard `gnu_dirs`
behavior.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Before, `do_the_symbol_stuff` would implicitly come before
`handle_add_object`, which adds object files to the linking task.
With newer (2.0.x) versions of waf, the ordering seems to get more
optimized, and thus we have to declare that the function that creates
the linking task should come before the task that adds object files
to the task.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Add another parameter to mpv_opengl_drm_params to hold the FD to the
render node, so that the fd can be passed to hwdec_vaegl.
The render node is opened in context_drm_egl and inferred from the
primary device fd using drmGetRenderDeviceNameFromFd.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The previous code did not save enough information about the old state,
and could end up changing what plane the fbcon:s FB got attached to,
or in worse case causing a blank screen (observed in some multi-screen
setups on Sandy Bridge).
In addition refactor the handling of drmModeModeInfo property blobs to
not leak, as well as enable reuse of already created blobs.
|
| | |
| |
| |
| |
| | |
Fix some memory leaks on error exit in crtc_setup_atomic and
crtc_release_atomic.
|
| | |
| |
| |
| |
| |
| | |
According to earlier discussions, this can improve visual quality.
This only changes the preferred order of the formats, not the
formats themselves.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
this was caused by commit 2e7a4f7. the LAST_LINKFLAGS were not added to
the linking of libmpv and that caused a linking error. manually add the
link flags the same way it's done when linking mpv.
Fixes #5968
|
| | |
| |
| |
| |
| |
| | |
Fixes compilation of the swift components with
`--variant="random_string"`, in which case "." is not the source
directory.
|
| | | |
|
| | |
| |
| |
| | |
Much faster build cycles and more consistent download bandwidth.
|
| | | |
|
| | |
| |
| |
| | |
This way it doesn’t override CC.
|
| | |
| |
| |
| |
| | |
Travis now builds with Clang and containers with git snapshots
of some dependencies.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Temporary solution. For now, this builds using a container image
based on openSUSE Tumbleweed with the current FFmpeg release.
More containers will be added (at least with git snapshots of FFmpeg
and libass), and Travis will eventually be replaced with something
we have more control over.
|
| | |
| |
| |
| | |
`--script-opts=autoload-disabled=yes` now
properly stops the script from running.
|
| | |
| |
| |
| | |
Fixes #5923
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
init is a reserved keyword and Swift 4.2 got a bit stricter about using
it. this could be fixed by adding apostrophes around init but makes the
code uglier. hence i just renamed init to initialized and for
consistency uninit to uninitialized.
Fixes #5899
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
this reverts commit a174566 since the actually reason for failing has
been found. the isysroot flag overwrites the framework and library
search paths. though we only need to overwrite the former and there is
no way to just overwrite that one. we manually add the standard library
search paths to the very end of the linking command, so it won't
interfere with the search paths extracted by waf.
Fixes #5791
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
the pre-allocation was needed because the layer allocated a opengl
context async itself and we couldn't influence that. so we had to start
the core after the context was actually allocated. furthermore a window,
view and layer hierarchy had to be created so the layer would create
a context.
now, instead of relying on the layer to create a context we do this
manually and re-use that context later when the layer wants to create
one async itself.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
The currently-displayed tags make sense for music files, but similar
information for video is more commonly - or at least should be - put
under other tags, while the audio-related tags are often used for
other information on video files (particularly with youtube-dl's
output).
|
| | |
| |
| |
| |
| | |
Those accidentally slipped in with 9975835bdeec3f2b04b136ef40c70b02487bb0e6
due to bad copy & paste.
|
| | |
| |
| |
| |
| | |
Change the log-level of an error message that would sometimes show up
during hwdec probing, and could be misleading.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
When seeking near the end of the file and the next file loads, seeking
continues on the next file at the same position and then immediately
the file after that. This patch stops slider seeking when a new file is
loaded, which is the standard behavior of many other players.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fixes a bug with alsa dmix on Fedora 29. After several minutes,
audio suddenly becomes bad and muted.
Actually, I don't know what causes this. Probably this is a bug in alsa.
In any case, as snd_pcm_status() returns not only 'avail', but also other
fields such as tstamp, htstamp, etc, this could be considered a good
simplification, as only avail is required for this function.
|
| | |
| |
| |
| |
| | |
Previously vo_sdl would unconditonally disable the screensaver,
ignoring the `stop-screensaver` option.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This sacrifices some dynamic range for well-behaved sources, but
prevents catastrophic desaturation on badly mastered / too bright
sources. I think that's the better trade-off. This makes the
desaturation algorithm much "safer" to deploy by default, as well. One
could even argue going up to strength 1.0, which works better for some
sources but worse for others. But I think the current strength is the
best trade-off even after this change.
|
| | |
| |
| |
| |
| | |
I'm also not sure whether this condition doesn't subtly break a lot of
things.
|
| | |
| |
| |
| |
| | |
This code shouldn't even exist in libavformat. If you still need it, you
can enable it via --demuxer-lavf-o.
|
| | |
| |
| |
| | |
Often requested, trivial.
|
| | |
| |
| |
| |
| | |
These were deprecated almost 2 years ago. Now they happen to be in the
way.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
For some reason shadow_offset is a int16_t variable (to save some space
or something), which means the static part of the entire option list
must be below 32KB. This is fine, but still add a check against
overflows. (Currently it's 3.6KB. This does not include dynamic
allocations like strings.)
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
Be a bit more detailed, and discourage disabling it.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The player fully restarts playback when the edition or disk title is
changed. Before this, the player tried to reinitialized playback
partially. For example, it did not print a new "Playing: <file>"
message, and did not send playback end to libmpv users (scripts or
applications).
This playback restart code was a bit messy and could have unforeseen
interactions with various state. There have been bugs before. Since it's
a mostly cosmetic thing for an obscure feature, just change it to a full
restart. This works well, though since it may have consequences for
scripts or client API users, mention it in interface-changes.rst.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This flag is used only by the command parser. Its value overlapped with
some of the existing m_option flags, but only flags that did not matter
for the command parser (i.e. the flag bits used had mostly private uses
in each component). It's still a bit unclean and dangerous to use an
essentially random value, so reuse M_OPT_OPTIONAL_PARAM for it.
Since M_OPT_OPTIONAL_PARAM has a slightly longer name than
MP_CMD_OPT_ARG, I'm going to keep the old name.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When changing video filters during initialization, there was a small
time window where video was initialized, but playback restart was not
complete yet. In this time window, playback_pts is not set. But since
issue_refresh_seek() was using this, it could lead to no refresh being
done _if_ the "video" had only 1 frame (such as cover art).
Fix this by using get_current_time() instead, which is the current time
with corner cases such as ongoing loading or seeks taken into account.
See also the previous commit. Without that, get_current_time() could
return NOPTS during init.
Fixes #5831.
|
| | |
| |
| |
| |
| | |
For example, we call setmode() to switch a FD from text to binary mode
on garbage OSes.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There is some code that checks a FD for whether it is a regular file or
not. If it's not a regular file, it e.g. enables use of poll() to avoid
blocking forever.
But this was done only for FDs that were open()ed by us, not from stdin
special handling or fd://. Consequently, " | mpv -" could block the
player. Fix this by moving the code and running for it on all FDs.
Also, set p->regular_file even on mingw.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When the current packet queue was completely empty, and EOF was reached,
the queue->is_eof flag was not correctly set to true. Change this by
reading ds->eof to check whether the stream is considered EOF. We also
need to make sure update_seek_ranges() is called in this case, so change
the code to simply call it when queue->is_eof changes.
Also, read_packet() needs to call adjust_seek_range_on_packet() if
ds->eof changes. In that case, the decoder also needs to be notified
about EOF. So both of these should be called when ds->eof changes to
true. (Other code outside of this function deals with the case when
ds->eof is changed to false.)
In addition, this code was kind of shoddy about calling wakeup_ds()
correctly. It looks like there was an inverted condition, and sent a
wakeup to the decoder only when ds->eof was already true, which is
obviously bogus. The final EOF case tried to be somehow clever about
checking in->last_eof for notifying the codec, which is sort of OK, but
seems to be strictly worse than just checking whether ds->eof changed.
Fix these things.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
The only effective difference is that the former explicitly checks
whether the JSON value type is string, and errors out if not. The rest
is exactly the same (mpv_set_property_string is mpv_set_property with
MPV_FORMAT_STRING).
It seems silly to keep this, so just remove it.
|
| | |
| |
| |
| |
| | |
If the container FPS is correct, this can help getting ideal mix factors
for vo_gpu interpolation mode. Otherwise, it doesn't matter.
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
This was accidentally moved together with the cmd stuff.
|
| | |
| |
| |
| | |
ffm (ffserver) was removed from ffmpeg.
|
| | |
| |
| |
| | |
(Why the fuck are there up to 20 mouse buttons?)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The default get_format does exactly do this, so we don't need to
duplicate it.
The only potential problem with this is that the logic doesn't entirely
prevent that the avcodec_default_get_format hw_device_ctx path is
triggered, which would probably work, but has unknown consequences and
interactions. But the way the logic currently works it can't happen,
provided the hwaccel metadata libavcodec provides is correct.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Avoids 100% CPU usage due to terminal code retrying read(). Seems like
this was "forgotten" (or there was somehow the assumption poll() would
not signal POLLIN anymore).
Fixes #5842.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
| |
For some reason, the X default modifier map binds shift+tab to
ISO_Left_Tab instead of the regular Tab. So to get Shift+TAB recognized
by mpv, we also need to accept ISO_Left_Tab.
This patch matches what other programs like e.g. Qt do, which treat Tab
and ISO_Left_Tab as the same thing.
God only knows why the distinction exists, and why X decides to mix up
its bindings like that.
Fixes #5849
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes several issues playing back mpegts with video streams marked
as having "still images". For example, see this video which has
frames only every 6s: https://s3.amazonaws.com/tmm1/music-choice.ts
Changes include:
- start playback right away, without waiting for first video frame
- do not consider the sparse video stream in demuxer underrun detection
- do not require multiple video frames for the VO
- use audio as the master stream for demuxer metadata events
- use audio stream for playback time
Signed-off-by: Aman Gupta <aman@tmm1.net>
|
| |
|
|
| |
Signed-off-by: Aman Gupta <aman@tmm1.net>
|
| |
|
|
| |
Needed for the new xdg-wm tiling enums.
|
| |
|
|
|
| |
We already did require it, in order to call set_buffer_scale. This
just makes it error out more gracefully.
|
| |
|
|
| |
Window size should not change if the window has been maximized or tiled.
|
| |
|
|
|
|
|
|
|
|
| |
With the advent of actual HDR devices, my real measured ICC profile has
an "infinite" contrast, since the display is completely off on pure
black inputs. 100k:1 might not be enough, so let's just bump it up to
1m:1 to be safe.
Also, improve the logging in the case that the detected contrast is too
high by default.
|
| | |
|
| |
|
|
|
| |
The old copy is broken with waf-1.9.8, update to the latest commit
(waf-project/waf@5e4b86b81df3b9819738d757eb8d2c8646ef0ede) instead.
|
| | |
|
| |
|
|
|
|
|
| |
This logic has been changed throughout the years, notably in 38ac5d5 and
3bdbf6. Update the documentation to reflect the current state.
Closes #5834.
|
| | |
|
| |
|
|
|
|
| |
This was there originally to detect too-old versions of ffmpeg. We now
only support >= 4.0, so it's not relevant. We just need the dependencies
to be present.
|
| |
|
|
|
|
|
|
|
| |
First fix a memory leak when skipping cursor planes by inverting the
check and putting everything, but the free, in the body.
Then fix a missed drmModeFreePlane by simply copying the fields of the
drmModePlane we are interested in and freeing the drmModePlane struct
early.
|
| |
|
|
|
|
|
| |
Fixes `--ytdl-format="dash-fastly_skyfire-video-363357330+dash-fastly_skyfire_sep-audio-363357330" https://vimeo.com/108650530`
This happened because the video track also had audio available and after
adding it expecting an audio-only track, there were no more tracks with video.
|
| | |
|
| |
|
|
|
|
| |
Could make it behave differently (and leak memory) in certain cases.
Basically, m_option_parse() randomly returns 0 or 1, but most time 1,
with the difference due to legacy reasons that don't matter anymore.
|
| |
|
|
|
|
|
| |
The "if (prop.name)" check is redundant, because an assert above it
implies that it never can be NULL.
Deduplicate some code for initializing the "prop" variable.
|
| | |
|
| |
|
|
|
|
| |
Now both command "descriptions" and runtime command instances are in
cmd.h, which makes sense to me. input.h is now for the actual input
context.
|
| |
|
|
|
|
| |
It doesn't really make sense to keep a separate cmd_list.c file, which
does _not_ contain a command list, but only a few minor helper
functions.
|
| |
|
|
|
| |
Done separately from the cmd.h rename to avoid issues with git being bad
at tracking mixed content and filename changes.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This gets rid of run_command() and its big switch statement, which was
an idiotically big function of almost 1000 lines.
The switch is replaced with a callback per command, and each command is
now implemented in its own function. Command IDs are not needed anymore,
so the mp_command_type enum disappears.
There should be no functional changes, but since this refactors 64
commands, regressions are possible.
The handler() parameter is void*, because in theory the input code is
supposed to be independent of the player core code. For example, you
should be able to reuse the command parser code for some other part of
mpv. In practice, the variable containing command list is defined in the
player core anyway, so you could say this doesn't work. But I'm still
trying to hold onto this idea, so I went with void*.
|
| |
|
|
|
|
|
|
|
|
| |
The plan is to remove the command ID enum. This will happen by replacing
the big switch statement in command.c with dispatching to per-command
callbacks. As preparation, remove uses of the command IDs outside of the
actual dispatching mechanism.
Also remove some instances of checking cmd->def for NULL. We now require
this always to be set.
|
| |
|
|
|
|
|
|
| |
These are old MPlayer commands that were redundant since 2007 or so. In
2013, mpv explicitly deprecated them (actually removed them, but left
this wrapper, which translated them to modern commands). The list was
not extended since 2013, and mpv always warned on the terminal when a
legacy command was used. So it's time to remove it.
|
| |
|
|
| |
Preparation for more changes.
|
| | |
|
| |
|
|
| |
Makes it easier to not break the build by confusing the ifdeffery.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Until recently, ao_lavc and vo_lavc started encoding whenever the core
happened to send them data. Since audio and video are not initialized at
the same time, and the muxer was not necessarily opened when the first
encoder started to produce data, the resulting packets were put into a
queue. As soon as the muxer was opened, the queue was flushed.
Change this to make the core wait with sending data until all encoders
are initialized. This has the advantage that we don't need to queue up
the packets.
|
| |
|
|
|
|
|
|
|
|
|
| |
The user won't want to have those in the video (I think). The core can
sporadically issue redraws, which is what you want for actual playback,
but not in encode mode. vo_lavc can explicitly detect those and skip
them. It only requires switching to a more advanced internal VO API.
The comments in vo.h are because vo_lavc draws to one of the images in
order to render OSD. This is OK, but might come as a surprise to whoever
calls draw_frame, so document it. (Current callers are OK with it.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The video timing code could just decide that EOF was reached before it
was displayed. This is not really a problem for normal playback (if you
use something like --keep-open it'd show the last frame anyway,
otherwise it'd at best flash it on screen before destroying the window).
But in encode mode, it really matters, and makes the difference between
having one frame more or less in the output file.
Fix this by waiting for the VO before starting the real EOF.
vo_is_ready_for_frame() is normally used to determine when the VO frame
queue has enough space to send a new frame. Since the VO frame queue is
currently at most 1 frame, it being signaled means the remaining frame
was consumed and thus sent to the VO driver. If it returns false, it
will wake up the playloop as soon as the state changes.
I also considered using vo_still_displaying(), but it's not reliable,
because it checks the realtime of the frame end display time.
|
| |
|
|
|
| |
This effectively makes --ocopyts the default. The --ocopyts option
itself is also removed, because it's redundant.
|
| |
|
|
|
|
|
|
|
|
| |
While I'm not sure whether it really works, at least it writes the pass1
log correctly now.
How 2-pass stat output is supposed to interact with the new decode API
is rather fishy. ffmpeg.c does the same, and before this change, the
log was not written on EOF (when at least libvpx actually outputs its
stats).
|
| |
|
|
|
|
| |
With the internal change from stringlist to keyvaluelist, these
sub-options stop working. I don't really care enough to bring them
back. (Order doesn't matter, -del always seemed annoying.)
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Inspired by kmscube, first try to pick the Encoder and CRTC already
associated with the selected Connector, if any. Otherwise try to find
the first matching encoder & CRTC like before.
The previous behavior had problems when using atomic
modesetting (crtc_setup_atomic) when we picked an Encoder & CRTC that
was currently being used by the fbcon together with another Encoder.
drmModeSetCrtc was able to "steal" the CRTC in this case, but using
atomic modesetting we do not seem to get this behavior automatically.
This should also improve behavior somewhat when run on a multi screen
setup with regards to deinit and VT switching (still sometimes you end
up with a blank screen where you previously had a cloned display of
your fbcon)
|
| |
|
|
| |
updated since the plane rename commit
|
| |
|
|
|
|
|
|
|
|
|
| |
Add some properties which where forgotten in crtc_setup_atomic.
In both change to not use DRM_MODE_PAGE_FLIP_EVENT | DRM_MODE_ATOMIC_NONBLOCK
flags. This should make it more similar to the drmSetCrtc which it aims to
replace (take effect directly, and blocking call). This also saves us the
trouble of having to set up a poll to wait for pageflip, which would've been
neccesary with DRM_MODE_PAGE_FLIP_EVENT, in both crtc_setup_atomic and
crtc_release_atomic.
|
| |
|
|
|
|
|
|
|
|
| |
This patch will make sure that the video plane is hidden when unused.
When using high resolution modes, typically UHD, and embedding mpv,
having the video plane sitting in the back when you don't play any video
is eating a lot of memory bandwidth for compositing.
That patch makes sure that the video layer is just disabled before and
after playback.
|
| |
|
|
|
|
|
| |
This commit allows to add atomic modesetting when using the atomic renderer.
This is actually needed when using and osd with a smaller size than screen resolution.
It will also make the drm atomic path more consistent
|
| |
|
|
|
|
|
|
| |
We are currently using primary / overlay planes drm objects, assuming that primary plane is osd and overlay plane is video.
This commit is doing two things :
- replace the primary / overlay planes members with osd and video planes member without the assumption
- Add two more options to determine which one of the primary / overlay is associated to osd / video.
- It will default osd to overlay and video to primary if unspecified
|
| |
|
|
|
|
|
|
|
|
| |
This patch adds
- DRM connector object to atomic context.
- fd property to the drm atomic object as well as a method to read blob type properties.
This allows to ensure that the proper connector is picked up, especially when specifying it
from the commandline, and also allows to make sure we're using the right one when embedding
with interop into an application.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
That new API was introduced and allows to have several native resources.
Thisuses that mechanisma for drm resources rather than the deprecated
opengl-cb structs.
This patch therefore add two structs that can be used with the drm atomic interop.
- mpv_opengl_drm_params : which will hold all the drm handles
- mpv_opengl_drm_osd_size : which will hold osd layer size
This commit adds a drm-osd-size=WxH parameter to commandline which
allows to define the OSD plane dimension. OSD can be upscaled to
screen resolution when having OSD at video resolution is too heavy.
This is especially useful for UHD modes on embedded devices where
the GPU cannot handle UHD modes at a decent framerate.
|
| |
|
|
|
| |
This is actually more generic and better than just lazily plastering
peak calculation together with dumb mode.
|
| |
|
|
|
| |
I don't know if we can just return from this function, so for now
just adding this piece of logging.
|
| |
|
|
| |
The manpage parts were forgotten when removing the options.
|
| |
|
|
|
| |
This seems to work surprisingly well, and it's enabled by default
(unlike the old text claims).
|
| |
|
|
|
|
|
|
| |
It was documented for --screenshot-template, but apparently never
implemented.
This value is not explicitly rounded, other than for printf() %f default
formatting (which rounds to 6 digits).
|
| |
|
|
|
|
|
|
|
| |
This means that a time of 4.5678 is displayed as "00:00:04.568" when the
format string is "%H:%M:%S.%T". Likewise, 59.99999 will be displayed as
"00:01:00.000". Before this change, the sub-ms times were just
truncated.
Requested by TheAMM.
|
| | |
|
| |
|
|
| |
The stable xdg-shell protocol is only available from this version.
|
| |
|
|
|
| |
This removes support for older compositors using the unstable version,
but those will still use Xwayland by default, so not a big loss.
|
| |
|
|
|
|
|
|
|
|
| |
Define a hard-coded value for gl_NumWorkGroups if it is not available.
This adds an additional requirement of needing a shader recompile for
all window size changes.
This was considered a worthwhile compromise as currently f.ex. d3d11
completely lacked any peak computation - this is a major quality of
life upgrade.
|
| |
|
|
|
| |
Now that the feature depends on multiple features, log all of
their states in the message.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of using an internal counter to keep track of the value that was
set last, attempt to find the current value of the property/option in
the value list, and then set the next value in the list.
There are some potential problems. If a property refuses to accept a
specific value, the cycle-values command will fail, and start from the
same position again. It can't know that it's supposed to skip the next
value. The same can happen to properties which behave "strangely", such
as the "aspect" property, which will return the current aspect if you
write "-1" to it. As a consequence, cycle-values can appear to get
"stuck".
I still think the new behavior is what users expect more, and which is
generally more useful. We won't restore the ability to get the old
behavior, unless we decide to revert this commit entirely.
Fixes #5772, and hopefully other complaints.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
If playback has not been initialized yet (decoders not initialized
etc.), or if in idle mode, let the track properties cycle through "no"
and "auto". This should be slightly more helpful than making it simply
exit.
Depending on the stage of loading, more could be done. For example, if
youtube-dl loads additional subtitle files, it can happen that these get
added before the main file, and this could be cycled through to an
extent. This is probably too clever, and also sort of dangerous
(unintended interactions with messy in-loading state), so don't do it.
|
| |
|
|
| |
Add {...}, change if(!a) to if(a) and swap its if/else body.
|
| |
|
|
|
| |
I had this enabled for quite a while and experienced no issues. I'm not
aware of other issues either.
|
| |
|
|
| |
Otherwise it will do nothing, waiting on nothing forever.
|
| |
|
|
|
|
|
|
|
| |
AVFilterContext instances support some additional AVOptions over the
actual filter. This includes useful options like "threads". We didn't
support setting those for the "direct" wrapper (--vf=yadif:threads=1
failed). Change this. It requires setting options on the AVFilterContext
directly, except the code for positional parameters still needs to
access the actual filter's AVOptions.
|
| |
|
|
|
|
|
| |
Strictly speaking redundant, but probably helpful.
In particular I want to push MPV_RENDER_PARAM_ADVANCED_CONTROL. Not
enabling this parameter is actually not very sane.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is for working around bugs in certain Android devices. At least one
device fails to sort EGLConfigs by size, so eglChooseConfig() ends up
choosing a config with 5/6/5 bits per r/g/b component. The other
attributes in the affected EGLConfigs did not look like they should
affect the sorting process as specified by the EGL 1.4 standard.
The device was reported as:
Sony Xperia Z3 Tablet Compact
Firmware 6.0.1 build number 23.5.A.1.291
GL_VERSION='OpenGL ES 3.0 V@140.0 AU@ (GIT@I741a3d36ca)'
GL_VENDOR='Qualcomm'
GL_RENDERER='Adreno (TM) 330'
Other Qualcom/Adreno devices have been reported as unaffected by this
(including some with same GL_RENDERER string).
"Fix" this by always requiring at least 8 bit. This means it would fail
on devices which cannot provide this. We're fine with this.
mpv-android/mpv-android#112
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was supposed to be a replacement for encode_lavc_discontinuity()
(so we don't need to store last_video_in_pts in a way which requires
synchronization). Unfortunately, VOCTRL_RESET is also called before
termination, and even though it shouldn't matter as far as the VO API is
concerned, it does. It's because vo_lavc.c buffers a frame to compute
the frame duration.
Drop this code. The consequence is that it appears to encode 2 frames
with the same PTS if multiple files are encoded into one. Before this,
it merely dropped a frame (maybe the first of every subsequent file, not
sure).
|
| |
|
|
| |
Might be helpful with broken EGL implementations.
|
| |
|
|
|
| |
This code makes the player wait using real time, which makes sense for
normal playback, but not encode mode.
|
| |
|
|
| |
So that demux_mkv doesn't log them as unknown.
|
