Commit Graph

1331 Commits

Author SHA1 Message Date
sfan5 10fbd305c8 demux: add function to refresh a track without (de-)selecting it 2020-11-27 17:28:59 +01:00
Mia Herkt 49d6a1e77d
demux_lavf: initialize ReplayGain data
This was causing undefined behavior when playing streams without RG tags
but with RG enabled. Broken in 585f9ff42f.

Thanks to uau for bisecting.
2020-10-23 14:22:57 +02:00
wm4 16b44d93f7 Revert "demux: add a POS"
This reverts commit 4f18e7927b.

It was a mistake, and barely anyone needs this.
2020-10-08 11:17:10 +02:00
wm4 4f18e7927b demux: add a POS
I regret doing this so much, it's fucking garbage.

Fixes: #5100
2020-10-08 00:35:37 +02:00
wm4 9806e9f82b command, demux: make drop-buffers reset state even harder
Leave nothing left when it's executed.
2020-09-17 15:34:40 +02:00
wm4 74e62ed2d1 Revert "demux_lavf: always give libavformat the filename when probing"
This reverts commit 41243e7c4f.

This fixes image format detection. FFmpeg has an utter called "image2",
which is designed to read patterns in filenames (so you can play
something like "%*.jpg" for all jpg files in the current directory).
"image2" is not what we want; it's just broken with custom I/O like
mpv uses it, and we don't want to "accidentally" interpret filenames
as pattern. That's why mpv blacklists it.

Unfortunately, "image2" is sometimes the format that FFmpeg's probe API
returns as best match. Thus demux_lavf fails to detect the file type,
and after some more futile attempts, we end up at demux_mf, which uses
detection by file extension. (Not sure why. I guess MPlayer did that,
and foudn that sufficient.) If the file extension is wrong (which
happens a lot because apparently the world is full of idiots who don't
manage to get the most simple things right), the image "loads", but
decoding obviously fails.

There's no easy way around this. The FFmpeg API has no mechanism to
exclude a specific format from probing (like image2, which breaks stuff
for us). Out of the 5 probe functions the API provides, none can probe
a specific format or include or exclude specific formats. The main
problem is that AVInputFormat.read_probe is a private symbol.

FFmpeg itself has no problem opening such files. It turns out that it
works, because even though image2 by itself uses detection by file
extension, it uses private API to further probe the exact format. It
explicitly excludes itself to prevent recursion.

But fortunately, that also means that it's impossible to get the image2
format if no filename is passed to the prober. (No filename, no file
extension.) Apparently we pass it in because it helps in corner cases.
Until almost 3 years ago, we passed the filename only when normal
probing already failed. Restore this by this revert. It makes
incorrectly named files work. The revert also makes the (apparently
forgotten) comment above the touched line of code true again.

Yes, quite possible that this breaks some mp3s again. You can't win
with FFmpeg. Thanks FFmpeg for making us fail at opening simple image
files and/or the most widely used file format for audio.
2020-08-23 12:44:54 +02:00
wm4 85f38a9765 demux_mf: actually report errors
Well, whatever. Only results in an error message being printed, because
there is no other error reporting mechanism, and the general policy is
to keep trying with the rest of the data (i.e. not report EOF).
2020-08-22 20:46:45 +02:00
wm4 d6bf3880d7 demux_mkv: warn against some other aspects of mismatching codec data
Such files violate the specification. Unfortunately, I could not test
whether it really works correctly, since I don't have a sample at hand
that is not broken in this regard.
2020-08-16 01:00:29 +02:00
wm4 06033df715 demux_lavf: workaround reading gif from unseekable streams
FFmpeg, being the pile of trash as usual, recently broke this. Add our
own trash hack to trashily workaround this shit.

Fixes: #7893
2020-07-09 12:29:22 +02:00
wm4 07b0c18bad build: change filenames of generated files
Force them into a more consistent naming schema.
2020-06-04 16:59:05 +02:00
Kevin Mitchell 2aa5964b43
stream_libarchive: remember archive headers from initial open
The header probing hacks were previously all broken. They only worked
the first time the archive file was open. Since subsequent opens (on
seek) occured in the middle of the source stream rather than at the
beginning, the stream_read_peek calls meant to retrieve the headers were
instead returning random bytes in the middle of the file.

