| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
In a shit show of subtle corner case interactions, making the demuxer
cache buffer the entire file can display a small buffered time if
subtitles are enabled. The reason is that some subtitle decoders may
read in advance infinitely, i.e. they read the entire subtitle stream.
Then, since the other streams (audio/video) have logically reached EOF,
and the subtitle stream is set to ds->active==true. This will have to be
fixed properly later to account buffering for subtitle-only files
(another corner case) correctly, but for now this is less annoying.
|
|
|
|
|
| |
As builtin script, it should not register global key bindings, and add
them to input.conf instead. This is similar to what stats.lua does.
|
|
|
|
|
|
|
|
|
|
|
|
| |
We don't hope to auto-detect them at load time, as that would be too
much of a pain - even FFmpeg requires fetching and parsing of video
packets, and exposes the information only via deprecated API.
But there still needs to be a way to select them by default. This is
also needed to get the first CC packet at all (without seeking back).
This commit also attempts to clean up locking a bit, which is a PITA,
but it's better be careful & clean.
|
|
|
|
| |
Not sure why there was 110, or why there is even a default.
|
|
|
|
|
|
|
|
|
| |
Normally such code is didsabled by have_mglsl==false in
check_gl_features(), but apparently not this one.
Just fix it. Seems also more readable.
Fixes #5069.
|
|
|
|
|
|
|
| |
Apparently this is required, but it doesn't check for it. To be fair,
this was tested by creating a compatibility context and pretending it's
GL 2.1. GL_ARB_shader_storage_buffer_object actually requires GL 4.0 or
up, but GL_ARB_uniform_buffer_object requires only GL 2.0.
|
| |
|
|
|
|
|
| |
Apparently, and to nobody's surprise, mkv can contain snow. It does
so with the V_SNOW tag. We can now play back snow-inside-mkv in mpv.
|
| |
|
|
|
|
|
|
| |
Pretty fucking ugly, but I'm not a UI designer.
Of course only does something with --demuxer-seekable-cache.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to
https://github.com/libarchive/libarchive/pull/773#issuecomment-334892291
we're not allowed to "continue reading" (post above) or performing "more
operations" (comments in archive.h header), whatever that means. Assume
closing and freeing the archive is still ok.
Since the codec already includes logic for closing and reopening the
archive for seeking in unseekable archives, this probably isn't too bad.
Untested due to lack of crashing sample (I lost my original test case,
and as recently user-provided one didn't crash).
|
|
|
|
|
| |
screenshot-template could be set to e.g. "%F/%04n", so we want to
make sure that the path generated from the template actually exists.
|
|
|
|
| |
Stupid libass.
|
|
|
|
|
| |
When the ifdeffery for the frame_params API was added, the new code
accidentally didn't include this.
|
| |
|
|
|
|
|
| |
"garbage" is considered offensive. The result will still be pretty bad
though (currently build failures).
|
|
|
|
|
|
|
|
|
|
|
| |
Apparently some people want this. Actually making it compile is still
their problem, though, and I expect that build with FFmpeg upstream will
occasionally be broken (as it is right now). This is because mpv also
relies on API provided by Libav, and if FFmpeg hasn't merged that yet,
it's not our problem - we provide a version of FFmpeg upstream with
those changes merged, and it's called ffmpeg-mpv.
Also adjust the README which still talked about FFmpeg releases.
|
|
|
|
|
|
|
|
|
|
|
| |
vo_gpu.c will call gl_video_icc_auto_enabled() to check whether it
should retrieve the ICC profile. But the value returned by this function
will be outdated, because gl_video_update_options() is not called yet.
Change the order of function calls so that this is done after updating
the options.
(This is fairly chaotic, but I guess this code will be refactored a
dozen of times anyway in the future.)
|
|
|
|
|
|
|
|
| |
All this code used to be required by the old variants of the libavcodec
hw decoding APIs. Almost all of that is gone, although the mediacodec
API unfortunately still pulls in some old stuff (but not all of it).
(mediacodec build/functionality is untested, but should work.)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All of this was dead code and completely unused.
get_buffer2_hwdec() is the biggest chunk. One unfortunate thing about it
is that, while it was active, it could perform a software fallback much
faster, because it didn't have to wait until a full frame is decoded (it
actually decoded a full frame, but the current code has to decode many
more frames due to the codec delay, because the current code waits until
the API returns a decoded frame.) We should probably restore the latter,
although since it's an optional optimization, and the current behavior
doesn't change with the removal of this code, don't actually do anything
about it.
|
|
|
|
|
| |
And move the remaining code (just 2 struct constant definitions) to
vd_lavc.c.
|
| |
|
|
|
|
| |
See #5062.
|
|
|
|
| |
Should fix #5062.
|
|
|
|
| |
Do this by replacing the first space after a line break with "\h".
|
|
|
|
|
|
|
|
|
|
|
| |
This is where it should be. It only wasn't because of an old libavcodec
bug, that returned the side data only on every IDR. This required some
sort of caching, which is now dropped. (mp_image wouldn't have been able
to do this kind of caching, because this code is stateless.) We don't
support these old libavcodec versions anymore, which is why this is not
needed anymore.
Also move initialization of rotation/stereo stuff to dec_video.c.
|
|
|
|
| |
(Not tested on Windows and OSX.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This simply didn't work. Unlike cuda-copy, this is a true hwaccel, and
obviously we need to provide it a device.
Implement this in a relatively generic way, which can probably reused
directly by videotoolbox (not doing this yet because it would require
testing on OSX).
Like with cuda-copy, --cuda-decode-device is ignored. We might be able
to provide a more general way to select devices at some later point.
|
|
|
|
|
|
|
| |
This is just a dumb consequence of HWDEC_ types somehow being part of
both decoder and VO. Obviously, the VO should only care about supporting
specific hardware surface types or providing specific device types, but
until they are separated, stupid unintuitive mismatches will occur.
|
|
|
|
|
|
| |
Somewhat useful for debugging. Unfortunately libass (or something else)
strips leading whitespace, making it look slightly more ugly than
necessary. Still an improvement.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Even though only 1 seek range is supported at the time.
Other than preparation for possibly future features, the main gain is
actually that we finally separate the reporting for the buffering, and
the seek ranges. These can be subtly different, so it's good to have a
clear separation.
This commit also fixes that the ts_reader wasn't rebased to the start
time, which could make the player show "???" for buffered cache amount
in some .ts files and others (especially at the end, when ts_reader
could become higher than ts_max). It also fixes writing the cache-end
field in the demuxer-cache-state property: it checked ts_start against
NOPTS, which makes no sense.
ts_start was never used (except for the bug mentioned above), so get rid
of it completely. This also makes it convenient to move the segment
check for last_ts to the demux_add_packet() function.
|
|
|
|
|
|
| |
Fist we were required to use them for ABI compat. reasons (and other
BS), now they're deprecated and we're supposed to access them directly
again.
|
|
|
|
| |
Fixes #5055.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current invocation of bstr_cut is as good as no cutting at all.
Almost the entire header is reread in every iteration of the loop.
I don't know how many styles libavcodec tends to generate, but if
(now or in the future) it generates many, then this loop is slow
for no good reason. If anything, the code would be more clear and
have the same performance if it didn't call bstr_cut at all.
The intention here (and the sensible thing regardless) seems to be
to skip the part of the string that bstr_find has already looked
through and found nothing. This commit additionally skips the whole
substring, because overlapping matches are impossible.
|
|
|
|
|
|
|
| |
Signed-off-by: Daniel Kucera <daniel.kucera@gmail.com>
Signed-off-by: wm4 <wm4@nowhere>
Uses different style and different logic from original PR.
|
|
|
|
|
|
|
|
| |
See manpage additions.
(In ffmpeg-mpv and Libav, this is still called "cuvid". Libav won't work
yet, because it has no frame params support yet, but this could get
fixed soon.)
|
|
|
|
|
|
|
| |
It isn't all that reliable, and improving it would make startup slower
and require more complexity. There isn't even a good reason to do this
(other than semi-broken mkv files), so don't do it. Also see previous
commit.
|
|
|
|
|
|
|
|
|
|
|
| |
In some cases, demux_mkv will detect a start time slightly above 0, but
there might still be a subtitle starting at exactly 0. When the player
rebases the timestamps to assumed start time, the subtitle will have a
slightly negative timestamp in the end. libavcodec's subtitle converter
turns this into a larger number due to underflow. Fix by clamping
subtitles always to 0, which may or may not be what you want.
At least it fixes #5047.
|
| |
|
|
|
|
| |
No idea if this is correct.
|
|
|
|
|
| |
Most likely will cause new warnings with avfilter_graph_alloc_filter()
on old libavfilter versions. Ingore that part.
|
|
|
|
|
|
|
|
|
| |
This is required now. Can't have FFmpeg upstream randomly break us and
then not fix it (like this recent EOF issue).
Upstream FFmpeg is of course still supported, but you will need to edit
the build scripts. Official support is only with the master branch of
our own repo.
|
|
|
|
|
|
|
|
| |
This removes the need for codec- and API-specific knowledge in the
libavcodec hardware acceleration API user. For mpv, this removes the
need for vd_lavc_hwdec.pixfmt_map and a few other things. (For now, we
still keep the "old" parts for the sake of supporting older Libav, and
FFgarbage.)
|
|
|
|
|
|
| |
params->rc was ignored in the calculation for the buffer size. I fucking
hate this stupid ra_tex_upload signature where *rc is randomly relevant
or not.
|
|
|
|
|
|
| |
Coverity complains about this, but it's probably a false positive.
Anyway, rewrite it in a slightly more readable way. Now it's more
obvious that it is correct.
|
|
|
|
|
|
|
| |
I _think_ this confuses Coverity and it thinks there is uninitialized
data to be read. Initialize the array to change/remove the warning, or
if there's a real problem, to make it easier to detect. (Basically apply
defensive coding.)
|
|
|
|
| |
Plus restructure the error path to make this simpler.
|
|
|
|
|
| |
Most commonly happened with --end, in which case that field tends to be
set.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Even if the demuxer cache does not multiple ranges yet. This is to
reduce the pain should caching of multiple ranges ever be implemented.
Also change it from the sub properties stuff to return a mpv_node
directly, which is less roundabout. Sub-property access won't work
anymore, though.
Remove the seekable-start/-end fields as well, as they're redundant with
the ranges.
All this would normally be considered an API change, but since it's been
only a few days with no known users, change it immediately.
This adds some node.c helpers as well, as the code would be too damn
fugly otherwise.
|
|
|
|
|
|
|
|
| |
Should speed up seeks.
(Unfortunately it's useless for backstepping. Backstepping is like
precise seeking, except we're unable to drop frames, as we can't know
the previous frame if we drop it.)
|
|
|
|
|
| |
Recent regression. Crashes because it sets the segmented flag, without
actually setting the fields required for segmentation.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Comparing mpv's implementation against the ACES ODR reference samples
and algorithms, it seems like they're happy desaturating highlights
_way_ more aggressively than mpv currently does. And indeed, looking at
some example clips like The Redwoods (which is actually well-mastered),
the current desaturation produces unnatural-looking brightness fringes
where the sky meets the treeline.
Adjust the algorithm to make it apply to a much larger, more gradual
brightness region; and change the interpretation of the parameter. As a
bonus, the new parameter is actually sanely scaled (higher values = more
desaturation). Also, make it scale based on the signal level instead of
the luminance, to avoid under-desaturating bright blues.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Avoids that cache seeking is not possible with files that have audio
frames with no timestamps (such as avi, sometimes mkv sub-packets from
lacing). These would set back_pts (first seekable PTS) to NOPTS, and
thus disable cache seeking completely. Instead, prune such packets until
we find one with timestamps.
One corner case is that the new next good packet might be in the forward
cache. In this case we defer dropping until the next time this code is
run, and the reader position has possibly moved past the drop point.
|
|
|
|
|
|
|
|
| |
In theory, start/ts_min could be set to NOPTS, in which case
"pts < start" for a valid pts would always evaluate to false.
Also remove the redundant "in-cache seek is possible.." message, as
there's always another message when cache seeks are done.
|
|
|
|
|
| |
Fixes AVI in particular, which abuses DTS for reordered PTS. (It's not
really DTS...)
|
|
|
|
|
|
| |
The seek range computation ignored streams with no timestamps. For
things like buffer estimation this is OK and wanted, but the seek range
needs to be conservative.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Which parts of the queue are considered forward or backward cache
depends on ds->reader_header. The packet at ds->reader_head, as well as
all packets following it (via the ->next field) are considered forward.
The fw_packs/fw_bytes/bw_bytes must be updated accordingly.
This broke in demux_add_packet(), when ds->reader_head was _not_ set on
the first packet (or before). This could happen since commit
05ae571241a, which can require skipping packets (so they immediately end
up in the backbuffer).
|
|
|
|
|
|
|
|
|
| |
With the timeline code, a packet at the start or end of a segment can
refer to an invisible frame. So it doesn't extend the seek range, and
the timestamp should be clipped to the actual segment range.
Also restructure recompute_keyframe_target_pts() to be hopefully less
confusing.
|
|
|
|
|
|
| |
Restores some behavior from before the demuxer cache changes, though
affects mostly just OSD display. The unknown queue state is reserved for
streams with missing or messed up timestamps.
|
|
|
|
|
|
| |
Fully fixes behavior of the files mentioned in the previous commit. Will
probably lead to worse behavior if someone tries to fix real video and
cover art tracks, but that's a broken fringe case anyway.
|
|
|
|
|
|
| |
This fixes .cue files with audio files that contain attached pictures to
some degree. demux_timeline.c just discarded packets with unset index,
so the picture was never fed to the decoder.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Directory-opening never worked on Windows because MSVCRT's open()
doesn't open directories and its |