summaryrefslogtreecommitdiffstats
path: root/stream
Commit message (Collapse)AuthorAgeFilesLines
* stream_libarchive: fix unnecessarily opening all volumes on openingwm42020-01-091-9/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Seems like I'm still not done with rar playback stuff... It turns out the reason for archive_read_open1() opening all volumes had nothing to do with libarchive's rar code, but was a consequence of how multi volume support is implemented in libarchive, and due to the fact that we enabled archive_read_support_format_zip_seekable() (through archive_read_support_format_zip()). The seekable zip format will seek to the end of the file and search for a zip "header" there. It could possibly be considered a libarchive bug that it does that even if it's fairly sure that it's a RAR file. We already do probing on a small buffer read from the start of the file (i.e. not giving libarchive a way to seek the stream before we think it's an archive), but that does not help, since libarchive needs to probe _again_. libarchive does not seem to provide a function to query the format (no archive_read_get_format()). Which seems quite strange, but at least I didn't find one. This commit works this around by doing some manual rar/zip probing. We could have gone only with rar probing. But detecting zip separately allows us to avoid that stream_libarchive seeks to the end during early probing. This is an additional bonus on top of "fixing" multi volume rar. The zip probing is from archive_read_format_zip_streamable_bid(). The rar signature is the common prefix of the rar and rar5 formats in libarchive (presumably the RAR fixed header parts without version). If the demuxer seeks to the end of the rar entry, this will still open all volumes; I'm not sure whether the old/removed rar code in mpv could handle this better. See: #7182
* stream_libarchive: enable anger managementwm42020-01-071-6/+7
| | | | | | | | Well that was too much misery when trying to deal with an idiotic feature, so it had to be compensated for. Replace insults with proper explanation, libarchive sort of isn't guilty in the first place, and their format support is pretty good all things considered.
* stream_libarchive: remove "old" rar volume patternwm42020-01-041-8/+0
| | | | | | | This turned every "normal" .rar filename into a multi-volume one accidentally. Since the detection is purely by filename (due to lack of support by libarchive I guess), it causes the nasty message added in the previous commit to appear for every .rar file. Just drop it.
* stream_libarchive: add annoying message regarding multi-volume archiveswm42020-01-041-2/+13
| | | | I'm done.
* libarchive: some shitty hack to make opening slightly fasterwm42020-01-042-4/+7
| | | | | | | | See manpage additions. The libarchive behavior mentioned in the last paragraph there is technically unrelated, but makes this new option mostly pointless. See: #7182
* stream_libarchive: log each opened volumewm42020-01-041-0/+1
| | | | To annoy the user.
* stream_libarchive: remove unnecessary string list of volumeswm42020-01-041-34/+25
| | | | Just add the entries as volumes directly.
* stream_libarchive: some more hacks to improve multi-volume archiveswm42020-01-042-31/+37
| | | | | | | | | | Instead of opening every volume on start just to see if it's there, all all volumes that could possibly exist, and "handle" it on opening. This requires working around some of libarchive's amazing stupidity and using some empirically determined behavior. Will possibly break if libarchive changes some of this behavior. See: #7182
* stream_libarchive: enable rar5 supportwm42020-01-041-0/+1
| | | | | | | | | | We whitelist formats (and not all of them). RAR v5 is a separated format entry for inexplicable reasons. (It's a separate implementation, but who really wants to support only either of the rar formats?) I'm not sure if it was libarchive 3.3.3. Their git history is absolutely chaotic. These people do not know how to use git. I couldn't be bothered to dig deeper.
* stream_dvb: Remove implicit fallthroughs and consistify debug messages.Oliver Freyermuth2019-12-281-4/+12
| | | | | | The code is more explicit now and less confusing, and debug messages for the channel parsing for the several delivery systems are now more similar.
* stream_concat, stream_memory: more stream_origin stuffwm42019-12-232-0/+19
| | | | | | Make concat streams use the "worst" origin of its parts, which may or may not be what makes sense. stream_memory has no natural way to do this, so just add a vague comment.
* stream, demux: redo origin policy thingwm42019-12-2014-37/+87
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* libarchive: prefix entry names in archive URLs with '/'wm42019-12-201-1/+3
| | | | | | | This has the advantage that playlists within the archive will work as expected, because demux_playlist will correctly join the archive base URL and entry name. Before this change, it could skip before the "|", resulting in a broken URL.
* build: add -Wimplicit-fallthroughwm42019-12-111-0/+1
| | | | | | | | | | This warning seems to be designed well. It doesn't seem to warn on fallthrough-only case statements, so it's compatible to well written code. stream_dvdnav.c had an obscure bug in inactive code, fix it. stream_dvb.c is the only place where it intentionally falls through, I guess I'll just leave it alone.
* command: shuffle some crap aroundwm42019-11-251-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | This is preparation to get rid of the option-to-property bridge (mp_on_set_option). This is a pretty insane thing that redirects accesses to options to properties. It was needed in the ever ongoing transition from something to... something else. A good example for the need of this bridge is applying profiles at runtime. This obviously goes through the config parser, but should also make all changes effective, for which traditionally the property layer is used. There isn't much left that needs this bridge. This commit changes a bunch of options (which also have a property implementation) to use option change notifications instead. Many of the properties are still left, but perform unrelated functions like OSD formatting. This should be mostly compatible. There may be some subtle behavior changes. For example, "hwdec" and "record-file" do not check for changes anymore before applying them, so writing the current value to them suddenly does something, while it was ignored before. DVB changes untested, but should work.
* stream_lavf: set --network-timeout to 60 seconds by defaultwm42019-11-142-6/+13
| | | | | | | | | | | 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
* demux_mkv, stream: attempt to improve behavior in unseekable streamswm42019-11-143-10/+10
| | | | | | | | | | | | | | | | | 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.
* stats, demux: log byte level stream seekswm42019-11-072-0/+4
|
* stream: remove unused read_chunk fieldwm42019-11-077-10/+0
| | | | | | | | | | | | | 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.
* stream: replace STREAM_CTRL_GET_SIZE with a proper entrypointwm42019-11-0710-87/+42
| | | | | This is overlay convoluted as a stream control, and important enough to warrant "first class" functionality.
* stream_dvdnav: ok, this makes no sense at allwm42019-11-071-1/+4
| | | | | | | | | | | | | | | | | The dvdnav API reads in 2K blocks (dvdnav_get_next_block()). The mpv wrapper (fill_buffer() in this file) expects that the read size done by the mpv core is at least 2K for this reason. If not, it returns an error. This used to be OK, because there was a thing called section alignment in the core code. This was removed because the core shouldn't suffer from optical disc idiosyncrasies. Which means that ever since, it has been working only by coincidence, or maybe not at all. Fixing this would require keeping a buffer in the priv struct, and returning it piece by piece if the core makes smaller reads. I have no intention of writing such code, so add an error message asking for a patch. If anyone actually cares about DVD, maybe it'll get fixed.
* stream_bluray: remove size getterwm42019-11-071-3/+0
| | | | | | This isn't really needed, since it doesn't support byte seeking (only for avoiding that demux_disc fucks up even more if the nested demux_lavf tries to seek in the TS).
* stream: change buffer argument types from char* to void*wm42019-11-0713-27/+27
| | | | | | | 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.
* stream: avoid a duplicate conditionwm42019-11-071-6/+3
| | | | | | stream_read_peek() duplicated what stream_read_more() checks for anyway (whether the forward buffer is large enough). This can be skipped by making the stream_read_more() return value more consistent.
* stream: fix typos in a commentswm42019-11-072-4/+4
|
* stream: remove eof getterwm42019-11-071-5/+0
| | | | | | | 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.)
* stream: bump default buffer size from 2K to 64Kwm42019-11-061-1/+1
| | | | | | | | | (Only half of the buffer is actually used in a useful way, see manpage or commit which added the option.) Might have some advantages with broken network filesystem drivers. See: #6802
* stream: remove inline buffer optimizationwm42019-11-062-18/+9
| | | | | | | | | | 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...
* stream: turn into a ring buffer, make size configurablewm42019-11-062-151/+259
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Replace uses of FFMIN/MAX with MPMIN/MAXwm42019-10-311-3/+2
| | | | And remove libavutil includes where possible.
* stream_memory: remove trivial ffmpeg dependencywm42019-10-311-3/+1
|
* stream: move stream_read_line to demux_playlist.cwm42019-10-312-71/+0
| | | | | 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.
* stream: stop accessing buffer internals in stream_read_line()wm42019-10-312-8/+16
| | | | | Getting this out of the way in preparation for reworking stream internals.
* demux: restore some of the DVD/BD/CDDA interaction layerswm42019-10-034-8/+367
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This partially reverts commit a9d83eac40c94f44d19fab7b6955331f10efe301 ("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.
* stream_dvb: Remove now replaced stream-control code for good.Oliver Freyermuth2019-10-022-85/+0
|
* stream_dvb: Allow actual zapping of channels again.Oliver Freyermuth2019-10-022-0/+8
| | | | | | | | | | | | | | | This is realized by dvbin-channel-switch-offset, which is a numeric offset on the channel initially tuned to. Since the channel list is kept in the stream alone depending on detected hardware and chosen card, and no available backchannel to the player, there's no direct property which could be switched. Using input.conf like: H cycle dvbin-channel-switch-offset up K cycle dvbin-channel-switch-offset down Q set dvbin-prog "ZDF HD" allow fast and reliable channel switching again.
* stream_dvb: Add dvb_update_config to poll config parameters.Oliver Freyermuth2019-10-022-0/+33
| | | | | | | | If any parameters have been updated, reinitiate streaming_start. Throttle checks since we poll from streaming_read. This also requires the player to re-initialize, since all video and audio streams and even the transport format may change. This is added in the next commit.
* stream_dvb: Move stream->is_on initialization to state preparation.Oliver Freyermuth2019-10-022-2/+1
| | | | | | Notably, this allows to call dvb_streaming_start more than once, simplifying e.g. channel switching. Also, get rid of unused timeout variable.
* stream_dvb: Factor out logic to determine program and card.Oliver Freyermuth2019-10-022-47/+75
| | | | | | | | This is now treated in dvb_parse_path consistently instead of logic scattered over various functions. This is a requirement to sensibly re-evaluate config after options have been changed, since we have two ways to configure the stream (decorated URI and config parameters).
* stream_dvb: Use separated out options struct.Oliver Freyermuth2019-10-022-27/+33
| | | | | This also allows the use of m_config_cache_alloc which allows to watch config updates.
* stream_lavf: add support for gopherLeonardo Taccari2019-09-291-1/+1
|
* stream: rearrange open functionswm42019-09-294-56/+96
| | | | | | | | | | | | | | | | 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.)
* stream_cb: add cancel_fn callbackAman Gupta2019-09-271-0/+8
| | | | | | | | This allows stream_cb backends to implement blocking behavior inside read_fn, and still get notified when the user wants to cancel and stop playback. Signed-off-by: Aman Gupta <aman@tmm1.net>
* stream_dvb: remove unused variablewm42019-09-211-1/+0
| | | | | | (At first I left this intentionally, because the temporarily disabled stream ctrl code used it, but there's actually no reason to annoy everyone with the warning.)
* stream_libarchive: Always use LC_CTYPE_MASK for libarchiveJames Hilliard2019-09-211-1/+1
| | | | | | Using LC_ALL_MASK is unnecessary and unreliable on some systems. Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
* stream: add a generic concat implementationwm42019-09-192-0/+164
| | | | | | 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.
* stream: create memory streams in more straightforward waywm42019-09-193-40/+57
| | | | | | | | | | | | | | | 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.
* stream: log positions on seek failureswm42019-09-191-1/+2
|
* stream: redo buffer handling and allow arbitrary size for stream_peek()wm42019-09-192-48/+95
| | | | | | | | | | | | | | | | 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.
* stream_libarchive: remove base filename stuffwm42019-09-192-6/+0
| | | | | | | | 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.
* stream_libarchive: fix another crash with broken rar fileswm42019-09-191-1/+3
| | | | | |