Perhaps the worst manifestation of this was when seeking within a
multi-volume .rar archive with the "legacy" file naming pattern. If the
seek required a reopen, the fact that the archive was multi-volume would
be forgotten and the file would appear truncated terminating playback.

To solve this, only perform the header probling the first time the
archive is opened. Save the results and reuse them on subsequent
reopens. Put this in a wrapper so this is transparent to
demux_libarchive.
2020-04-28 22:13:03 -07:00
wm4 ace169ad0f demux_mkv: add png intra support
Evil, non-standard shit.

Sample file and script:
https://github.com/mpv-player/random-stuff/tree/master/matroska/png
2020-04-16 00:03:26 +02:00
wm4 30855638df demux_mkv: concatenate multiple tags
Instead of just picking the last tag that was encountered. The order of
the tags still depends on the file order.

This is probably wrong, and we should respect TargetTypeValue. But
despite staring at the spec, I have no idea what the hell this should
do, so fuck that.

Fixes: #7604
2020-04-13 16:28:15 +02:00
wm4 dc9135b164 demux: don't let --sub-create-cc-track add a track for attached pictures
Unfortunately, attached pictures (from tags etc.) are treated as video
tracks. That meant --sub-create-cc-track added a CC track for them as
well. Stop doing that.

See: #7608
2020-04-13 15:56:52 +02:00
wm4 bc1a18ee24 options: cleanup .min use for OPT_CHANNELS
Replace use of .min==1 with a proper flag. This is a good idea, because
it has nothing to do with numeric limits (also see commit 9d32d62b61
for how this can go wrong).

With this, m_option.min/max are strictly used for numeric limits.
2020-04-09 11:27:38 +02:00
wm4 fd3caa264e stats: some more performance graphs
Add an infrastructure for collecting performance-related data, use it in
some places. Add rendering of them to stats.lua.

There were two main goals: minimal impact on the normal code and normal
playback. So all these stats_* function calls either happen only during
initialization, or return immediately if no stats collection is going
on. That's why it does this lazily adding of stats entries etc. (a first
iteration made each stats entry an API thing, instead of just a single
stats_ctx, but I thought that was getting too intrusive in the "normal"
code, even if everything gets worse inside of stats.c).

You could get most of this information from various profilers (including
the extremely primitive --dump-stats thing in mpv), but this makes it
easier to see the most important information at once (at least in
theory), partially because we know best about the context of various
things.

Not very happy with this. It's all pretty primitive and dumb. At this
point I just wanted to get over with it, without necessarily having to
revisit it later, but with having my stupid statistics.

Somehow the code feels terrible. There are a lot of meh decisions in
there that could be better or worse (but mostly could be better), and it
just sucks but it's also trivial and uninteresting and does the job. I
guess I hate programming. It's so tedious and the result is always shit.
Anyway, enjoy.
2020-04-09 00:33:38 +02:00
wm4 2de783125b demux: average reported download speed some more
Currently, this reported the number of received bytes per second.
Improve this slightly by averaging over 2 seconds (but still updating
every second).
2020-03-21 19:32:50 +01:00
wm4 41e96d8b6b options: fix OPT_BYTE_SIZE upper limits
As an unfortunate disaster, min/max values use the type double, which
causes tons of issues with int64_t types. Anyway, OPT_BYTE_SIZE is often
used as maximum for size_t quantities, which can have a size different
from (u)int64_t.

OPT_BYTE_SIZE still uses in64_t, because in theory, you could use it for
file sizes. (demux.c would for example be capable of caching more than
2GB on 32 bit platforms if a file cache is used. Though for some reason
the accounting code still uses size_t, so that use case is broken. But
still insist that it _could_ be used this way.)

