Commit Graph

250 Commits

Author SHA1 Message Date
sfan5 5117fa70af stream: turn stream_info.open2's args argument const
So nobody comes up with the "smart" idea to modify those again.
2021-04-08 23:47:35 +03: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 ad9f3bfe96 stream: make stream_read_file() more robust
Change it to strictly accept local paths only. No more http://, no more
$HOME expansion with "~/" or mpv config path expansion with "~~/". This
should behave as if passing a path directly to open().

Reduce annoying log noise to further facilitate it using as open()
replacement.
2020-05-10 16:44:35 +02:00
wm4 217c47ecb2 stream: fix whitespace within comment
arrrrrrrghh
2020-04-10 10:50:54 +02:00
wm4 1cb9e7efb8 stream, demux: redo origin policy thing
mpv has a very weak and very annoying policy that determines whether a
playlist should be used or not. For example, if you play a remote
playlist, you usually don't want it to be able to read local filesystem
entries. (Although for a media player the impact is small I guess.)

It's weak and annoying as in that it does not prevent certain cases
which could be interpreted as bad in some cases, such as allowing
playlists on the local filesystem to reference remote URLs. It probably
barely makes sense, but we just want to exclude some other "definitely
not a good idea" things, all while playlists generally just work, so
whatever.

The policy is:
- from the command line anything is played
- local playlists can reference anything except "unsafe" streams
  ("unsafe" means special stream inputs like libavfilter graphs)
- remote playlists can reference only remote URLs
- things like "memory://" and archives are "transparent" to this

This commit does... something. It replaces the weird stream flags with a
slightly clearer "origin" value, which is now consequently passed down
and used everywhere. It fixes some deviations from the described policy.

I wanted to force archives to reference only content within them, but
this would probably have been more complicated (or required different
abstractions), and I'm too lazy to figure it out, so archives are now
"transparent" (playlists within archives behave the same outside).

There may be a lot of bugs in this.

This is unfortunately a very noisy commit because:
- every stream open call now needs to pass the origin
- so does every demuxer open call (=> params param. gets mandatory)
- most stream were changed to provide the "origin" value
- the origin value needed to be passed along in a lot of places
- I was too lazy to split the commit

Fixes: #7274
2019-12-20 13:00:39 +01:00
wm4 5a99015acf stream_lavf: set --network-timeout to 60 seconds by default
Until now, we've made FFmpeg use the default network timeout - which is
apparently infinite. I don't know if this was changed at some point,
although it seems likely, as I was sure there was a more useful default.

For most use cases, a smaller timeout is more useful (for example
recording something in the background), so force a timeout of 1 minute.

See: #5793
2019-11-14 13:46:03 +01:00
wm4 ac7f67b3f2 demux_mkv, stream: attempt to improve behavior in unseekable streams
stream_skip() semantics were kind of bad, especially after the recent
change to the stream code. Forward stream_skip() calls could still
trigger a seek and fail, even if it was supposed to actually skip data.
(Maybe the idea that stream_skip() should try to seek is worthless in
the first place.)

