| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
| |
Is anyone still monitoring this in any way? I think not.
|
| | |
|
| |
|
|
|
| |
These are a common source of bug reports, due to misconceptions that
they are required to make use of hardware decoding.
|
| |
|
|
| |
'ctx->ra' is null pointer when d3d11 init failed before call 'ra_d3d11_create' in 'd3d11_init'.
|
| |
|
|
| |
'ctx11' be not release when d3d11 hwdec be uninit with 'mapper_uninit' method.
|
| |
|
|
| |
See previous commit. It compiles, but 100% untested.
|
| |
|
|
| |
See previous commit.
|
| |
|
|
|
|
|
|
| |
The write functionality is almost unused (only encoding 2-pass mode uses
it to write the log file). Moreover, it almost makes no sense to use
this in a not local scenario. This change is just to prevent people from
duplicating the short write logic across all streams that happen to
support writing. Mostly untested; local log file writing still works.
|
| | |
|
| |
|
|
|
|
| |
The old rar code could do uncompressed rar, libarchive supports at least
some rar compression algorithms. There is no need to keep the old rar
code.
|
| |
|
|
|
|
|
|
|
| |
The "program" property could switch between TS programs. It was rather
complex and rather obscure (even if you deal with TS captures, you
usually don't need it). If anyone actually needs it (did anyone ever
attempt to even use it?), it should be rewritten. The demuxer should
export a program list, and the frontend should handle the "cycling"
logic.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Linux analog TV support (via tv://) was excessively complex, and
whenever I attempted to use it (cameras or loopback devices), it didn't
work well, or would have required some major work to update it. It's
very much stuck in the analog past (my favorite are the frequency tables
in frequencies.c for analog TV channels which don't exist anymore).
Especially cameras and such work fine with libavdevice and better than
tv://, for example:
mpv av://v4l2:/dev/video0
(adding --profile=low-latency --untimed even makes it mostly realtime)
Adding a new input layer that targets such "modern" uses would be
acceptable, if anyone is interested in it. The old TV code is just too
focused on actual analog TV.
DVB is rather obscure, but has an active maintainer, so don't remove it.
However, the demux/stream ctrl layer must go, so remove controls for
channel switching. Most of these could be reimplemented by using the
normal method for option runtime changes.
|
| |
|
|
|
|
| |
This was possibly needed by libdvdread, and/or old CD drivers on some
system. It still works with on-filesystem DVD and BD test images, so
this can go.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This removes anything related to DVD/BD/CD that negatively affected the
core code. It includes trying to rewrite timestamps (since DVDs and
Blurays do not set packet stream timestamps to playback time, and can
even have resets mid-stream), export of chapters, stream languages,
export of title/track lists, and all that.
Only basic seeking is supported. It is very much possible that seeking
completely fails on some discs (on some parts of the timeline), because
timestamp rewriting was removed.
Note that I don't give a shit about optical media. If you want to watch
them, rip them. Keeping some bare support for DVD/BD is the most I'm
going to do to appease the type of lazy, obnoxious users who will care.
There are other players which are better at optical discs.
|
| |
|
|
| |
Isolate icky DVD garbage into a single file.
|
| |
|
|
|
|
|
|
|
|
|
| |
stream_dvd.c contained large amounts of ancient, unmaintained code,
which has been historically moved to libdvdnav. Basically, it's full of
low level parsing of DVD on-disc structures.
Kill it for good. Users can use the remaining dvdnav support (which
basically operates in non-menu mode). Users have reported that
libdvdread sometimes works better, but this is just libdvdnav's problem
and not ours.
|
| |
|
|
|
|
|
| |
s->priv->cancel will be freed when s is freed, so
freeing it explicitly is not required.
Signed-off-by: Aman Gupta <aman@tmm1.net>
|
| |
|
|
| |
With minor difference from lua, as documented.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Semantics changes are the same as at 548ef078 .
Also, the previous C implementation returnd a string for the `stdout`
value, but stdout of the subprocess command is MPV_FORMAT_BYTE_ARRAY
which js previously didn't support, so support it too (at pushnode)
by returning it as a string - the same as the lua code does.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
There were some cases where a js number (double) was blindly casted to
int or uint64, but that can be undefined behavior (out of range to int)
or wrong (negative to uint).
Now the code throws a js error if the value is out of range.
Additionally, commit ec625266 added these checks for the new hooks API,
but incorrectly tested int64 range rather than uint64. Fix this too.
|
| |
|
|
|
|
| |
This prevents the pause state from triggering before the audio output is
finished playing back audio. This is particularly helpful for gapless
audio.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Mesa supports the EGL_CHROMIUM_sync_control extension, and it's
available out of the box with AMD drivers. In practice, this is exactly
the same as GLX_OML_sync_control, but for EGL. The extension
specification is separate from the GLX one though, and buried somewhere
in the Chromium code.
This appears to work, although I don't know if it really works.
In theory, this could be useful for other EGL targets. Support code for
it could have been added to egl_helpers.c to avoid some minor duplicated
glue code if another EGL target were to provide this extension. I didn't
bother with that. ANGLE on Windows can't support it, because the
extension spec. explicitly requires POSIX timers. ANGLE on Linux/OSX is
actively harmful for mpv and hopefully won't ever use it. Wayland uses
EGL, but has its own fancy presentation feedback stuff (and besides, I
don't think basic video player functionality works on Wayland at all).
context_drm_egl maybe? But I think DRM has its own stuff.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So the next commit can make EGL use it. EGL has a quite similar
function, that practically works the same. Although it's relatively
trivial, it's still tricky, and probably shouldn't end up as duplicated
code.
There are no functional changes, except initialization, and how failure
of the glXGetSyncValues call is handled. Also, some comments mention the
EGL extension.
Note that there's no intention for this code to handle anything else
than the very specific OML sync extension (and its EGL equivalent). This
is just too weirdly specific to the weird idiosyncrasies of the
extension, and it makes no sense to extend it to handle anything else.
(Such as Wayland or DXGI presentation feedback.)
|
| |
|
|
|
|
|
|
|
|
| |
In the past, src peak was always equal to or higher than dst peak. But
since `--target-peak` got introduced, this could no longer be the case.
This leads to an incorrect result (scaling for peak mismatch in gamma
light) unless some other option (CMS, --linear-scaling, etc.) forces the
linearization.
Fixes #6533
|
| | |
|
| |
|
|
| |
this for example allows --demuxer=rawaudio to work on directories
|
| |
|
|
| |
It seems some DVB-T2 cards take longer to push out data.
|
| |
|
|
|
|
|
| |
While they accept the frequency field with MHz for DVB-S,
for DVB-C and DVB-T, it may be in Hz, kHz or MHz.
The official rule is to multiply whatever is in the channels.conf
by 1000 until a value > 1000000 is reached to get correct units for tuning.
|
| | |
|
| | |
|
| |
|
|
|
| |
This was forgotten in commit 5a8c48fde2a26fe00c3552e3ccf83a965b6d3576
when the number of buffers was reduced to 1.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
* Adds a script to clone and build FFmpeg as well as
to configure and build mpv itself. Currently only used
for macOS and contain hard-coded macOS specific options.
* Still works with the Linux containers.
* Moves our language back to "c" from "generic"
* Defines our Linux distribution as "bionic" to get the latest
Ubuntu base distribution to be the runner for our containers.
* Adds the homebrew add-on for macOS package installation for
dependencies. Installs everything required but FFmpeg, as we want
to have our own FFmpeg snapshots.
|
| |
|
|
|
|
|
|
|
| |
We collect a 'vulkan-device' option today but then don't actually
pass it on, so it's useless. Once that's fixed, it can be used
to select a specific vulkan device by name.
Tested with the new nvidia offload feature to select between the
nvidia and intel GPUs.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Somehow I got the idea that compound literals had function-scoped
lifetime. Instead, like all other objects with automatic storage
duration, compound literals are block-scoped, so they become invalid
after exiting the block they were declared in. It seems like a recent
change to GCC actually reuses the memory that the compound literals
used to occupy, which was causing a few bugs.
The pattern of conditionally assigning a pointer to a compound literal
was used in a few places in ra_d3d11 where the Direct3D API expects
either a pointer to an initialised struct or NULL. Change these to
ensure the lifetime of the struct includes the API call.
Should fix #6775.
|
| |
|
|
|
| |
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 t |
