summaryrefslogtreecommitdiffstats
path: root/stream
Commit message (Collapse)AuthorAgeFilesLines
* 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
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | libarchive (sometimes affectionately called libcve) has this annoying behavior that if after a "fatal" error, you do any operation on the archive context other than querying the error and closing the context, you get a free CVE. So we close the archive context in these situations. This can set p->mpa to NULL, so code accessing this field needs to be careful. This was not considered in a certain code path, and a simple truncated .rar file made it crash. Part of the problem was that the file inside the rar was a mkv file, which triggered seeking when the demux_mkv resync code encountered bogus data. This is probably a regression from a relatively recent change to this code (in any case mpv 0.29.1 doesn't crash). Fix this by adding the check. There's also a mechanism to reopen an archive context used to emulate seeking, since most libarchive format handlers don't support this natively. Add a reopen call to the codepath, because obviously it should always be possible to seek back into a "working" area of the file. There is a second bug with this: if reopening fails, we don't adjust the current position back to 0, which in some cases means we accidentally return bogus data to the reader when we shouldn't. Fix this by always resetting the position on reopening.
* 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_smb: remove unnecessary short write logicwm42019-09-141-11/+4
| | | | See previous commit. It compiles, but 100% untested.
* stream_file: remove unnecessary short write logicwm42019-09-141-10/+1
| | | | See previous commit.
* 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-135-663/+1
| | | | | | 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.
* stream: remove some more optical disc leftoverswm42019-09-132-15/+0
|
* Remove classic Linux analog TV support, and DVB runtime controlswm42019-09-1316-5522/+4
| | | | | | | | | | | | | | | | | | | | | | | | 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-135-16/+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 optical disc fancification layerswm42019-09-134-355/+8
| | | | | | | | | | | | | | | | | 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.
* stream_dvdnav: merge stream_dvd_commonwm42019-09-133-205/+106
| | | | Isolate icky DVD garbage into a single file.
* Remove libdvdread support in favor of libdvdnavwm42019-09-132-999/+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_file: avoid redundant freeAman Gupta2019-09-111-1/+0
| | | | | | | s->priv->cancel will be freed when s is freed, so freeing it explicitly is not required. Signed-off-by: Aman Gupta <aman@tmm1.net>
* stream_dvb: Increase timeout of streaming read.Oliver Freyermuth2019-09-021-1/+1
| | | | It seems some DVB-T2 cards take longer to push out data.
* stream_dvb: Adapt to VDR channel config format.Oliver Freyermuth2019-09-021-3/+8
| | | | | | | While they accept the frequency field with MHz for DVB-S, for DVB-C and DVB-T, it may be in Hz, kHz or MHz. The official rule is to multiply whatever is in the channels.conf by 1000 until a value > 1000000 is reached to get correct units for tuning.
* libarchive: add fallback for systems without C.UTF-8dudemanguy2019-05-041-2/+5
|
* Merge branch 'master' into pr6360Jan Ekström2019-03-111-2/+2
|\ | | | | | | | | | | Manual changes done: * Merged the interface-changes under the already master'd changes. * Moved the hwdec-related option changes to video/decode/vd_lavc.c.
| * stream_dvb: Correct range for dvbin-card option.Oliver Freyermuth2018-12-121-2/+2
| | | | | | | | | | | | Adapt documentation accordingly and also, fix an off-by-one check in the code. closes #6371
* | 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-062-0/+5
| | | | | | | | it's more like an input speed rather than a cache speed, but who cares.
* | Merge commit '559a400ac36e75a8d73ba263fd7fa6736df1c2da' into ↵Anton Kindestam2018-12-0514-1243/+14
|\ \ | |/ |/| | | | | | | wm4-commits--merge-edition This bumps libmpv version to 1.103
| * demux, stream: rip out the classic stream cachewm42018-08-3112-1099/+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.
| * options: add --http-proxywm42018-05-241-0/+4
| | | | | | | | Often requested, trivial.
| * player: some further cleanup of the mp_cancel crapwm42018-05-241-1/+1
| | | | | | | | | | | | | | | | | | | | Alway give each demuxer its own mp_cancel instance. This makes management of the mp_cancel things much easier. Also, instead of having add/remove functions for mp_cancel slaves, replace them with a simpler to use set_parent function. Remove cancel_and_free_demuxer(), which had mpctx as parameter only to check an assumption. With this commit, demuxers have their own mp_cancel, so add demux_cancel_and_free() which makes use of it.
| * command: whitelist some blocking accesses for certain demuxers/streamswm42018-05-242-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * stream_file: use a separate mp_cancel thingwm42018-05-241-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | The intention is to avoid that the parent mp_cancel retains the internally allocated wakeup pipe. File FDs are a relatively scarce resource, so try to avoid having too many. This might matter for subtitle files, for which it is relatively likely that they are loaded in large quantities. demux_lavf.c will close the underlying stream for most subtitle files, and now it will free the wakeup pipe too. Actually, there are currently only 1 or 2 mp_cancel objects per mpv core, but this could change if every external subtitle track gets its own mp_cancel in later commits.
| * misc: move mp_cancel from stream.c to thread_tools.cwm42018-05-246-143/+5
| | | | | | | | | | | | | | | | | | | | | | | | 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.
| * stream_file: properly detect stdin as pipewm42018-05-241-17/+16
| | | | | | | | | | | | | | | | | | | | | | | | There is some code that checks a FD for whether it is a regular file or not. If it's not a regular file, it e.g. enables use of poll() to avoid blocking forever. But this was done only for FDs that were open()ed by us, not from stdin special handling or fd://. Consequently, " | mpv -" could block the player. Fix this by moving the code and running for it on all FDs. Also, set p->regular_file even on mingw.
* | stream_smb: make sure the string is NULL-terminated after strncpypavelxdd2018-10-251-0/+1
| | | | | | | | strncpy does not guarantee that the string will be NULL-terminated.
* | stream_libarchive: fix hangs when demuxer does out of bound seekswm42018-10-011-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | This happened with a .flac file inside an archive. It tried to seek beyond the end of the archive entry in a format where seeking isn't supported. stream_libarchive handles these situations by skipping data. But when the end of the archive is reached, archive_read_data() returns 0. While libarchive didn't bother to fucking document this, they do say it's supposed to work like read(), so I guess a return value of 0 really means EOF. So change the "< 0" to "<= 0". Also add some error logging. The same file actually worked without out of bounds reads when extracted, so there still might be something very wrong.
* | stream_smb/stream_file: fix `write_buffer`Yclept Nemo2018-07-292-16/+16
| | | | | | | | | | | | | | Functions `write` and `smbc_write` are given a diminishing buffer of incorrect constant size. After partial writes, the code would do another write of the full original length, failing to subtract the amount already written.
* | stream_smb: locking to bypass libsmbclient issuesYclept Nemo2018-07-291-1/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Thread-unsafe libsmbclient is likely to crash when used simultaneously across threads. For example, by: mpv "smb://...mkv" --sub-file "smb://...srt" Work around this by locking all calls to this library under a single global mutex. This is a temporary solution. When the libsmbclient bug [1] is fixed, switch to the code from branch [2] which uses a new api to create per-thread smb contexts. Fixes [3]. [1] https://bugzilla.samba.org/show_bug.cgi?id=11413 [2] https://github.com/orbisvicis/mpv/tree/smbclient_threaded_api [3] https://github.com/mpv-player/mpv/issues/5936
* | stream_file: enable cache for FUSE filesystems on OpenBSD and FreeBSDgall0ws2018-06-051-1/+1
| |
* | options: add --http-proxywm42018-05-311-0/+4
| | | | | | | | Often requested, trivial.
* | stream_file: properly detect stdin as pipewm42018-05-251-17/+16
|/ | | | | | | | | | | | There is some code that checks a FD for whether it is a regular file or not. If it's not a regular file, it e.g. enables use of poll() to avoid blocking forever. But this was done only for FDs that were open()ed by us, not from stdin special handling or fd://. Consequently, " | mpv -" could block the player. Fix this by moving the code and running for it on all FDs. Also, set p->regular_file even on mingw.
* stream_libarchive: mark as needing cachewm42018-04-151-0/+1
| | | | | Seeking back can be excessively slow with most formats, so it'll benefit from this.
* 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_file: enable cache for FUSE filesystems on OS XPhilip Sequeira2018-03-151-1/+2
| | | | Requested in #634. Better late than never?
* stream_file: add more network file systems (Linux)Philip Sequeira2018-03-151-0/+1
| | | | Fixes #5643.
* tv: Recognise v4l2 'JPEG' fourccPhilip Langdale2018-03-043-2/+7
| | | | | | | | | | | | | Naturally, there's more than one fourcc that indicates an mjpeg stream. I have a particular ancient webcam here (Logitech QuickCam Messanger) that only supports the single 'JPEG' format, but there are other devices out there which support both 'JPEG' and 'MJPG' with no visible differences, and others where the streams are slightly different. Regardless of those details, it remains correct to treat 'JPEG' the same as 'MJPG' from a stream consumption perspective.
* stream_file: add mode for reading appended fileswm42018-02-211-7/+48
| | | | | | | | | | | | | Do this because retrying reading on higher levels (like the demuxer) usually causes tons of problems. A hack like this is simpler and could allow to remove some of the higher level retry behavior. This works by trying to detect whether the file is appended. If we reach EOF, check if the file size changed compared to the initial value. If it did, it means the file was appended at least once, and we set the p->appending flag. If that flag is set, we simply retry reading more data every time we encounter EOF. The only way to do this is polling, and we poll for at most 10 times, after waiting for 200ms every time.
* stream_lavf: remove deprecated hls protocol from whitelistwm42018-01-251-1/+1
| | | | | | The use of the FFmpeg hls protocol (as opposed to demuxer) is "discouraged", and probably only causes additional potential security problems at best, so drop it.
* stream_bluray: always show list of available titlesRicardo Constantino2018-01-231-2/+2
|
* stream_bluray: silence libbluray's debug messages unless we want themRicardo Constantino2018-01-231-0/+4
| | | | libbluray's way too verbose on default loglevel with non-breaking issues.
* Fix undefined preprocessor behaviorwm42018-01-181-1/+5
| | | | | | | | | | | This commit eliminates the following clang warning: warning: macro expansion producing 'defined' has undefined behavior [-Wexpansion-to-defined] Going by the clang commit message, this seems to be explicitly specified as UB by the standard, and they added this warning because MSVC apparently results in different behavior. Whatever, we can just avoid the warning with some small changes.
* stream_bluray: support detecting UHD BD directoriesRicardo Constantino2018-01-111-10/+7
| | | | Close #5325
* cache: fix --cache-initial status messagewm42018-01-071-4/+3
| | | | | | | | | | | | | |