summaryrefslogtreecommitdiffstats
path: root/stream/stream.c
Commit message (Collapse)AuthorAgeFilesLines
* 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.
* stream: change license to LGPLwm42017-06-191-21/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* stream: rewrite url escaping/unescaping functionswm42017-06-131-36/+48
| | | | | | | | | | | | | | | | | | | | | | | | | The original functions come from 24c6f11c8b8, which says that these functions were copied from another project. This other project is GPL and was written by an unknown author, so there is no hope to relicense them to LGPL. Replace the existing functions with code written by Avi Halachmi. He did not see the old code, but wrote it based on the function signature and an extended description of what they should do (http://sprunge.us/edia). Some additional help was provided by me (in particular the function of the "ok" parameter and how to implement it - not in the original ASFRecorder code). Some of the code is hilariously similar, but these are coincidences. The name of the variable "c" probably "leaked" from me, but "o" is a true coincidence. The code was integrated by me - my only change is changing the function names to the old ones, moving the order of the top-level declarations, and changing "default_ok" to "url_default_ok", and changing the strings from char* to char[]. The author of the new code is Avi Halachmi.
* wscript: decouple dvdnav check from dvdreadRicardo Constantino2017-03-311-1/+1
| | | | | | | | | Reallows enabling dvdnav without enabling dvdread which was broken in 77cbb3543 when they were both disabled by default. Since dvdnav requires dvdread, we can enable dvdread:// even if --enable-dvdread isn't passed. Fixes #4290
* stream: get rid of streamtype enumwm42017-02-021-3/+2
| | | | | | | | | 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.
* stream: better method signal caching, rename weird uncached_stream fieldwm42017-02-021-6/+7
| | | | | | | | "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.
* stream: minor cleanup to previous commitwm42017-01-271-12/+7
| | | | | | | This is almost cosmetic, but removes the duplicated EOF-setting. Somewhat oddly, this will enter the reconnect path and exit it immediately again - should be fine.
* stream: set EOF if stream is canceledwm42017-01-261-1/+3
| | | | | | | | | Commit 7be495b3 added the cancellation test, but forgot to set the eof flag. This could lead to demux_mkv.c not terminating if the stream was cancelled in some code paths. This function is what is supposed to set the EOF flag in the first place, so just add the missing code.
* stream: check for playback aborts on reading toowm42017-01-241-0/+2
| | | | | | | | | Benefits demux_mkv.c, or demux_lavf.c during probing. In particular demux_lavf.c can sometimes get "stuck" when reading from a slow/blocking source, and if probing needs more than a few iterations. Since this is a read of an atomic variable with relaxed semantics, this should have no impact on reading speed at all, not even theoretically.
* player: remove --stream-capture option/propertywm42017-01-211-34/+0
| | | | | | | | | | | | | | | 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.)
* demux, stream: add option to prevent opening referenced fileswm42016-12-041-0/+6
| | | | Quite irresponsibly hacked together. Sue me.
* stream_cb: don't add "*://" to protocol listwm42016-09-101-4/+1
| | | | | | | | | --list-protocol was printing a *:// entry, which looked strange at best. The "*" protocol was used to always match everything, so stream_cb.c could hook in custom protocols with a prefix chosen by the API user. Change it instead so that an empty protocol list means "match all