| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
They didn't exist yet when this code was added.
Completely untested.
|
|
|
|
| |
See #5670.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Hardware decoding things often need access to additional handles from
the windowing system, such as the X11 or Wayland display when using
vaapi. The opengl-cb had nothing dedicated for this, and used the weird
GL_MP_MPGetNativeDisplay GL extension (which was mpv specific and not
officially registered with OpenGL).
This was awkward, and a pain due to having to emulate GL context
behavior (like needing a TLS variable to store context for the pseudo GL
extension function). In addition (and not inherently due to this), we
could pass only one resource from mpv builtin context backends to
hwdecs. It was also all GL specific.
Replace this with a newer mechanism. It works for all RA backends, not
just GL. the API user can explicitly pass the objects at init time via
mpv_render_context_create(). Multiple resources are naturally possible.
The API uses MPV_RENDER_PARAM_* defines, but internally we use strings.
This is done for 2 reasons: 1. trying to leave libmpv and internal
mechanisms decoupled, 2. not having to add public API for some of the
internal resource types (especially D3D/GL interop stuff).
To remain sane, drop support for obscure half-working opengl-cb things,
like the DRM interop (was missing necessary things), the RPI window
thing (nobody used it), and obscure D3D interop things (not needed with
ANGLE, others were undocumented). In order not to break ABI and the C
API, we don't remove the associated structs from opengl_cb.h.
The parts which are still needed (in particular DRM interop) needs to be
ported to the render API.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
At least the libavcodec MediaCodec wrapper sometimes seems to break the
libavcodec API, and does the following sequence:
send_packet() -> EAGAIN
receive_frame() -> EAGAIN
send_packet() -> OK
The libavcodec API never allows returning EAGAIN from both functions, so
we discarded packets in this case. Change it to retrying decoding, for
the sake of MediaCodec. Note that it could also happen due to internal
bugs in the vd_lavc.c hw fallback code, but if there are any remaining,
they should be fixed properly instead.
Requested.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When this happens, network calls are forcibly aborted (more or less),
but demuxers might keep going, as most of them do not check for forced
exits properly. This can possibly lead to broken packets being added.
Also do not attempt to read more packets in this situation.
Also do not print a stream open failed message if opening was aborted
anyway.
|
|
|
|
|
|
|
|
|
|
|
| |
we rendered on the displaylink thread which wasn't the best idea. if
rendering took too long or was blocking it also blocked the displaylink
callback. when that happened new vsyncs were reported delayed or not at
all. consequently the mpv_render_context_report_swap function wasn't
called consistently and that could cause bad video playback. so the
rendering is moved to a dedicated dispatch queue. furthermore the update
callback starts a layer update directly instead of the displaylink
callback, making the rendering a bit more consistent.
|
|
|
|
|
|
|
| |
Previously, section titles (File/Video/Audio) were printed as suffix of
a property that was assumed to always exist. However, with e.g.
lavi-complex this is not the case, therfore, print them without being
dependent on a property.
|
|
|
|
|
|
|
|
|
| |
Switch from audio|video to audio|video-out-params properties as per
recommendation in #5670. These properties are tables and include
information explicitly queried later, so switch to using these tables
and reduce the amount of queried properties.
Fixes #5670
|
|
|
|
|
| |
This manages to make the code more readable. Thanks to
MakeGho@IRCnet for the snippet on which this was based.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Right now the atomic request is alive during the renderloop.
We want it to be alive until the drm egl context is destroyed because some properties
might still be set upon interop close
This patch make the request to be kept created even outside the renderloop.
The context uninit will commit the last request.
|
|
|
|
| |
This makes the French version consistent with the English one.
|
|
|
|
|
|
|
|
| |
commit 2edf00f changed the MPV_EVENT_SHUTDOWN behaviour slightly, such
that it will only be sent once. cocoa-cb relied on it being sent
continuously till all mpv_handles are destroyed. now it manually shuts
down and destroys the mpv_handle after the animation instead of relying
on this removed behaviour.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This passed the display size as source size to the renderer, which is of
course nonsense. I don't know what I was doing in 569383bc54.
Yet another fix for those damn anamorphic videos.
As a somewhat redundant/cosmetic change, use image_params instead of
real_image_params in the code above. They should have the same, dimensions
(but possibly different formats when doing hw decdoing), and mixing them
is confusing. p->image_params wins because it's shorter.
Actually fixes #5619.
|
| |
|
|
|
|
| |
Fixes #5640.
|
|
|
|
| |
This also switches the order, because that makes more sense.
|
|
|
|
|
| |
Jesus Christ, how did I get this wrong, or never verified proper
function. This fixes --vf=vdpaupp not working with yuv420p input.
|
|
|
|
|
|
|
|
| |
There is some sort-of awkwardness here, because option access needs to
happen in a synchronized manner, and the framedrop flag is not in the VO
option struct. Remove the mp_read_option_raw() call and the awkward
change notification via VO_EVENT_WIN_STATE from command.c, and pass it
through as new vo_frame flag.
|
|
|
|
|
|
| |
Removes the awkward notification through VO_EVENT_WIN_STATE.
Unfortunately, some awkwardness remains in mp_property_display_fps(),
because the property has conflicting semantics with the option.
|
|
|
|
| |
Probably mostly useful for the libmpv render API.
|
| |
|
|
|
|
|
|
|
| |
It's a WTF that we have something as specific in the API. It could be
argued that we should provide helpers for other language and GUI toolkit
combinations. Obviously that's not going to scale, and it's somewhat
likely that it will bitrot. The rest is said in the API changelog.
|
|
|
|
|
|
|
|
|
|
|
| |
We took the storage size instead of the display size for "unscaled"
screenshots. Even if it's called "unscaled", it's still supposed to
scale to compensate for aspect ratio.
(How many commits fixing anamorphic screenshots in various situations
are there?)
Fixes #5619.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
vf_vdpaupp crashed on certain files (with --hwdec=vdpau --deinterlace).
This happened for example with mpeg2 files, which for some reason
typically contain some AVFrame side data. It turns out the last change
in 55c88fdb8f1a9269 was not quite clean, and forgot the special cases in
mp_image_new_dummy_ref(). This function is supposed to copy all metadata
from the argument passed, except buffer refs. But there were new buffer
refs, that were not cleared properly. Also, the ff_side_data pointer
must be cleared, or the new mp_image would try to free it on
destruction.
The bottom line is that mp_image_new_dummy_ref() is a pretty bad idea,
and I suppose all callers with non-NULL arguments should be changed to
create a blank mp_image, and copy frame properties as needed (this
includes callers of mp_image_new_custom_ref()).
Fixes #5630.
|
| |
|
|
|
|
| |
Requested in #634. Better late than never?
|
|
|
|
| |
Fixes #5643.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this change, mpv_wait_event() could inconsistently return
multiple MPV_EVENT_SHUTDOWN events to a single mpv_handle, up to the
point of spamming the event queue under certain circumstances. Change
this and just send it exactly once to each mpv_handle.
Some client API users might have weird requirements about destroying
their state asynchronously (and not reacting immediately to the SHUTDOWN
event). This change will help a bit to make this less weird and
surprising.
|
| |
|
|
|
|
|
| |
Since this has clearer semantics now, the old name is just clunky and
confusing.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changes how mpv_terminate_destroy() and mpv_detach_destroy()
behave. The doxygen in client.h tries to point out the differences. The
goal is to make this more useful to the API user (making it behave like
refcounting).
This will be refined in follow up commits.
Initialization is unfortunately closely tied to termination, so that
changes as well. This also removes earlier hacks that make sure that
some parts of FFmpeg initialization are run in the playback thread
(instead of the user's thread). This does not matter with standard
FFmpeg, and I have no reason to care about this anymore.
|
|
|
|
|
|
| |
The intention is to reduce annoying differences between mpv CLI and
libmpv, and there's no reason to have the locale check only in libmpv
(although it doesn't help with any real issues either).
|
|
|
|
|
| |
Remove the weird prepare_exit_cplayer() function, and fold the contents
into mpv_main() and mp_initialize().
|
|
|
|
|
|
|
| |
the first mouse events, that try to hide the title bar, could happen
before the title bar was actually initialised. that caused our hiding
code to access a nil value. check for an available title bar before
trying to hide it.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
there were actually a few small problems. the fatalError() function
wasn't supposed to be called there and caused an "Illegal instruction".
this was replaced by a print and exit() call. the second problem was
that cocoa returns a kCGLBadPixelFormat instead of a kCGLBadAttribute
error, which broke our check, immediately exited our loop and no working
pixel format was ever created. the third problem was that macOS 10.12
didn't return any errors but also didn't return a pixel format, that
also broke our check. now the code checks for both cases.
Fixes #5631
|
|
|
|
|
|
|
| |
with older waf versions a node doesn't return an absolute path but just
a relative one. fix this by explicitly requesting an absolute one.
Fixes #5604
|
|
|
|
|
|
| |
with the new libmpv API it's not necessary to check for this property
anymore since libmpv will only use the provided profile when it is
needed.
|
|
|
|
|
|
|
|
| |
when we transitioned to the new libmpv API with commit ae29725 i
reintroduced an old bug that was fixed with 7f714c6 because of a dumb
rebasing error on my part. the branch i based the libmpv changed on was
originally without the fbo fix and on rebasing i forgot to change the
variable to the proper one, basically deactivating the fix.
|
|
|
|
|
|
|
|
|
|
| |
mouse events and the tracking area are needed for (un)hiding the new
title bar, which was broken when input-cursor=no was set. no tracking
area was ever created and set which completely deactivated any mouse
events. the specific mouse event functions were already deactivated
proactively and have the needed check. no events are being propagated to
the mpv core when input-cursor=no is set, even with an active tracking
area.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Overall, just shuffled code around and added a few debugging messages
for future issues.
The issue could be reproduced easily by quickly navigating through the
playlist inside a network mount.
Closes #5618
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The s_size() function, whatever it was supposed to do, caused the
surface size to increase indefinitely. Fix by making it always use the
maximum size that was last used, which is less optimal (many surface
recreations when making the window slowly larger), but at least it
works.
The rotation code didn't mark the old surface as invalid when it was
freed, so it could destroy random other surfaces (let's call it dangling
ID).
Also, the required rotation surface size depends on the rotation mode,
so recreate the surfaces on rotation as well.
|
|
|
|
|
|
|
|
| |
If you set desired.samples to 0, SDL will return a default buffer size
on obtained.samples. This was broken, because ceil_power_of_two(0)
returns 1. Since 0 is usually not considered a power of two, this is
probably correct, but we still want to set desired.samples to 0 in this
case.
|
|
|
|
|
|
|
|
|
| |
You can use --audio-buffer=0 to minimize the audio buffer size. But if
the AO reports no device buffer size (like e.g. ao_jack does), then the
buffer size is actually 0, and playback can never work properly.
Make it fallback to a size of 1, which is unlikely to work properly, but
you get what you asked for, instead of a freeze.
|
|
|
|
|
|
|
|
|
|
| |
Since the demuxer cache addition, ds->queue->head can actually be set to
non-NULL, but the decoder can still be at EOF (with no packets to come).
This made it report an unknown buffered size, instead of 0. Fix this by
checking the decoder part of the packet queue instead.
Probably doesn't matter much, but fixes an annoying "???" on the CLI
status line in some situations.
|
|
|
|
|
| |
The old message was outdated and also not very precise. Make it all a
bit more elaborate.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
there were several problems that had to be fixed because of differences
between python2 to python3:
- subprocess.check_output returned an unicode instead of a string
- filter() returns an iterator instead of a list
- recursion limit was reached
first two were fixed by explicitly converting to the needed type or
using the proper function invocation. third was fixed by changing the
recursive process_libraries function to an iterative one.
Fixes #5600, #3316
|
|
|
| |
While the soft buffer size is already by default 200ms, it is not enough to guarantee dropout-free playback on Bluetooth audio. Bumping the device buffer size to the same value seems to suffice.
|
|
|
| |
Set play state to playing in init() instead. We no longer touch the play state afterwards.
|
|
|
| |
Avoid resume() from causing SL_RESULT_BUFFER_INSUFFICIENT ("Failed to Enqueue: 7" when seek or resume from pause).
|
|
|
|
|
|
|
|
| |
We use triple buffering for this interop and we were only unreffing the
data structures, which doesn't destroy the drm buffers.
This patch allows to make sure that we release the drm buffers on
playback end.
|
|
|
|
|
|
|
| |
we activated the rendering loop a bit too early and it was possible that
the first draw function was called before it was actually ready. this
was a remnant from the old init routine and should have been changed.
start the queue on reconfigure instead of preinit.
|
|
|
|
|
|
|
| |
on a file change and when the aspect ratio of the window changed, the
first live resize state had a wrong aspect ratio because the new aspect
ratio was only set after the first resize. just set the new content
frame before the resize.
|
|
|
|
|
|
|
|
|
|
|
|
| |
i tried being smart and handle aspect ratio differences manually via
atomic drawing and resizing to aspect fitted frames. there were a few
issues with that. like unexpected visibility of certain System GUI
elements on entering fullscreen or visually dropped frames due to the
atomic drawing. now we rely on system mechanics to keep the proper
aspect ratio of our layer, the recommended way. as a side effect it also
fixes a segfault.
Fixes #5581
|
|
|
|
|
|
|
|
|
|
|
|
| |
It turns out that Mali drivers are likely broken, and do not return
GBM_FORMAT_ARGB8888 (they return GBM_FORMAT_XRGB8888) when getting
EGL_NATIVE_VISUAL_ID for any EGLConfig, even though the resulting
EGLConfig appears to be capable of alpha.
It could also be potentially useful to allow an ARGB EGLConfig used
with an XRGB framebuffer on some platforms, so we do that. (cf. weston)
Unrelated indentation fix in gbm_format_to_string.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Naturally, there's more than one fourcc that indicates an mjpeg
stream.
I have a particular ancient webcam here (Logitech QuickCam Messanger)
that only supports the single 'JPEG' format, but there are other
devices out there which support both 'JPEG' and 'MJPG' with no visible
differences, and others where the streams are slightly different.
Regardless of those details, it remains correct to treat 'JPEG'
the same as 'MJPG' from a stream consumption perspective.
|
|
|
|