summaryrefslogtreecommitdiffstats
path: root/stream
Commit message (Collapse)AuthorAgeFilesLines
* 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
| | | | | | | | | | | | | | | For quite some time, msg.c hasn't output partial log messages anymore, and instead buffered them in memory. This means the MP_INFO() statement here just kept appending the message to memory, instead of outputting it. Easy enough to fix by abusing the status line (which means the frontend and this code will "fight" for the status line, but this code seems to win usually, as the frontend doesn't update it so often). Users should probably really switch to --cache-pause-initial. Fixes #5360.
* stream: use native libavformat reconnection featurewm42018-01-044-64/+3
| | | | | | | | | | | | | | | | | | 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-022-6/+14
| | | | | | | | | | | | | 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.
* stream_libarchive: fix seeking fallbackwm42017-12-241-14/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | In commit 1199c1e3, we added checks to every libarchive API call to make sure the archive was closed on ARCHIVE_FATAL - otherwise, libarchive could endow us with free CVEs (such as it apparently happens when you continue reading a rar archive that uses features not yet supported by libarchive). This broke the fallback for seeking in unseekable archive formats. Of course libarchive won't tell us directly whether a format implementation has seek support or not - and OF COURSE it returns ARCHIVE_FATAL if it has no seek support. (The error string, which you can retrieve via API, is actually more detailed, and also claims it's an "internal error". I don't think so, libarchive.) Returning ARCHIVE_FATAL means we have to assume free CVEs are ahead, and we have to close the archive. Which breaks the fallback in a dumb way (we have no way of telling which of those cases happened anyway). Fix this by assuming that all seek errors are potentially due to lack of seek support. If the seek call fails, reopen the archive, and set a flag so the seek API is never tried again. (This means we can still skip ahead for forward seeks, which is more efficient than skipping from the start of the archive entry.) Also fix an old typo in an error message.
* cache: propagate underlying stream seek errors in some caseswm42017-12-241-1/+12
| | | | | This just put the cache into an endless loop. This can happen simply if any seek call of the underlying stream returns an error.
* cache: lower default size to 2*10MBwm42017-12-231-2/+2
| | | | | | | | | | | | Reduce it from 75MB in both directions (forward/backwards) to 10MB each. The stream cache is kind of becoming useless in favor of the demuxer cache. Using both doesn't make much sense, because they will contain duplicated data for no reason. Still leave it at 10MB, which may help with mp4 a bit. libavformat's mp4 demuxer tends to seek too much, so we try to avoid triggering network level seeks by having some caching in the stream layer.
* dvb: Add multiple frontends support: MAX_FRONTENDS now 8.rim2017-12-164-88/+99
|
* 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_libarchive: Fix locale includes on macOSsfan52017-12-031-0/+5
| | | | Fixes #5108
* stream_libarchive, osdep: use stubs for POSIX 2008 locale on MinGWwm42017-11-121-0/+1
|
* stream_libarchive: workaround various types of locale braindeathwm42017-11-122-4/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix that libarchive fails to return filenames for UTF-8/UTF-16 entries. The reason is that it uses locales and all that garbage, and mpv does not set a locale. Both C locales and wchar_t are shitfucked retarded legacy braindeath. If the C/POSIX standard committee had actually competent members, these would have been deprecated or removed long ago. (I mean, they managed to remove gets().) To justify this emotional outbreak potentially insulting to unknown persons, I will write a lot of text. Those not comfortable with toxic language should pretend this is a religious text. C locales are supposed to be a way to support certain languages and cultures easier. One example are character codepages. Back when UTF-8 was not invented yet, there were only 255 possible characters, which is not enough for anything but English and some european languages. So they decided to make the meaning of a character dependent on the current codepage. The locale (LC_CTYPE specifically) determines what character encoding is currently used. Of course nowadays, this is legacy nonsense. Everything uses UTF-8 for "char", and what doesn't is broken and terrible anyway. But the old ways stayed with us, and the stupidity of it as well. C locales were utterly moronic even when they were invented. The locale (via setlocale()) is global state, and global state is not a reasonable way to do anything. It will break libraries, or well modularized code. (The latter would be forced to strictly guard all entrypoints set set/restore locales, assuming a single threaded world.) On top of that, setting a locale randomly changes the semantics of a bunch of standard functions. If a function respects locale, you suddenly can't rely on it to behave the same on all systems. Some behavior can come as a surprise, and of course it will be dependent on the region of the user (it doesn't help that most software is US-centric, and the US locale is almost like the C locale, i.e. almost what you expect). Idiotically, locales were not just used to define the current character encoding, but the concept was used for a whole lot of things, like e. g. whether numbers should use "," or "." as decimal separaror. The latter issue is actually much worse, because it breaks basic string conversion or parsing of numbers for the purpose of interacting with file formats and such. Much can be said about how retarded locales are, even beyond what I just wrote, or will wrote below. They are so hilariously misdesigned and insufficient, I can't even fathom how this shit was _standardized_. (In any case, that meant everyone w