summaryrefslogtreecommitdiffstats
path: root/stream/stream.c
Commit message (Collapse)AuthorAgeFilesLines
* stream: increase max_size to INT_MAX minus paddingKacper Michajłow2024-01-311-1/+1
| | | | | No need to magic number limit, we can support up to INT_MAX with current code. Which should be more than enough.
* stream: remove unneeded mp_read_option_raw callDudemanguy2023-09-221-3/+4
| | | | We can get the group from demux_conf instead and use that.
* options: transition options from OPT_FLAG to OPT_BOOLChristoph Heinrich2023-02-211-4/+4
| | | | | | c78482045444c488bb7948305d583a55d17cd236 introduced a bool option type as a replacement for the flag type, but didn't actually transition and remove the flag type because it would have been too much mundane work.
* stream: remove trailing NULL element from stream listThomas Weißschuh2023-01-171-4/+3
|
* manpage: document improved --playlist securityLeo Izen2020-11-181-2/+1
| | | | | | | Recent versions of mpv have applied security checks to --playlist that previously only existed if playlist files were played as an input directly. This commit documents this change and how to work around it, in the event that playlist files are trusted.
* stream: Implement slice:// for reading slices of streamsMohammad AlSaleh2020-08-191-0/+2
| | | | | | | | | | | | | | | | Add support for reading a byte range from a stream via the `slice://` protocol. Syntax is `slice://start[-end]@URL` where end is a maximum (read until end or eof). Size suffixes support in `m_option` is reused so they can be used with start/end. This can be very useful with e.g. large MPEGTS streams with corruption or time-stamp jumps or other issues in them. Signed-off-by: Mohammad AlSaleh <CE.Mohammad.AlSaleh@gmail.com>
* demux_lavf: workaround reading gif from unseekable streamswm42020-07-091-1/+9
| | | | | | | FFmpeg, being the pile of trash as usual, recently broke this. Add our own trash hack to trashily workaround this shit. Fixes: #7893
* stream: make stream_read_file() more robustwm42020-05-101-11/+19
| | | | | | | | | 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.
* stream: actually drop unneeded bufferwm42020-04-101-16/+21
| | | | | | | | | | | | | | | | | | The buffer can be larger than the normal size when "peeking" is used (such as done with some file formats, where a large number of bytes masy need to be "peeked" at the beginning, because FFmpeg). Once normal operation resumes, it's supposed to free this buffer again. Apparently this didn't happen as intended, because normal reading did have no way to discard back buffer before/while resizing the buffer. There's only a path for discarding the back buffer when actually reading. It seems like this unfortunately needs 2 code paths for discarding old data. Just put it into stream_resize_buffer(), where it's rather non-tricky (discarding can be done by adjusting the copy offset when moving data to the new allocation). The function now drops old data if it doesn't fit into the allocation. The caller must ensure that the new size is sufficient; the function signature changes only so the size of the implicitly guaranteed kept part can be checked with assert().
* stream: add assert, a cosmetic changewm42020-04-101-1/+3
| | | | This shouldn't change anything.
* stream: minor adjustment to buffer size limit logicwm42020-04-101-6/+6
| | | | | Instead of having 2 inconsistent limits on the upper possible buffer size (option limit and allocation code), use a shared constant for them.
* options: change option macros and all option declarationswm42020-03-181-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* stream_file: mark fd protocols as "unsafe"wm42020-03-081-0/+2
| | | | | Whatever good or bad that might do. In any case, they can easily trigger UB-like behavior.
* stream_smb: remove thiswm42020-03-051-4/+0
| | | | | | | | | | | This required libsmbclient, which is a heavy dependency, and as a library, has all kinds of problems. For one, the API requires completely unacceptable global state (in particular, leaks auth state), and is not thread-safe (meaning concurrent reads to multiple files block each other). There are better replacements: you can use the Linux kernel's builtin CIFS support, fusesmb, or contribute supoport for libdsm.
* stream: early-out in stream_seek_skip() if nothing is skippedwm42020-02-141-2/+7
| | | | | | | stream_seek() might somewhat show up in the profiler, even if it's a no-OP, because of the MP_TRACE() call. I find this annoying. Otherwise, this should be of no consequence, and should not break or improve anything.
* stream, demux: redo origin policy thingwm42019-12-201-18/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* demux_mkv, stream: attempt to improve behavior in unseekable streamswm42019-11-141-7/+7
| | | | | | | | | | | | | | | | | 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-071-0/+2
|
* stream: remove unused read_chunk fieldwm42019-11-071-3/+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-071-4/+1
| | | | | This is overlay convoluted as a stream control, and important enough to warrant "first class" functionality.
* stream: change buffer argument types from char* to void*wm42019-11-071-6/+6
| | | | | | | 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-071-1/+1
|
* 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-061-14/+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-061-142/+222
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: move stream_read_line to demux_playlist.cwm42019-10-311-69/+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-311-8/+15
| | | | | Getting this out of the way in preparation for reworking stream internals.
* stream: rearrange open functionswm42019-09-291-42/+59
| | | | | | | | | | | | | | | | 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: create memory streams in more straightforward waywm42019-09-191-26/+27
| | | | | | | | | | | | | | | 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-191-42/+91
| | | | | | | | | | | | | | | | 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: stop randomly corrupting memorywm42019-09-181-1/+2
| | | | | | | | | | | | | | | | | | | | The intent of the line above the modified one code was raising the amount of read data, so that many stream_peek() calls with small len values would not degrade performance by effectively turning every stream_peak() into an unbuffered read call to the stream implementation. So this confusing looking MPMAX() was correct, but "chunk" could still get beyond the buffer. So just fix that and limit "chunk" correctly. I'm not sure whether the commit referenced below accidentally removed some intricate guarantee that this couldn't happen, since the code was around since 2013. It could have relied on TOTAL_BUFFER_SIZE > STREAM_BUFFER_SIZE. But not sure. I've rewritten all this code in my own branch a year ago, so who knows. Fixes: 162e0f5ad92116d Fixes: #6948
* stream: handle short writeswm42019-09-141-7/+10
| | | | | | | | The write functionality is almost unused (only encoding 2-pass mode uses it to write the log file). Moreover, it almost makes no sense to use this in a not local scenario. This change is just to prevent people from duplicating the short write logic across all streams that happen to support writing. Mostly untested; local log file writing still works.
* demux, stream: remove old rar support in favor of libarchivewm42019-09-131-3/+0
| | | | | | 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.
* Remove classic Linux analog TV support, and DVB runtime controlswm42019-09-131-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | 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.
* stream: remove BD/DVD/CDDA sector size alignmentwm42019-09-131-11/+4
| | | | | | 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.
* Remove libdvdread support in favor of libdvdnavwm42019-09-131-6/+0
| | | | | | | | | | | stream_dvd.c contained large amounts of ancient, unmaintained code, which has been historically moved to libdvdnav. Basically, it's full of low level parsing of DVD on-disc structures. Kill it for good. Users can use the remaining dvdnav support (which basically operates in non-menu mode). Users have reported that libdvdread sometimes works better, but this is just libdvdnav's problem and not ours.
* stream: silence failed seek message on terminationwm42018-12-061-1/+2
| | | | | | Seems to happen often with ytdl pseudo-DASH streams, so whatever. I couldn't reproduce it and check what triggers it, I just remember seeing the error message and found it annoying.
* stream: somethingwm42018-12-061-3/+4
|
* demux, stream: readd cache-speed in some other formwm42018-12-061-0/+1
| | | | it's more like an input speed rather than a cache speed, but who cares.
* demux, stream: rip out the classic stream cachewm42018-08-311-97/+0
| | | | | | 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.
* misc: move mp_cancel from stream.c to thread_tools.cwm42018-05-241-135/+1
| | | | | | | | | | | | 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.
* demux, stream: ignore packets and errors on forced exitwm42018-03-261-1/+2
| | | | | | | | | | When this happens, network calls are forcibly aborted (more or less), but demuxers might keep going, as most of them do not check for forced exits properly. This can possibly lead to broken packets being added. Also do not attempt to read more packets in this situation. Also do not print a stream open failed message if opening was aborted anyway.
* stream: use native libavformat reconnection featurewm42018-01-041-35/+0
| | | | | | | | | | | | | | | | | | 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@8a108bdea06fac43af9f44b6d2538f357451167a 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.)
* stream_lavf: minor fixes to HTTP reconnection supportwm42018-01-021-2/+1
| | | | | | | | | | | | | Don't drop the stream buffers, because the read call (that must have been failing) might try to extend an existing read buffer in the first place. Just move the messy seek logic to stream_lavf.c. (In theory, stream_lavf should probably make libavformat connect at the correct offset instead of using a seek to reconnect it again. This patch doesn't fix it, but at least it's a good argument to have the messing with the position not in the generic code.) Also update the comment about avio not supporting reconnecting. It has that feature now. Maybe we should use it, but only after it gets fixed.
* msg: reinterpret a bunch of message levelsNiklas Haas2017-12-151-2/+2
| | | | | | | | | | | | | | | | | | | | | | I've decided that MP_TRACE means “noisy spam per frame”, whereas MP_DBG just means “more verbose debugging messages than MSGL_V”. Basically, MSGL_DBG shouldn't create spam per frame like it currently does, and MSGL_V should make sense to the end-user and provide mostly additional informational output. MP_DBG is basically what I want to make the new default for --log-file, so the cut-off point for MP_DBG is if we probably want to know if for debugging purposes but the user most likely doesn't care about on the terminal. Also, the debug callbacks for libass and ffmpeg got bumped in their verbosity levels slightly, because being external components they're a bit less relevant to mpv debugging, and a bit too over-eager in what they consider to be relevant information. I exclusively used the "try it on my machine and remove messages from MSGL_* until it does what I want it to" approach of refactoring, so YMMV.
* stream: add an assert() to an obscure seek casewm42017-08-171-0/+1
| | | | | | | | This affects small seeks backwards while within the buffer. Demuxers usually avoid this, so it's probably not triggered very often. (Although demux_mkv.c potentially triggers it often, and it uses stream_peek() to explicitly guarantee that it can use this code to seek back.) The condition is complex enough to warrant an assertion.
* Avoid calling close(-1)wm42017-06-291-2/+4
| | | | | | | | | | While this is perfectly OK on Unix, it causes annoying valgrind warnings, and might be otherwise confusing to others. On Windows, the runtime can actually abort the process if this is called. push.c part taken from a patch by Pedro Pombeiro.
* <