Rename it to stream_seek_skip() (takes absolute position now because I
think that's better), and make it always skip if the stream is marked as
forward.

While we're at it, make EOF detection more robust. I guess s->eof
shouldn't exist at all, since it's valid only "sometimes". It should be
removed... but not today. A 1-byte stream_read_peek() call is good to
get the s->eof flag set to a correct value.
2019-11-14 12:59:14 +01:00
wm4 19becc8ea9 stats, demux: log byte level stream seeks 2019-11-07 22:53:13 +01:00
wm4 6487abde79 stream: remove unused read_chunk field
It was set, but its value was never used. The stream cache used to use
it, but it was removed. It controlled how much data it tried to read
from the underlying stream at once.

The user can now control the buffer size with --stream-buffer-size,
which achieves a similar effect, because the stream will in the common
case read half of the buffer size at once. In fact, the new default size
is 128KB, i.e. 64KB read size, which is as much as stream_file and
stream_cb requested by default. stream_memory requested more, but it
doesn't matter anyway. Only stream_smb set a larger size with 128KB.
2019-11-07 22:53:13 +01:00
wm4 e5a9b792ec stream: replace STREAM_CTRL_GET_SIZE with a proper entrypoint
This is overlay convoluted as a stream control, and important enough to
warrant "first class" functionality.
2019-11-07 22:53:13 +01:00
wm4 d3479018db stream: change buffer argument types from char* to void*
This is slightly better, although not much, and ultimately doesn't
matter.

The public API in stream_cb.h also uses char*, but can't change that.
2019-11-07 22:53:13 +01:00
wm4 53f17a71f4 stream: fix typos in a comments 2019-11-07 22:53:13 +01:00
wm4 12d1761064 stream: remove eof getter
demux_mkv was the only thing using this, and everything else accessed it
directly. No need to keep the indirection wrapper around.

(Funny how this getter was in the initial commit of MPlayer.)
2019-11-07 22:53:10 +01:00
wm4 b4466cf0d4 stream: remove inline buffer optimization
Was probably worthless, and I can't measure a difference anymore (I used
to be able and it still seemed worth doing so back then).

