| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Recent regression. Crashes because it sets the segmented flag, without
actually setting the fields required for segmentation.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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 fstat() doesn't recognise directory
handles. These are just MSVCRT restrictions, and the Windows API itself
has no problem with opening directories as file objects, so reimplement
mpv's mp_open and mp_stat to use the Windows API directly. This should
fix directory playback.
This also populates the st_dev and st_ino fields of struct stat, so
filesystem loop checking in demux_playlist.c should now work on Windows.
Fixes #4711
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new_segment field was used to track the decoder data flow handler of
timeline boundaries, which are used for ordered chapters etc. (anything
that sets demuxer_desc.load_timeline). This broke seeking with the
demuxer cache enabled. The demuxer is expected to set the new_segment
field after every seek or segment boundary switch, so the cached packets
basically contained incorrect values for this, and the decoders were not
initialized correctly.
Fix this by getting rid of the flag completely. Let the decoders instead
compare the segment information by content, which is hopefully enough.
(In theory, two segments with same information could perhaps appear in
broken-ish corner cases, or in an attempt to simulate looping, and such.
I preferred the simple solution over others, such as generating unique
and stable segment IDs.)
We still add a "segmented" field to make it explicit whether segments
are used, instead of doing something silly like testing arbitrary other
segment fields for validity.
Cached seeking with timeline stuff is still slightly broken even with
this commit: the seek logic is not aware of the overlap that segments
can have, and the timestamp clamping that needs to be performed in
theory to account for the fact that a packet might contain a frame that
is always clipped off by segment handling. This can be fixed later.
|
| |
|
|
|
|
| |
Needed for a failed thing, leaving it anyway because it causes no harm
and might be less awkward if struct virtual_stream is possibly extended
anyway in the future.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Although seeking past the cached range will trigger a low level seek, a
seek into the region between cache end and last video key frame would
simply seek to the video key frame. This meant that you could get
"stuck" at the end of the file instead of terminating playback when
trying to seek past the end.
One change is that we fix this by _actually_ allowing SEEK_FORWARD to
seek past the last video keyframe in find_seek_target().
In that case, or otherwise seeking to cache buffer end, it could happen
that we set ds->reader_head=NULL if the seek target is after the current
packet. We allow this, because the end of the cached region is defined
by the existence of "any" packet, not necessarily a key frame. Seeking
there still makes sense, because we know that there is going to be more
packets (or EOF) that satisfy the seek target.
The problem is that just resuming demuxing with reader_head==NULL will
simply return any packets that come its way, even non-keyframe ones.
Some decoders will produce ugly soup in this case. (In practice, this
was not a problem, because seeking at the end of the cached region was
rare before this commit, and also some decoders like h264 will skip
broken frames by default anyway.)
So the other change of this commit is to enable key frame skipping.
As a nasty implementation detail, we use a separate flag, instead of
setting reader_head to the first key frame encounted (reader_head being
NULL can happen after a normal seek or on playback start, and then we
want to mirror the underlying demuxer behavior, for better or worse).
This change is relatively untested, so you get to keep the pieces for
yourself.
|
| |
|
|
| |
Looks ugly on the status line and could upset the buffering logic.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Seems like most code dealing with this was for setting it in redundant
cases. Now SEEK_BACKWARD is redundant, and SEEK_FORWARD is the odd one
out.
Also fix that SEEK_FORWARD was not correctly unset in try_seek_cache().
In demux_mkv_seek(), make the arbitrary decision that a video stream is
not required for the subtitle prefetch logic to be active. We might want
subtitles with long duration even with audio only playback, or if the
file is used as external subtitle.
|
| |
|
|
|
|
|
|
|
| |
If a packet uses segmentation, the codec field must be set. Copying the
codec field was forgotten as an oversight, which is why this just
crashes. This showed up only now, because demux_copy_packet() was not
used before in the main demux path until recently.
Fixes #5027.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This improves upon the previous commit, and partially rewrites it (and
other code). It does:
- disable the seeking within cache by default, and add an option to
control it
- mess with the buffer estimation reporting code, which will most likely
lead to funny regressions even if the new features are not enabled
- add a back buffer to the packet cache
- enhance the seek code so you can seek into the back buffer
- unnecessarily change a bunch of other stuff for no reason
- fuck up everything and vomit ponies and rainbows
This should actually be pretty usable. One thing we should add are some
properties to report the proper buffer state. Then the OSC could show a
nice buffer range. Also configuration of the buffers could be made
simpler. Once this has been tested enough, it can be enabled by default,
and might replace the stream cache's byte ringbuffer.
In addition it may or may not be possible to keep other buffer ranges
when seeking outside of the current range, but that would be much more
complex.
|
| |
|
|
|
| |
If a suitable keyframe cannot be found in each stream's
readahead cache, fallback to a regular seek.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
More the ignore_eof field to the internal demux_stream struct. This is
relatively messy, because the internal struct exists only once the
stream is created, and after that setting the ignore_eof flag is a race
condition. We could bother with adding demux_add_sh_stream() parameters
for this, but let's not. So in theory a tiny race condition is
introduced, which can never be triggered since all demux API functions
are called by the playback thread only anyway.
Fix that ts_offset is accessed without log (this was introduced much
earlier by myself).
Introduce an alternative way of avoiding the annoying EOF reached
messages by not resetting the EOF flags for CC streams when a CC packet
is added. This makes the second commit in the PR which added the
original fix unnecessary.
As another cosmetic change merge the check in cached_demux_control()
into a single if().
In the future, the CC pseudo-stream should probably be replaced with an
entire pseudo-demuxer or such, which would avoid some of the messiness
(or maybe not, we don't know yet).
|
| | |
|
| |
|
|
| |
Fuck this thing.
|
| |
|
|
|
|
|
|
|
|
|
| |
iive agreed to relicense things that are still in mpv to LGPLv2.1. So
change the licenses of the affected files, and rename the configure
switch for LGPL mode to --enable-preliminary-lgpl2.
(The "preliminary" part will probably be removed from the configure
switch soon as well.)
Also player/main.c hasn't had GPL parts since a few commits ago.
|
| |
|
|
|
| |
It's deprecated, and av_packet_copy_props() is nearly equivalent. It's
also more widely supported.
|
| |
|
|
|
|
|
| |
See "Copyright" file for caveats.
This changes the remaining "almost LGPL" files to LGPL, because we think
that the conditions the author set for these was finally fulfilled.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds handling of spherical video metadata: retrieving it from
demux_lavf and demux_mkv, passing it through filters, and adjusting it
with vf_format. This does not include support for rendering this type of
video.
We don't expect we need/want to support the other projection types like
cube maps, so we don't include that for now. They can be added later as
needed.
Also raise the maximum sizes of stringified image params, since they
can get really long.
|
| |
|
|
| |
More betterer.
|
| |
|
|
|
|
|
|
| |
If --demuxer-mkv-probe-start-time=no is used, and a seek is triggered on
start, then cluster_start will be 0, and the packet reading code will
print an error message about not finding valid data. This fixes itself
since it invokes the resync code, but it's still pretty ugly. Avoid this
by always initializing cluster_start.
|
| |
|
|
|
|
|
|
| |
This currently is only limited to Android. Its stdlib contains the
things that mpv's POSIX check checks for, but unfortunately not
glob().
This fixes Android compilation broken in 70a70b9da .
|
| |
|
|
| |
We don't even set it anymore. This really should be up to libavformat.
|
| |
|
|
|
|
|
|
|
| |
It seems like adjusting the raw stream ID should be done only for DVD.
Otherwise, getting the subtitle language for Bluray breaks.
Untested. Regression since fb9a32977d6.
Fixes #4611 (probably).
|
| |
|
|
|
|
|
|
| |
This API isn't deprecated (yet?), but it's still inferior and harder to
use than avcodec_free_context().
Leave the call only in 1 case in af_lavcac3enc.c, where we apparently
seriously close and reopen the encoder for whatever reason.
|
| |
|
|
|
|
|
|
| |
Was at least somewhat broken, and is misleading. I don't really have an
idea why FFmpeg has two AVOptions here anyway. We don't need to care,
and I'm only aware of 1 user trying this option ever.
See #4579.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The first time I saw a user try to use this option, and apparently it
didn't work. I'm not exactly sure why, but the code seems to be broken
anyway. Apart from not doing any error checking (neither mallocs nor
warning the user against invalid input), it forgets to add a 0
terminator.
Use the corresponding AVOption instead, which probably works.
See #4579.
|
| |
|
|
| |
Closes #4414
|
| |
|
|
|
| |
POSIX requires glob(), so no need to check for it. Together with the
fact that we can emulate glob() on Windows, glob() is always available.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All relevant authors have agreed.
I'm removing the NV12 FourCC, which was added in f910f3d9 by someone who
was not contacted for the relicensing. I doubt the remaining code is
copyrightable (basically all what remains the fact is that NV12 uses the
same amount of space like YV12), but in this case I feel more
comfortable removing it.
Might contain some trace amounts of "michael"'s copyright, who agrees
with LGPL only once the core is relicensed - but with the core already
mostly relicensed, I'm changing the license header to LGPL, and only
marking this in the "Copyright" file.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
cehoyos, who did not agree to the relicensing, added bcb5c78ce3. If
there was copyright, we consider it gone, because the table changed. It
does not map file extension to a FourCC anymore, and codecs.conf is
gone. The new mapping is a libavcodec codec name (happens to be the same
as the file extension).
The same applies to commits 60ecafec, b749836b, 5b3e3be1. None of these
authors were contacted. These were before the code was replaced with a
table (in d0326807). The parts outside of demux_mf.c were removed a long
time ago. Like in the previous comment, we don't think any copyright
applies at least to the new code (at least after the FourCC removal).
iive authored 0aa37a0d, which is probably still left in some form, and
makes demux_mf.c "LGPL 3 or later".
stream_avdevice.c (unrelated) has been marked as LGPL before.
|
| |
|
|
|
| |
Who says that the first member is an array or whatever? It depends on
whatever the matroska.py script generates.
|
| |
|
|
|
|
|
|
|
|
|
| |
- Fix a signed/unsigned comparison involving info.segment_uid.len
(doesn't actually warn here, but seems fragile). Code was previously
safe though.
- Match up all printf format strings with the respective value types,
using the *int*_t printf specifiers where necessary, and fixing
multiple signed/unsigned differences. Removed some casts that
otherwise may have truncated values.
- Fix a warning when initializing ebml_info.
|
| |
|
|
|
|
| |
On some platforms, unsigned long and uint64_t aren't the same type,
after all. As this is just a MP_VERBOSE message, risking truncation in
some cases seems OK.
|
| |
|
|
|
| |
The file consists of stream/tv.c contents. Use the copyright header of
that file.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As usual, the history of these files is a bit murky. It starts with the
initial commit. (At which some development had already been done,
according to the AUTHORS and ChangeLog files at the time, we should be
but covered with relicensing agreements, though.) then it goes on with
complete lack of modularization, which was cleaned up later (cd68e161).
As usual, we don't consider the copyright of the stuff that has been
moved out cleanly.
There were also contributions to generic code by people who could not be
reached or who did not agree to the relicensing, but this was all
removed.
The only patches that we could not relicense and which were still in the
current code in some form are from Dénes Balatoni: 422b0d2a, 32937181.
We could not reach him, so commits f34e1a0d and 18905298 remove his
additions. It still leaves the demux_control() declaration itself, but
we don't consider it copyrightable. It's basically an idiom that existed
in MPlayer before that change, applied to the demuxer struct. (We even
went as far as making sure to remove all DEMUXER_CTRLs the original
author added.)
Commit be54f481 might be a bit of a corner case, but this was rewritten,
and we consider the old copyright removed long ago.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Similar purpose as f34e1a0deea45e.
Somehow this is much more natural too, and needs less code.
This breaks runtime updates to duration. This could easily be fixed, but
no important demuxer does this anyway. Only demux_raw and demux_disc
might (the latter for BD/DVD). For the latter it might actually have
some importance when changing titles at runtime (I guess?), but guess
what, I don't care.
|
| |
|
|
|
|
|
|
| |
This is more uniform, and potentially gets rid of some past copyrights.
It might be that this subtly changes caching behavior (it seems before
this, it synced to the demuxer if the length was unknown, which is not
what we want.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
MaxCLL is the more authoritative source for the metadata we are
interested in. The use of mastering metadata is sort of a hack anyway,
since there's no clearly-defined relationship between the mastering peak
brightness and the actual content. (Unlike MaxCLL, which is an explicit
relationship)
Also move the parameter fixing to `fix_image_params`
I don't know if the avutil check is strictly necessary but I've included
it anyway to be on the safe side.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
List of changes:
1. Kill nom_peak, since it's a pointless non-field that stores nothing
of value and is _always_ derived from ref_white anyway.
2. Kill ref_white/--target-brightness, because the only case it really
existed for (PQ) actually doesn't need to be this general: According
to ITU-R BT.2100, PQ *always* assumes a reference monitor with a
white point of 100 cd/m².
3. Improve documentation and comments surrounding this stuff.
4. Clean up some of the code in general. Move stuff where it belongs.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This file is an leftover from when img_format.h was changed from using
the ancient FourCCs (based on Microsoft multimedia conventions) for
pixel formats to a simple enum. The remaining cases still inherently
used FourCCs for whatever reasons.
Instead of worrying about residual copyrights in this file, just move it
into code we don't want to relicense (the ancient Linux TV code). We
have to fix some other code depending on it. For the most part, we just
replace the MP_FOURCC macro with libavutil's MKTAG (although the macro
definition is exactly the same). In demux_raw, we drop some pre-defined
FourCCs, but it's not like it matters. (Instead of
--demuxer-rawvideo-format use --demuxer-rawvideo-mp-format.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since this demuxer is based on code by michael, this file can become
LGPL only once the mpv core becomes LGPL, and this is preparation for
it.
There were quite a lot of changes for rearranging preferred libavformat
vs. internal MPlayer demuxers, codec mappings, and filename extensions,
but all this got removed, so some of the relevant authors weren't asked.
cehoyos, who disagreed with LGPL, made a few changes in the past (mostly
codec mapping and deinterlacing related things), but all of them were
removed, mostly due to libavformat API cleanups.
adland, who could not be reached, did commit 057916ee65, but it's easy
to essentially revert the change (this is what the source changes in
this commit do), so we don't need to think about it.
Chris Welton, who could not be reached, made a simple change in com |
