| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
use the append to playlist functionality if shift is pressed while dropping
|
|
|
|
|
|
|
| |
If the drag and drop action is anything other than
XdndActionCopy, append the dropped files rather than
replacing the existing playlist. With most file managers,
this will mean at least pressing shift while dropping.
|
|
|
|
|
|
| |
This puts in place the machinery to merely append dropped file to the playlist
instead of replacing the existing playlist. In this commit, all front-ends
set this to false preserving the existing behaviour.
|
|
|
|
|
|
| |
This takes care of the corner case where the player is started with a
single playlist entry so that the next/prev arrows are greyed out, but
remain that way even after new elements are added to the playlist.
|
|
|
|
| |
Return MPV_ERROR_LOADING_FAILED instead of MPV_ERROR_NOTHING_TO_PLAY.
|
|
|
|
|
| |
This refers to media played by mpv, and these don't necessarily have to
be files. They can be network resources or entirely abstract URLs too.
|
|
|
|
|
|
|
|
|
|
|
| |
Even after it has been disabled with the `disable-osc` message, the OSC
continues to run the tick function. Completely preventing tick from
being called is impractical since there are several different places
that it's called in the code, so just make it immediately return if the
OSC has been disabled.
This prevents the OSC from continuing the clear the OSD on every tick,
allowing other scripts to disable it so that they may draw to the OSD.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The FFmpeg can officially not distinguish between unknown subtitle
durations, and subtitle durations being 0. (It documents the value 0
meaning unknown duration.)
In practice, at least the LRC demuxer signals unknown subtitle durations
with a negative value.
Assume negative durations mean unknown duration. Show subtitles with
unknown duration forever. Unless there's a subtitle event following it;
then reset the duration so that it ends on the new subtitle event.
Fixes #2244.
|
|
|
|
|
|
|
| |
Some extractors may claim to have extracted subtitles, but then
set the relevant fields to null. Try to catch those cases.
Fixes #2254
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a simplistic heuristic for detecting broken indexes. This includes
indexes with very few elements (apparently libavformat sometimes writes
such indexes, or used to), and indexes with broken timestamps.
The latter was apparently produced by very old HandBrake versions:
| + Muxing application: libmkv 0.6.1.2
| + Writing application: HandBrake 0.9.1
These broken files seem to be common enough that libavformat added a
workaround for them in 2008 (and maybe again in 2015). Apparently all
timestamps are multiplied with the file's tc_scale twice, and FFmpeg
attempts to fix them. We should throw away the whole thing.
|
|
|
|
|
|
| |
Actually, this never happened, because there's logic for ignoring
duplicate header elements (which includes the seek index). This is
mostly for robustness and readability.
|
|
|
|
|
|
|
| |
It just causes annoying artifacts.
Interestingly, this means keeping down the frame stepping key (".") will
play video with interpolation disabled.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This might fix some problems when framestepping with interpolation
enabled. The problem here is that we want to show the non-interpolated
frame while paused. Framestepping is like unpausing the video for a
frame, and then pausing again. This draws an interpolated frame, and
redrawing on pausing is supposed to take care of this.
This possibly didn't always work, because vo->want_redraw is not checked
by the vo_control() code path. So wake up the VO thread (which takes
care of servicing redraw requests, kind of) explicitly.
The correct solution is getting rid of the public-writable want_redraw
field and replacing it with a new vo_request_redraw() function, but this
can come later.
|
|
|
|
|
|
|
| |
So snd_device_name_get_hint() return values do in fact have to be freed.
Also, change listing semantics slightly: if io==NULL, skip the entry,
instead of assuming it's an output device.
|
| |
|
|
|
|
|
|
|
| |
libavcodec does not support HEVC via VAAPI yet, so this won't work.
However, there is ongoing work to add HEVC support to VAAPI, and this
change might help with testing. (Or maybe not - but there is no harm in
this change.)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead, allow reading 2KB only. This seems to be sufficient for
libarchive to recognize zip, 7z, rar, tar. Good enough.
This is implemented by creating an in-memory stream with a copy of
the file header. If libarchive succeeds opening this, the actual
stream is opened.
Allowing unlimited reading could break unseekable streams, such as
playing from http servers with no range request support or pipes.
Also, we try not to read too much data in the first probe pass. Some
slow network streams like shoutcast services could make probing much
slower if we allow it to read too much. In the second probing pass,
actually allow 200KB.
|
|
|
|
|
|
| |
Should not happen, but since we don't control decoder video surface
allocation, anything could happen, and the code should be able to deal
with it. Untested.
|
|
|
|
|
|
|
| |
This should avoid unnecessary sleeping when audio playback start resync
has finished and goes into the normal playback state.
This is tricky; see e.g. commit 402fe381.
|
|
|
|
| |
Fixes #2237.
|
|
|
|
|
|
|
|
|
|
| |
As expected, probing with libarchive is a disaster. Both libavformat and
libarchive are too eager to misdetect file formats just because files
"might" be of a specific type. In this case, it's mp3 vs. tar. To be
fair, neither file format has an actual header. I'm not sure why we'd
need tar support, but since libarchive provides it, and idiots on the
internet apparently pack media files in tar sometimes (really, idiots),
keep it for now, and probe tar last.
|
|
|
|
| |
Oddly often requested.
|
|
|
|
| |
Leftover from 3245bfef.
|
|
|
|
| |
ingore-chmap -> ignore-chmap
|
|
|
|
|
|
|
| |
Provides a simplistic way to seek without having to care about weird
situations like timestamp vs. playback time. This is good, because the
seek command is currently timestamp based, so when using the seek
command the user _does_ have to care.
|
|
|
|
|
|
|
|
| |
Always compute the estimated absolute time of the seek target, and
display this as playback time during seeks.
Improves behavior with e.g. .ts files, for which we try to avoid seeks
by timestamp.
|
| |
|
|
|
|
|
| |
Keep glSwapInterval(0) on to avoid blocking on gl calls, but wait for
frame callbacks so we play nice with compositor.
|
|
|
|
|
|
|
| |
Privdes small api for vo_wayland where one can request frame callback
and then wait for it.
This will make vo_wayland play video smoothly.
|
|
|
|
| |
This makes mesa not wait for frame callback internally.
|
|
|
|
|
|
|
|
|
| |
Fixes regression in dfd8a5f that made autoload not add more files
at the end of the current playlist if playlist was made by the
script.
This still prevents loading the script if more than one (media or
playlist) file was manually added.
|
|
|
|
|
|
| |
Or almost. I don't know or care.
Fixes #2219 (maybe, I don't know or care).
|
|
|
|
|
| |
Too many false positives (it accepts things like unspecific text files),
and also relatively useless.
|
|
|
|
|
|
|
|
|
|
| |
This significantly reduces the amount of noticeable flashing when using
tscale kernels with negative lobes, by cutting them off completely.
I'm not sure if this has any negative effects. It needs a bit of
subjective testing over a period of time, so I just made it an option.
Fixes #2155.
|
|
|
|
| |
And add an option to enable it.
|
|
|
|
|
|
|
|
|
| |
A client API user might count on the fact that audio and video outputs
have already been uninitialized. (They remain uninitialized before
entering idle mode in order to allow smooth transition to the next
playlist entry.) Since event delivery is asynchronous, this has to
happen after actually doing the uninitialization, or the client will
essentially run into a race condition.
|
|
|
|
| |
Most likely doesn't matter much.
|
|
|
|
|
| |
This is a cosmetic change, because the value is exactly the same. (The
old code just duplicates the logic, sort of.)
|
|
|
|
|
|
|
|
|
|
|
| |
libarchive uses a quite confusing ifdeffery mess for some of the types
used in callbacks. Currently, archive_read_set_seek_callback() causes a
warning at least on Windows due to mismatching return type. The header
file uses __LA_INT64_T as return type, so I think the user is intended
to use int64_t.
(The ssize_t return type for the read_cb seems correct, on the other
hand.)
|
|
|
|
|
| |
The OSD overlay wasn't initialized, so it remained solid black until the
first time a subtitle line or an OSD element became visible.
|
| |
|
|
|
|
|
|
|
| |
All hwdec backends now use a single pixel format, and the format is
always checked.
Also, the init_decoder callback is now mandatory.
|
|
|
|
|
| |
This is not needed. It was used only temporarily in a development
branch, and is a leftover from earlier rebasing.
|
|
|
|
|
|
| |
Some particular checks can define the HAVE_ key on their own. To make sure
they work correctly when composed (with compose_checks) we force the HAVE_
key to be undefined if a check fails.
|
|
|
|
| |
This reverts commit 1b7883a3e57a39edfd39732efde5cd02417e3ebd.
|
|
|
|
|
| |
Even though the rpi check fails, it'll define "HAVE_RPI 1" in config.h.
Why? Who knows...
|
|
|
|
|
| |
Most of what is not in this list is extremely obscure, or increases the
file format misdetection rate.
|
|
|
|
| |
Actually, this was unintentionally changed in commit 70e0bc1e.
|
|
|
|
|
|
|
|
|
|
|
| |
Since vo_rpi uses MMAL for video output, which is completely
independent from the GLES overlay, we can just not redraw the
GLES screen if subtitles do not change.
(As a furhter optimization, the dispmanx overlay could be removed
if nothing is visible. But I'm not sure if adding and removing the
overlay frequently is a good idea for performance, so this could
just as well go the other way.)
|
|
|
|
|
|
|
|
| |
Slightly faster than using the dispmanx mess (perhaps to a large amount
due to the rather stupid C-only unoptimized ASS->RGBA blending code).
Do this by reusing vo_opengl's subtitle renderer, and vo_opengl's RPI
backend.
|
|
|
|
| |
To be used by vo_rpi.c. No functional changes.
|
|
|
|
| |
libarchive does strange things with them.
|
|
|
|
|
| |
And use it everywhere, instead of retrieving the size manually. Slight
simplification.
|
|
|
|
|
|
|
|
| |
Things like .gz etc., which have no real file header. A mixed bag,
because it e.g. tends to misdetect mp3 files as compressed files or
something (of course it has no mp3 support - I don't know as what it
detects them). But requested by someone (or maybe not, I'm not sure
how to interpret that).
|
|
|
|
| |
Fix a typo, and also reword another comment.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This affects vo_opengl_cb in particular: it'll most likely auto-load
VDA, and then the VideoToolbox decoder won't work. And everything fails.
This is mainly caused by FFmpeg using separate pixfmts for the _same_
thing (CVPixelBuffers), simply because libavcodec's architecture demands
that hwaccel backends are selected by pixfmts. (Which makes no sense,
but now we have the mess.)
So instead of duplicating FFmpeg's misdesign, just change the format to
our own canonical one on the image output by the decoder. Now the GL
interop code is exactly the same for VDA and VT, and we use the VT name
only.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This works similar to the existing .rar support, but uses libarchive.
libarchive supports a number of formats, including zip and (most of)
rar.
Unfortunately, seeking does not work too well. Most libarchive readers
do not support seeking, so it's emulated by skipping data until the
target position. On backwards seek, the file is reopened. This works
fine on a local machine (and if the file is not too large), but will
perform not so well over network connection.
This is disabled by default for now. One reason is that we try
libarchive on every file we open, before trying libavformat, and I'm not
sure if I trust libarchive that much yet. Another reason is that this
breaks multivolume rar support. While libarchive supports seeking in
rar, and (probably) supports multivolume archive, our support of
libarchive (probably) does not. I don't care about multivolume rar, but
vocal users do.
|
|
|
|
| |
Regression since commit 75b1d504.
|
|
|
|
| |
Can happen in obscure situations and with hw decoding disabled.
|
|
|
|
|
|
|
| |
The waf build system generates this already. No point in redoing it in
the header file.
The legacy build system (which we really should drop) didn't; fix it.
|
|
|
|
| |
Apparently this is sufficient.
|
|
|
|
| |
Small bug, much pain.
|
|
|
|
| |
It's unnecessary and slow. Doesn't help too much, though.
|
| |
|
|
|
|
|
|
|
| |
Make a difference between different mpv_handles pointing to the same mpv
core, or different mpv cores. While we're not explicit about it, at
least avoid that someone could misunderstand when really looking for the
case of mpv_handles pointing to the same core.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Instead, force everyone to use the metadata struct and set a "title"
field. This is only a problem for the timeline producers, which set up
chapters manually. (They do this because a timeline is a separate
struct.)
This fixes the behavior of the chapter-metadata property, which never
returned a "title" property for e.g. ordered chapters.
|
|
|
|
|
|
|
| |
We must not use the frame PTS in any case. In this case, it fails
because nothing sets it up to wake up. This typically caused the player
to apparently "pause", until something else waked it up, like moving the
mouse and other events.
|
|
|
|
| |
Could lead to failure because it's essentially a race condition.
|
|
|
|
| |
Fixes #503
|