When the default buffer size is enlarged in the next commit, the inline
buffer probably won't even be useful in theory, because the data will
rarely be on the same page as the other stream fields. It surely makes
the inline buffer seem like a ridiculous micro-optimization. Farewell...
2019-11-06 21:54:41 +01:00
wm4 f37f4de849 stream: turn into a ring buffer, make size configurable
In some corner cases (see #6802), it can be beneficial to use a larger
stream buffer size. Use this as argument to rewrite everything for no
reason.

Turn stream.c itself into a ring buffer, with configurable size. The
latter would have been easily achievable with minimal changes, and the
ring buffer is the hard part. There is no reason to have a ring buffer
at all, except possibly if ffmpeg don't fix their awful mp4 demuxer, and
some subtle issues with demux_mkv.c wanting to seek back by small
offsets (the latter was handled with small stream_peek() calls, which
are unneeded now).

In addition, this turns small forward seeks into reads (where data is
simply skipped). Before this commit, only stream_skip() did this (which
also mean that stream_skip() simply calls stream_seek() now).

Replace all stream_peek() calls with something else (usually
stream_read_peek()). The function was a problem, because it returned a
pointer to the internal buffer, which is now a ring buffer with
wrapping. The new function just copies the data into a buffer, and in
some cases requires callers to dynamically allocate memory. (The most
common case, demux_lavf.c, required a separate buffer allocation anyway
due to FFmpeg "idiosyncrasies".) This is the bulk of the demuxer_*
changes.

I'm not happy with this. There still isn't a good reason why there
should be a ring buffer, that is complex, and most of the time just
wastes half of the available memory. Maybe another rewrite soon.

It also contains bugs; you're an alpha tester now.
2019-11-06 21:36:02 +01:00
wm4 a267452b00 stream: move stream_read_line to demux_playlist.c
demux_playlist.c is the only remaining user of this. Not sure if it
should stay this way, but for now I'll say yes.
2019-10-31 11:05:48 +01:00
wm4 c6b08d222f stream: stop accessing buffer internals in stream_read_line()
Getting this out of the way in preparation for reworking stream
internals.
2019-10-31 11:05:45 +01:00
wm4 1c63869d0a demux: restore some of the DVD/BD/CDDA interaction layers
This partially reverts commit a9d83eac40
("Remove optical disc fancification layers").

Mostly due to the timestamp crap, this was never really going to work.
The playback layer is sensitive to timestamps, and derives the playback
time directly from the low level packet timestamps. DVD/BD works
differently, and libdvdnav/libbluray do not make it easy at all to
compensate for this. Which is why it never worked well, but not doing it
at all is even more awful.

demux_disc.c tried this and rewrote packet timestamps from low level TS
to playback time. So restore demux_disc.c, which should bring behavior
back to the old often non-working but slightly better state.

I did not revert anything that affects components above the demuxer
layer. For example, the properties for switching DVD angles or listing
disc titles are still gone. (Disc titles could be reimplemented as
editions. But not by me.)

This commit modifies the reverted code a bit; this can't be avoided,
because the internal API changed quite a bit. The old seek resync in
demux_lavf.c (which was a hack) is replaced with a hack. SEEK_FORCE and
demux_params.external_stream are new additions.

Some of this could/should be further cleaned up. If you don't want
"proper" DVD/BD support to disappear, you should probably volunteer.

Now why am I wasting my time for this? Just because some idiot users are
too lazy to rip their ever-wearing out shitty physical discs? Then why
should I not be lazy and drop support completely? They won't even be
thankful for me maintaining this horrible garbage for no compensation.
2019-10-03 00:22:18 +02:00
wm4 2bb5ab07b7 stream: rearrange open functions
Add yet another variant of the stream open function. This time, make it
so that it's possible to add new open parameters in an extendable way,
which should put an end to having to change this every other year.

Effectively get rid of the overly special stream_create_instance()
function and use the new one instead, which requires changes in
stream_concat.c and stream_memory.c. The function is still in private in
stream.c, but I preferred to make the mentioned users go through the new
function for orthogonality. The error handling (mostly logging) was
adjusted accordingly.

This should not have any functional changes. (To preempt any excuses, I
didn't actually test stream_concat and stream_memory.)
2019-09-29 00:46:54 +02:00
wm4 43fc314279 stream: add a generic concat implementation
This is not available to users. It can be used only though the
stream_concat_open(). It's unused yet; to be used in the following
commit.
2019-09-19 20:37:05 +02:00
wm4 e40885d963 stream: create memory streams in more straightforward way
Instead of having to rely on the protocol matching, make a function that
creates a stream from a stream_info_t directly. Instead of going through
a weird indirection with STREAM_CTRL, add a direct argument for non-text
arguments to the open callback. Instead of creating a weird dummy
mpv_global, just pass an existing one from all callers. (The latter one
is just an artifact from the past, where mpv_global wasn't available
everywhere.)

Actually I just wanted a function that creates a stream without any of
that bullshit. This goal was slightly missed, since you still need this
heavy "constructor" just to setup a shitty struct with some shitty
callbacks.
2019-09-19 20:37:05 +02:00
wm4 c91e659f88 stream: redo buffer handling and allow arbitrary size for stream_peek()
struct stream used to include the stream buffer, including peek buffer,
inline in the struct. It could not be resized, which means the maximum
peek size was set in stone. This meant demux_lavf.c could peek only so
much data.

Change it to use a dynamic buffer. Because it's possible, keep the
inline buffer for default buffer sizes (which are basically always used
outside of file opening). It's unknown whether it really helps with
anything. Probably not.

This is also the fallback plan in case we need something like the old
stream cache in order to deal with mp4 + unseekable http: the code can
now be easily changed to use any buffer size.
2019-09-19 20:37:04 +02:00
wm4 f77515ebaf stream_libarchive: remove base filename stuff
Apparently this was so that when playing a video file from a .rar file,
it would load external subtitles with the same name (instead of looking
for mpv's rar:// mangled URL). This was requested on github almost 5
years ago. Seems like a weird feature, and I don't care. Drop it,
because it complicates some in progress change.
2019-09-19 20:37:04 +02:00
wm4 a25b3d61a1 demux, stream: remove old rar support in favor of libarchive
The old rar code could do uncompressed rar, libarchive supports at least
some rar compression algorithms. There is no need to keep the old rar
code.
2019-09-13 17:35:06 +02:00
wm4 ddcbe66768 stream: remove some more optical disc leftovers 2019-09-13 17:32:21 +02:00
wm4 b30e85508a Remove classic Linux analog TV support, and DVB runtime controls
Linux analog TV support (via tv://) was excessively complex, and
whenever I attempted to use it (cameras or loopback devices), it didn't
work well, or would have required some major work to update it. It's
very much stuck in the analog past (my favorite are the frequency tables
in frequencies.c for analog TV channels which don't exist anymore).

Especially cameras and such work fine with libavdevice and better than
tv://, for example:

  mpv av://v4l2:/dev/video0

(adding --profile=low-latency --untimed even makes it mostly realtime)

Adding a new input layer that targets such "modern" uses would be
acceptable, if anyone is interested in it. The old TV code is just too
focused on actual analog TV.

DVB is rather obscure, but has an active maintainer, so don't remove it.
However, the demux/stream ctrl layer must go, so remove controls for
channel switching. Most of these could be reimplemented by using the
normal method for option runtime changes.
2019-09-13 17:32:19 +02:00
wm4 162e0f5ad9 stream: remove BD/DVD/CDDA sector size alignment
This was possibly needed by libdvdread, and/or old CD drivers on some
system. It still works with on-filesystem DVD and BD test images, so
this can go.
2019-09-13 17:32:05 +02:00
wm4 a9d83eac40 Remove optical disc fancification layers
This removes anything related to DVD/BD/CD that negatively affected the
core code. It includes trying to rewrite timestamps (since DVDs and
Blurays do not set packet stream timestamps to playback time, and can
even have resets mid-stream), export of chapters, stream languages,
export of title/track lists, and all that.

Only basic seeking is supported. It is very much possible that seeking
completely fails on some discs (on some parts of the timeline), because
timestamp rewriting was removed.

Note that I don't give a shit about optical media. If you want to watch
them, rip them. Keeping some bare support for DVD/BD is the most I'm
going to do to appease the type of lazy, obnoxious users who will care.
There are other players which are better at optical discs.
2019-09-13 17:31:59 +02:00
wm4 4dfaa37384 demux, stream: readd cache-speed in some other form
it's more like an input speed rather than a cache speed, but who cares.
2018-12-06 10:30:41 +01:00
wm4 559a400ac3 demux, stream: rip out the classic stream cache
The demuxer cache is the only cache now. Might need another change to
combat seeking failures in mp4 etc. The only bad thing is the loss of
cache-speed, which was sort of nice to have.
2018-08-31 12:55:22 +02:00
wm4 d7ca95c3ea command: whitelist some blocking accesses for certain demuxers/streams
The properties/commands touched in this commit are all for obscure
special inputs (BD/DVD/DVB/TV), and they all block on the demuxer/stream
layer. For network streams, this blocking is very unwelcome. They will
affect playback and probably introduce pauses and frame drops. The
player can even freeze fully, and the logic that tries to make playback
abortable even if frozen complicates the player.

Since the mentioned accesses are not needed for network streams, but
they will block on network streams even though they're going to fail,
add a flag that coarsely enables/disables these accesses. Essentially it
establishes a whitelist of demuxers/streams which support them.

In theory you could to access BD/DVD images over network (or add such
support, I don't think it's a thing in mpv). In these cases these
controls still can block and could even "freeze" the player completely.

Writing to the "program" and "cache-size" properties still can block
even for network streams. Just don't use them if you don't want freezes.
2018-05-24 19:56:35 +02:00
wm4 31b78ad7fa misc: move mp_cancel from stream.c to thread_tools.c
It seems a bit inappropriate to have dumped this into stream.c, even if
it's roughly speaking its main user. At least it made its way somewhat
unfortunately to other components not related to the stream or demuxer
layer at all.

I'm too greedy to give this weird helper its own file, so dump it into
thread_tools.c.

Probably a somewhat pointless change.
2018-05-24 19:56:35 +02:00
wm4 185e63a3e2 stream: use native libavformat reconnection feature
Remove our own hacky reconnection code, and use libavformat's feature for
that. It's disabled by default, and until recently it did not work too
well. This has been fixed in recent ffmpeg git master[1], so there's no reason
to keep our own code.

[1] FFmpeg/FFmpeg@8a108bdea0

We set "reconnect_delay_max" to 7, which limits the maximum time it
waits. Since libavformat doubles the wait time on each reconnect attempt
(starting with 1), and stops trying to reconnect once the wait time is
over the reconnect_delay_max value, this allows for 4 reconnection
attempts which should add to 11 seconds maximum wait time. The default
is 120, which seems too high for normal playback use.

(The user can still override these parameters with --stream-lavf-o.)
2018-01-04 18:33:18 -08:00
wm4 e0c50289d6 stream: change license to LGPL
All relevant authors have agreed.

There are two exceptions, patches by authors who could not be reached.
This commit tries to remove their copyright.

a0f08fbe: messes with the seeking code corner cases. The EOF flag logic
was changed at some point, and always had a flaky history (see e.g.
347cf972 50274ca3 70411f27 5999efb9 0d5e6084 ff08d0c3 2e2f77e3 de5566f0
9554a844, all which happened after that patch, MPlayer ones without that
patch). I claim that all of the copyright the patch might have added is
gone. Except the message in stream_seek(), which this commit removes.
The other code removed/changed in stream_seek() is probably not from
that patch, but it doesn't hurt to be sure, and also makes it more
readable. (It might change the behavior so that sometimes the eof flag
is set after a seek, but it doesn't matter here.)

2aa6acd9: it looks like the seek_forward() modified by this patch was
later moved to stream.c and renamed to stream_skip_read() in a790f2133.
(Looking closer at it, it was actually modified again a bunch of times,
fixing the logic.) I rewrote it in this commit. The code ended up rather
similar, which probably could lead to doubts whether this was done
properly, but I guess the reader of this will just have to believe me. I
knew what stream_skip_read() was supposed to do (which was reinforced
when I tried to replace it on the caller side), without reading the
pre-existing code in detail. I had to "relearn" the logic how buf_pos
and bug_len work - it was actually easy to see from stream_read_char()
how to skip the data, essentially by generalizing its logic from 1 byte
to N bytes. From the old code I only "used" the fact that it's obviously
a while(len>0) look, that has to call stream_fill_buffer repeatedly to
make progress. At first I actually didn't use stream_fill_buffer_by(),
but the variant without _by, but readded it when I checked why the old
code used it (see cd7ec016e7). This has to be good enough. In the end,
it's hard to argue that this could be implemented in a way not using
such a loop.

Other than this, I could add the usual remarks about how this code was
not modularized in the past, and how stream.c contained DVD code, and
how this was later modularized, moving the copyright to other files, and
so on. Also, if someone wrote a stream module, and was not asked about
LGPL relicensing, we don't consider the entry in stream_list[]
copyrightable.
2017-06-19 16:10:10 +02:00
wm4 fb9a32977d stream: get rid of streamtype enum
Because it's kind of dumb. (But not sure if it was worth the trouble.)

For stream_file.c, we add new explicit fields. The rest are rather
special uses and can be killed by comparing the stream impl. name.

The changes to DVD/BD/CD/TV are entirely untested.
2017-02-02 18:26:58 +01:00
wm4 e13a62fc34 stream: better method signal caching, rename weird uncached_stream field
"uncached_stream" is a pretty bad name. It could be mistaken for a
boolean, and then its meaning would be inverted. Rename it.

Also add a "caching" field, which signals that the stream is a cache or
reads from a cache. This is easier to understand and more flexible.
2017-02-02 18:03:29 +01:00
wm4 73858bb0cc player: remove --stream-capture option/property
This was excessively useless, and I want my time back that was needed to
explain users why they don't want to use it.

It captured the byte stream only, and even for types of streams it was
designed for (like transport streams), it was rather questionable.

As part of the removal, un-inline demux_run_on_thread() (which has only
1 call-site now), and sort of reimplement --stream-dump to write the
data directly instead of using the removed capture code.

(--stream-dump is also very useless, and I struggled coming up with an
explanation for it in the manpage.)
2017-01-21 17:19:01 +01:00
wm4 ceb2e1026d demux, stream: add option to prevent opening referenced files
Quite irresponsibly hacked together. Sue me.
2016-12-04 23:15:31 +01:00
wm4 04320d26eb stream, demux, config: remove some dead/unneeded option-related code
This has all been made unnecessary recently. The change not to copy the
global option struct in particular can be made because now nothing
accesses the global options anymore in the demux and stream layers.

Some code that was accidentally added/changed in commit 5e30e7a0 is also
removed, because it was simply committed accidentally, and was never
used.
2016-09-09 17:54:57 +02:00
wm4 5e30e7a041 stream_dvd, stream_dvdnav: remove weird option parsing stuff
Same deal as with stream_bluray.

Untested because I don't give a fuck about your shitty DVDs.
2016-09-08 21:46:48 +02:00
wm4 d4d8b3a4fc demux: do not access global options
Don't access MPOpts directly, and always use the new m_config.h
functions for accessing them in a thread-safe way.

The goal is eventually removing the mpv_global.opts field, and the
demuxer/stream-layer specific hack that copies MPOpts to deal with
thread-safety issues.

This moves around a lot of options. For one, we often change the
physical storage location of options to make them more localized,
but these changes are not user-visible (or should not be). For
shared options on the other hand it's better to do messy direct
access, which is worrying as in that somehow renaming an option
or changing its type would break code reading them manually,
without causing a compilation error.
2016-09-06 20:09:56 +02:00
Aman Gupta 7ca4a453e0 client API: add stream_cb API for user-defined stream implementations
Based on #2630. Some heavy changes by committer.

Signed-off-by: wm4 <wm4@nowhere>
2016-08-07 19:33:20 +02:00
wm4 57506b27ed cache: use a single STREAM_CTRL for various cache info
Instead of having a separate for each, which also requires separate
additional caching in the demuxer. (The demuxer adds an indirection,
since STREAM_CTRLs are not thread-safe.)

Since this includes the cache speed, this should fix #3003.
2016-03-29 11:29:52 +02:00
wm4 5f1ff78516 command: add cache-speed property
Should reflect I/O speed.

This could go into the terminal status line. But I'm not sure how to put
it there, since it already uses too much space, so it's not there yet.
2016-03-20 19:51:22 +01:00
wm4 3a7563a999 cache: remove unused STREAM_CTRL_RESUME_CACHE
Went way with DVD/BD menu support.
2016-03-03 10:08:00 +01:00
wm4 6f35d4df5a cache: add mechanism for disabling readahead
Will be used in a following commit.
2016-01-18 18:40:12 +01:00
Oliver Freyermuth 62acd315ad player, stream_dvb: implement dvb-channel-name property.
On read, it returns the name of the current DVB program,
on write, it triggers a channel-switch to the program
if it is found in the channel list of the currently active card.
Compared to the dvb-channel property which already exists
and is a pair of integers (card + channel number) this has the limitation
of not switching the card, but is probably of much more common use.
2016-01-14 00:36:53 +01:00
wm4 cf2fa9d3e5 stream: provide a stream_get_size() convenience function
And use it everywhere, instead of retrieving the size manually. Slight
simplification.
2015-08-18 00:10:54 +02:00
wm4 525ada8c7a stream: remove remaining DVD/BD menu definitions 2015-08-03 23:49:14 +02:00
Niklas Haas 4d6b9550fe
vo_opengl: add support for custom shaders 2015-05-27 11:09:41 +02:00