There were various inconsistent attempts to set m_option.max to a value
such that the size_t/int64_t upper limit is not exceeded. Due to the
double max field, this didn't really work correctly. Try to fix this
with the M_MAX_MEM_BYTES constant. It's a good approximation, because on
32 bit it should allow 2GB (untested, also would probably exhaust
address space in practice but whatever), and something "high enough" in
64 bit.

For some reason, clang 11 still warns. But I think this might be a clang
bug, or I'm crazy. The result is correct anyway.
2020-03-18 20:51:38 +01:00
wm4 a550bf4927 demux_mkv: fix another integer/float conversion warning
This code could assign INT64_MAX+1 (as double) to int64_t.
2020-03-18 20:44:54 +01:00
wm4 26f4f18c06 options: change option macros and all option declarations
Change all OPT_* macros such that they don't define the entire m_option
initializer, and instead expand only to a part of it, which sets certain
fields. This requires changing almost every option declaration, because
they all use these macros. A declaration now always starts with

   {"name", ...

followed by designated initializers only (possibly wrapped in macros).
The OPT_* macros now initialize the .offset and .type fields only,
sometimes also .priv and others.

I think this change makes the option macros less tricky. The old code
had to stuff everything into macro arguments (and attempted to allow
setting arbitrary fields by letting the user pass designated
initializers in the vararg parts). Some of this was made messy due to
C99 and C11 not allowing 0-sized varargs with ',' removal. It's also
possible that this change is pointless, other than cosmetic preferences.

Not too happy about some things. For example, the OPT_CHOICE()
indentation I applied looks a bit ugly.

Much of this change was done with regex search&replace, but some places
required manual editing. In particular, code in "obscure" areas (which I
didn't include in compilation) might be broken now.

In wayland_common.c the author of some option declarations confused the
flags parameter with the default value (though the default value was
also properly set below). I fixed this with this change.
2020-03-18 19:52:01 +01:00
wm4 8d965a1bfb options: change how option range min/max is handled
Before this commit, option declarations used M_OPT_MIN/M_OPT_MAX (and
some other identifiers based on these) to signal whether an option had
min/max values. Remove these flags, and make it use a range implicitly
on the condition if min<max is true.

This requires care in all cases when only M_OPT_MIN or M_OPT_MAX were
set (instead of both). Generally, the commit replaces all these
instances with using DBL_MAX/DBL_MIN for the "unset" part of the range.

This also happens to fix some cases where you could pass over-large
values to integer options, which were silently truncated, but now cause
an error.

This commit has some higher potential for regressions.
2020-03-13 17:34:46 +01:00
wm4 d6f282e162 demux: bump --cache-secs default value
Change to it 1000 hours, which is "infinite" enough. (Hesitant to use
INFINITY, as that is not in the option's range. The option parser
rejects it because it causes only problems in API users and so on.)
2020-03-07 12:47:46 +01:00
wm4 f20dfef880 demux: mark recently added debug option as deprecated
It was the intention to remove it again after a release or two; mark it
was deprecated so nobody thinks it gets to stay.
2020-03-07 12:47:46 +01:00
wm4 8427292eb7 demux: deprecate --cache-secs
Because it's confusing and useless. If nobody complains, we'll have one
weird cache configuration option less.
2020-03-05 22:00:50 +01:00
mg 24acddbdc4 demuxer-lavf: udp_multicast rtsp-transport option 2020-03-03 18:31:20 +01:00
wm4 b31a5e3a58 demux: another hack to deal with track switching refresh
The demuxer cache employs a strange method to make track switching
instant with caching enabled. Normally this would mean you have to wait
until the cache has played out (and you get new packets, including
packets from the newly selected track), or you have to perform a slow
high level seek (decoding video again etc.). The strange method is that
it performs a demuxer-level seek without a high level seek so it looks
like a continuous stream to the decoder, and the newly select stream
gets packets at the current playback position. This is called a refresh
seek.

This works only if some weird heuristics work. It needs a packet "unique
ID", for which it uses either dts or pts. The value must be strictly
monotonic increasing. If this doesn't work, the referesh seek can't be
executed, and the user has to wait until the end of the cache. Sometimes
there are files that simply do not work.

In the present case, there's actually a hack that we can extend. Packets
with unset position are likely generated by the parser, and the hack
which this commit touches simply attempts to make up a new (hopefully
unique) position value, even if the value itself makes no sense. It only
ha to be deterministic.

It turns out libavcodec sometimes output packets with repeating position
values. This commit tries to handle this case too with the same hack.

Fixes: #7498
2020-02-29 23:03:39 +01:00
wm4 c79619f110 demux: add a way to block reading after seeks
Preparation for a future commit. The demuxer queues might be read from
other threads than the one to issue the seek, and passing SEEK_BLOCK
with such a seek will provide a convenient way to synchronize this.
2020-02-29 21:49:00 +01:00
wm4 d32ce14d2c demux_lavf: don't interpret errors as EOF
It seems sporadic errors are possible, such as connection timeouts.
Before the recent demuxer change, the demuxer thread retried many times
even on EOF, so an error was only interpreted as EOF once the decoder
queues ran out.

Change it to use EOF only. Since this may actually lead to the demuxer
thread being "stuck" and retrying forever (depending on libavformat API
behavior), I'm also adding a heuristic to prevent this, using a random
retry counter. This should not be necessary, but libavformat cannot be
trusted. (This retrying forever could be stopped by the user, but
obviously it would still heat the CPU for a longer time if the user is
not present.)
2020-02-28 17:25:07 +01:00
wm4 3ae4094ec0 demux: make seek ranges work for static images + audio
In this case the video track has seek_start == seek_end, and due to the
"seek_start >= seek_end" condition, this was considered broken, and no
seek range was created, breaking cached seeking.

Fix this by allowing the case if they're equal, and a valid timestamp.

(NB: seeking backward in this will still jump to position 0, because it
is the video timestamp. This is unfortunately how it's supposed to work.
HR-seeks will also do this, but decode and skip the entire audio until
the seek target, so it will mostly appear to work.)
2020-02-28 00:59:11 +01:00
wm4 2b628d4352 demux_timeline: fix bad EOF reporting
Exposed by commit b56e2efd5f. demux_timeline reported a bogus EOF if
"parallel" streams were used. If a virtual source reported EOF, it was
propagated as global EOF, without serving packets of other virtual
sources that have not ended yet.

Fix this by not reporting global EOF just because a source has not
returned a packet. Instead make the reader retry by returning no packet
and no EOF state, which will call d_read_packet() again with a different
source. Rely on the eof_reached flags to signal global EOF.

Since eof_reached is now more important, set it in a certain other case
when it apparently should have been set. do_read_next_packet()'s return
value is now ignored, so get rid of it.
2020-02-28 00:08:36 +01:00
wm4 05564af1ac demux_mkv: document probe-start-time option and enable it by default
This is useful with live streams, and it's not much worse than the h264
first packet hack, which reads some data anyway.

For some reason, the option wasn't even documented, so do that.

In addition, print the start time even if it's negative. That should not
be possible, but for some reason, the field is an int64_t copied from an
uint64_t so... whatever. Keeping the logging slightly more straight
forward is better anyway.
2020-02-27 22:30:46 +01:00
wm4 b56e2efd5f demux: simplify some internals, stop trying to read packets after EOF
Remove some redundant fields that controlled or indicated whether the
demuxer was/could/should prefetch. Redefine how the eof/reading fields
work.

The in->eof field is now always valid, instead of weirdly being reset to
false in random situations. The in->reading field now corresponds to
whether the demuxer thread is working at all, and is reset if it stops
doing anything.

Also, I always found it stupid that dequeue_packet() forced the demuxer
thread to retry reading if it was EOF. This makes little sense, but was
probably added for files that are being appended to (running downloads).
It makes no sense, because if the cache really tried to read until file
EOF, it would encounter partial packets and throw errors, so all is lost
anyway. Plus stream_file now handles this better. So stop this behavior,
but add a temporary option that enables the old behavior.

I think checking for ds->eager when enabling prefetching never really
made sense (could be debated, but no, not really). On the other hand,
the change above exposed a missing wakeup in the backward demuxing code.

Some chances of regressions that could make it stuck in certain states
or so, or incorrect demuxer cache state reporting to the player
frontend.
2020-02-27 22:30:46 +01:00
wm4 cf2b7a4997 sub, demux: improve behavior with negative subtitle delay/muxed subs
A negative subtitle delay means that subtitles from the future should be
shown earlier. With muxed subtitles, subtitle packets are demuxed along
with audio and video packets. But since they are demuxed "lazily",
nothing guarantees that subtitle packets from the future are available
in time.

Typically, the user-observed effect is that subtitles do not appear at
all (or too late) with large negative --sub-delay values, but that using
--cache might fix this.

Make this behave better. Automatically extend read-ahead to as much as
needed by the subtitles. It seems it's the easiest to pass the subtitle
render timestamp to the demuxer in order to guarantee that everything is
read. This timestamp based approach might be fragile, so disable it if
no negative sub-delay is used.

As far as the player frontend part is concerned, this makes use of the
code path for external subtitles, which are not lazily demuxed, and may
already trigger waiting.

Fixes: #7484
2020-02-27 02:23:58 +01:00
wm4 b873f1f8e5 demux: avoid some queue management corner cases with subtitles
Subtitle tracks are usually "lazy" (ds->eager=false), There are a number
of weird special cases associated with it. One of them is that they have
some sort of "temporary" EOF (to signal that there isn't a packet right
now, and the decoder should not block playback by waiting for more
packets). In a the next commit, I want to call mark_stream_eof() in case
of (some) of these temporary EOFs.

The problem is that mark_stream_eof() also calls the functions touched
by this commit. Basically they shouldn't do any complex work due to
these temporary EOFs (because they might happen very often). It turns
out that lazy tracks barely matter here: they do not extend the seek
range of a packet/EOF happens on them, they do not trigger seek range
joining, and they do not support backward demuxing.

This change should enable the following commit, while not causing any
behavior changes (i.e. bugs) with the current state.
2020-02-27 02:15:21 +01:00
wm4 605e1fb766 ytdl_hook, edl: add fps, samplerate codec parameters
Well, didn't help much in the case I was interested it.
2020-02-21 14:48:23 +01:00
wm4 a77780e6be edl: make it possible to set the track "default" flag
Also, the forced flag (and in the future, potentially a number of other
flags not implemented yet). See next commit for purpose.
2020-02-21 14:16:26 +01:00
wm4 9f5b9011d6 demux_edl: correct warning on duplicate parameters
A parameter that is actually used is removed from the param_names[]
array, so we can report unused parameters. This also happened on
duplicate parameters, so adjust the warning to make it less confusing.

(In any case, you're not supposed to provide duplicate parameters.)
2020-02-21 12:05:29 +01:00
wm4 6f0297dff4 edl: make it possible to delay-load files with multiple tracks
Until now, delay-loading was for files with single tracks only
(basically what DASH and HLS like to expose, so adaptive streaming and
codec selection becomes easier - for sites, not for us). But they also
provide some interleaved versions, probably for compatibility. Until
now, we were forced to eagerly load it (making startup slightly slower).

But there is not much missing. We just need a way to provide multiple
metadata entries, and use them to represent each track.

A side effect is now that the "track_meta" header can be used for normal
EDL files too.
2020-02-21 00:19:17 +01:00
wm4 6726b7a1ba demux_lavf: signal no seeking for RTSP streams without duration
RTSP supports seeking, but at least the libavformat implementation makes
this dependent on runtime behavior. So you have to perform a seek, and
check if it fails. But even if you do this, the stream is interrupted
and restarted, and there seem to be other issues.

Assume that RTSP with unknown duration means it's a live stream, and
disable seeking in this case, as suggested by the issue reporter.

Fixes: #7472
2020-02-20 15:28:49 +01:00
wm4 bd6d8d320f demux_timeline: don't open every delayed-open track on seeking
Now this was stupid. To seek a source, it obviously has to be opened...
so just don't try to seek any unused source. If the track is actually
selected during playback, a seek to the correct position is performed
anyway.
2020-02-20 15:21:27 +01:00
wm4 0020b47ffd demux: fix seek range caching with delay_open hack
These have ->segmented set (so the codec can be initialized properly),
but have no segment start or end times. This code was (probably) the
only thing which didn't handle this case.
2020-02-20 15:11:46 +01:00
wm4 e64645540a demux_timeline: warn if streams are invisible
ytdl_hook.lua can do this with all_formats and when delay_open is used,
and if the source stream actually contains both audio and video. In this
case, it might accidentally hide a media type completely, or waste
bandwidth (if the stream has true interleaved audio/video). So it's
important to warn.
2020-02-20 12:16:32 +01:00
wm4 b8f80b3854 player: print manifest per-stream bitrate information to terminal
Aka hls-bitrate. In turn, remove the demux_lavf.c hack, which made the
track title use this.
2020-02-19 16:26:22 +01:00
wm4 fbc226af51 demux: cosmetic change
This was sort of asymmetric and annoying.
2020-02-17 00:04:56 +01:00
wm4 26ec5862b3 demux: update file-size property even when paused
While paused, the decoders typically stop reading data from the demuxer.
But for some reason, the file size is returned as a public field in
struct demuxer (wat...), and updated only when the packet reading
function is called. This caused the file size property to always return
the same value when paused, even though the demuxer thread was reading
new data, and the internal file size was updated.

Fix with a simple hack.
2020-02-16 23:59:21 +01:00
wm4 1a54339705 demux: only query stream size at most once per second
Instead of every packet. Doing it every packet led to the performance
regression mentioned in the fstat() commit. This should now be over, but
out of being careful, don't query the file size that often. This is only
used for user interface things, so this should not cause any problems.

For the sake of leaving the code compact, abuse another thing that is
updated only every second (speed statistics).
2020-02-16 23:49:42 +01:00
wm4 27bf978e75 demux: invert update_cache() locking
Equivalent, just slightly more convenient for the following change.
2020-02-16 23:43:13 +01:00
wm4 7d11eda72e Remove remains of Libav compatibility
Libav seems rather dead: no release for 2 years, no new git commits in
master for almost a year (with one exception ~6 months ago). From what I
can tell, some developers resigned themselves to the horrifying idea to
post patches to ffmpeg-devel instead, while the rest of the developers
went on to greener pastures.

Libav was a better project than FFmpeg. Unfortunately, FFmpeg won,
because it managed to keep the name and website. Libav was pushed more
and more into obscurity: while there was initially a big push for Libav,
FFmpeg just remained "in place" and visible for most people. FFmpeg was
slowly draining all manpower and energy from Libav. A big part of this
was that FFmpeg stole code from Libav (regular merges of the entire
Libav git tree), making it some sort of Frankenstein mirror of Libav,
think decaying zombie with additional legs ("features") nailed to it.
"Stealing" surely is the wrong word; I'm just aping the language that
some of the FFmpeg members used to use. All that is in the past now, I'm
probably the only person left who is annoyed by this, and with this
commit I'm putting this decade long problem finally to an end. I just
thought I'd express my annoyance about this fucking shitshow one last
time.

The most intrusive change in this commit is the resample filter, which
originally used libavresample. Since the FFmpeg developer refused to
enable libavresample by default for drama reasons, and the API was
slightly different, so the filter used some big preprocessor mess to
make it compatible to libswresample. All that falls away now. The
simplification to the build system is also significant.
2020-02-16 15:14:55 +01:00
wm4 c92c08edc6 edl: add mechanism for delay loading streams
Add something that will access an URL embedded in EDL only when the
track it corresponds to is actually selected. This is meant to help with
ytdl_hook.lua and to improve loading speeds.

In theory, all this stuff is available to any mpv user, but discourage
using it, as it's so specialized towards ytdl_hook.lua, that there's
danger we'll just break this once ytdl_hook.lua stops using it, or
similar.

Mostly untested.
2020-02-15 18:29:44 +01:00
wm4 1d53a8f2e7 demux_edl: warn if no_clip is used with multiple parts
Well whatever.
2020-02-15 15:25:12 +01:00