| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
enable_key_bindings()/disable_key_bindings() now prints a log message on
each call, thus we should avoid makign redundant calls.
This could probably be solved more elegantly, but since this is all
legacy/private API, don't bother.
|
|
|
|
|
|
|
|
| |
This VO is special because it normally doesn't block on vsync, but can
be made to do so. Supposedly the MMAL video output API merely sets a
"current frame" field when sending an output frame, and the firmware
will pick up whatever frame that field is set to at the time of a
vsync.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If this mode is enabled, the player tries to strictly synchronize video
to display refresh. It will adjust playback speed to match the display,
so if you play 23.976 fps video on a 24 Hz screen, playback speed is
increased by approximately 1/1000. Audio wll be resampled to keep up
with playback.
This is different from the default sync mode, which will sync video to
audio, with the consequence that video might skip or repeat a frame once
in a while to make video keep up with audio.
This is still unpolished. There are some major problems as well; in
particular, mkv VFR files won't work well. The reason is that Matroska
is terrible and rounds timestamps to milliseconds. This makes it rather
hard to guess the framerate of a section of video that is playing. We
could probably fix this by just accepting jittery timestamps (instead
of explicitly disabling the sync code in this case), but I'm not ready
to accept such a solution yet.
Another issue is that we are extremely reliant on OS video and audio
APIs working in an expected manner, which of course is not too often
the case. Consequently, the new sync mode is a bit fragile.
|
|
|
|
|
|
|
|
|
|
| |
For video sync, we want separate playback speed controls for user-
requested speed and the "correction" speed for video timing. Further, we
use this separation to make sure only a resampler is inserted if
playback speed is only changed for video sync correction.
As of this commit, this is basically inactive code. It's just
preparation for the video sync code (the following commit).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Additionally to taking the average, this tries to use the demuxer FPS to
eliminate jitter, and applies some other heuristics to check if the
result is sane.
This code will also be used for the display sync code (it will actually
make use of the require_exact parameter).
(The value of doing this over keeping the simpler demux_mkv hack is
somewhat questionable. But at least it allows us to deal with other
container formats that use jittery timestamps, such as mp4 remuxed
from mkv.)
|
|
|
|
|
|
|
|
|