summaryrefslogtreecommitdiffstats
path: root/stream
Commit message (Collapse)AuthorAgeFilesLines
* cache: move duplicated condition to a functionwm42017-05-151-6/+12
| | | | | While subtly duplicating such checks happens a lot in this file, this particular case can be easily factored into a function.
* cache: fix unnecessary seek blocking from f4d62dc4a0Uoti Urpala2017-05-151-9/+18
| | | | | | | | | | | | | | | | | | | | | Commit 374600cec0 ("cache: propagate seek failures") changed stream-level seeks to be done in the calling thread so possible errors could be reported. This commit included some rationale why doing the stream-level seeks synchronously was not a big issue. However, the following fixup commit f4d62dc4a0 changed the seek code to always synchronize with the cache thread and do seek handling there. This is a problem because it affects even seeks within already cached data (which require no stream-level seek). With a network server that sends data in bursts, the cache thread can be blocked in a read call for a long time; the added synchronization means that seeking within already downloaded data can have unnecessary long delays. Change cache_seek() to check whether the seek is expected to result in a stream-level seek, and skip synchronization if it is not. This means that seeks within the cached portion of the file now again happen immediately without possibly waiting for network. Signed-off-by: wm4 <wm4@nowhere>
* cache: clarify that copyright will be changed to LGPL v2.1 if possiblewm42017-05-111-0/+2
| | | | | | Clearly the licensing situation isn't confusing enough. I don't know why that guy insists on LGPLv3.
* stream_smb: disable by default, mark as GPLv3wm42017-05-111-1/+1
| | | | | | | | | | It seems libsmbclient has been GPLv3 for years. Also, it's certainly not LGPL (unlike some of its support libs like talloc). Thus, mpv built with Samba support is GPLv3. Disable it by default, so we don't have to go through the trouble to indicate the correct license in our output, and we don't trick people into distributing stuff under the wrong license.
* stream_file: change license to LGPLwm42017-05-111-10/+8
| | | | | | | | | | | | | | | | | | | | | This has a messy history all back to the initial commit with multiple refactors, but it seems almost all authors agreed. Exceptions: 2aa6acd9747: patch by someone who could not be reached. Whether or not this code is still in mpv is unknown, but the affected code was moved to stream.c at one point anyway. 3859bbd9fef: not sure if this is a patch by the mentioned person (I assume not) or the committer (who agreed to LGPL), but it seems the change is too trivial to affect copyright. It seems even the FD check can be dropped, which I'm doing in this commit. 58846451f0e: author doesn't reply. But reverting this and letting someone who has never seen this commit before redo it would lead to exactly the same code. So I'm claiming that the change is not copyrightable.
* cookies: change license to LGPLwm42017-05-112-15/+14
| | | | | | | All authors have agreed. One minor exception is 21a9221e7bb2 (patch by someone who wasn't asked), but we just remove the added line again. It seems unneeded.
* cache: change license to LGPL v3wm42017-05-081-7/+12
| | | | | | | | | | | | | All authors have agreed to the relicensing. iive has insisted on "LGPL v3 or later", which makes the file LGPL v3. His commits are the following: 84ec57750883 9b0d8c680f63. All other contributions are LGPL v2.1. I hope we can remove these changes completely one day to make this file LGPL v2.1. iive also authored commit 3934b160a829, but this code is completely gone today. (fork() and shared memory use was removed completely in favor of threads.)
* stream_null: change license to LGPLwm42017-05-081-7/+7
|
* 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/stream_dvdnav: show list of titles on verboseRicardo Constantino2017-03-291-0/+7
| | | | Same as stream_bluray, but only if no title is selected already.
* stream/stream_dvdnav: don't ignore setting titleRicardo Constantino2017-03-291-1/+1
| | | | | Probably a typo in 5e30e7a04. Fixes #4283
* stream_dvd: fix subs/audio detection on DVDs containing multi-PGC titlesqrwyeui2017-03-151-3/+3
| | | | | | | | | | On some DVDs, title number is not necessarily the same as the (first) PGC number. (Most often they are equal, since there's usually exactly one PGC per title, which is likely why this issue wasn't noticed before.) When searching for audio/subtitle metadata, we want to look at the actual PGC we're about to play. See discussion in issue #4235. Signed-off-by: wm4 <wm4@nowhere>
* dvb: add support for DVB-T2ivan-832017-03-064-633/+777
| | | | | | | | | | | | | | | | | | | | | | | | Probably does much more: + add support DVB-T2 * DVB params set to AUTO by default * MAX_CARDS: 4 -> 16 * DMX_SET_BUFFER_SIZE: 64kb -> 256kb + add DTV_CLEAR call before tune + add logic from https://github.com/olifre/mpv/commits/dvb-mixed-api-scan * rename type to delsys * single playlist per adapter * card -> adapter * fix channels order in playlist * update internal api * auto fallback to old DVB API on tune * fix DELSYS_SUPP_MASK value * remove tone - unused * add channel mem zeroize in config parser + add code from libdvbv5 for detect delivery systems * SYS_DVBC_ANNEX_AC replaced to SYS_DVBC_ANNEX_A + SYS_DVBC_ANNEX_C Signed-off-by: wm4 <wm4@nowhere>
* Revert "dvb: add support for DVB-T2"wm42017-02-144-766/+625
| | | | | | | | This reverts commit df91e492fd3365cf7db9c6ba4a721f8fcce0521c. Multiple issues such as weird code with undefined behavior (like (like conf_file*). The PR wasn't properly reviewed anyway (my error), so this commit should be reviewed and then merged again.
* dvb: add support for DVB-T2ivan-832017-02-134-625/+766
| | | | | | | | | | | | | | | | | | | | | | | | Probably does much more: + add support DVB-T2 * DVB params set to AUTO by default * MAX_CARDS: 4 -> 16 * DMX_SET_BUFFER_SIZE: 64kb -> 256kb + add DTV_CLEAR call before tune + add logic from https://github.com/olifre/mpv/commits/dvb-mixed-api-scan * rename type to delsys * single playlist per adapter * card -> adapter * fix channels order in playlist * update internal api * auto fallback to old DVB API on tune * fix DELSYS_SUPP_MASK value * remove tone - unused * add channel mem zeroize in config parser + add code from libdvbv5 for detect delivery systems * SYS_DVBC_ANNEX_AC replaced to SYS_DVBC_ANNEX_A + SYS_DVBC_ANNEX_C Signed-off-by: wm4 <wm4@nowhere>
* dvb: move priv allocation to dvb_openThomas V2017-02-101-1/+1
| | | | | | | This fixes a crash when changing channels; previously stream->priv would not be initialized when dvb_get_state reused the existing state. Signed-off-by: Thomas VanSelus <tvanselus@diospyros.us>
* tv: Zero-out newly-allocated handle in tv_new_handle()Frédéric Brière2017-02-051-4/+1
| | | | | | | Some fields (notably tv_channel_list) were left uninitialized, potentially causing problems later on. Fixes #4096
* stream: get rid of streamtype enumwm42017-02-0212-31/+9
| | | | | | | | | 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-022-7/+9
| | | | | | | | "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.
* tvi_dummy: don't return bad dummy PTSwm42017-02-021-2/+3
| | | | This makes the player spam timestamp warnings. Return NOPTS instead.
* 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_lavf: add support for data URIsRicardo Constantino2017-01-251-0/+1
| | | | | | | Only FFmpeg supports them and they need to be in the format data:// like other protocols or prefixed with ffmpeg:// or lavf://. Closes #4058
* 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-212-39/+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.)
* stream_bluray: use proper 0-based idxRicardo Constantino2017-01-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Even though the title list code was copied from FFmpeg/libbluray, I didn't check that mpv used 0-based title indexing. $ mpv bd://1 --bluray-device=. --msg-level=bd=v [bd] Opening bd:// [bd] List of available titles: [bd] idx: 1 duration: 00:00:36 (playlist: 00000.mpls) [bd] idx: 2 duration: 01:31:30 (playlist: 00001.mpls) [bd] idx: 3 duration: 00:00:50 (playlist: 00003.mpls) bd://1 actually opens idx 2 from the list, not 1. bd://mpls/1 opens playlist 00001.mpls as expected. With this commit: $ mpv bd://1 --bluray-device=. --msg-level=bd=v [bd] Opening bd:// [bd] List of available titles: [bd] idx: 0 duration: 00:00:36 (playlist: 00000.mpls) [bd] idx: 1 duration: 01:31:30 (playlist: 00001.mpls) [bd] idx: 2 duration: 00:00:50 (playlist: 00003.mpls) should play the expected idx 1.
* cache: remove redundant free()wm42017-01-091-3/+1
| | | | | | This code used to check/free multiple things, so the argument to free() was not always NULL. After the code was simplified, the free() became redundant.
* demux, stream: add option to prevent opening referenced fileswm42016-12-045-0/+16
| | | | Quite irresponsibly hacked together. Sue me.
* tv: fix option typewm42016-11-222-3/+3
| | | | | It appears this makes it actually compatible with the property. It was an ancient MPlayer artifact all along.
* stream_bluray: check title index/playlist rangeschnusch2016-10-171-6/+20
| | | | | Blu-ray title index/playlist must be in the range 0-99999, otherwise an error will be returned
* stream_bluray: select title by playlistschnusch2016-10-171-18/+34
| | | | | Blu-ray titles can now be selected by playlist number like this: bd://mpls/[playlist]
* stream_file: don't use poll() on directorieswm42016-10-141-3/+5
| | | | | | | | | | POSIX leaves poll() behavior on directories unspecified. While on Linux, it seems to behave the same way as regular files (always return immediately), this is not guaranteed. At least with OSX 10.12, it seems to wait, which essentially means that opening directories will "hang". Fixes #3530 and #3649.
* stream_libarchive: add some more points at which reading can be stoppedwm42016-10-011-1/+4
|
* stream_lavf: check seekable flag correctlywm42016-09-271-1/+1
| | | | | | AVIOContext.seekable is actually a bitfield. Currently, it has only AVIO_SEEKABLE_NORMAL defined, but it might be extended with a hint for non-byte seekability. Thus we should check it correctly.
* stream_lavf: fix determining seekabilitywm42016-09-261-3/+23
| | | | | | | | | | | | | | | | | | | | demux_lavf.c forces seek to being determined as supported if STREAM_CTRL_HAS_AVSEEK is returned as success. But it always succeeds with current FFmpeg versions. (Seems like Libav commit cae448cf broke this in early 2016.) Now we can't determine via private API whether the underlying protocol supports read_seek anymore. The affected protocols (mostly rtmp) also set seekable=0, meaning they signal they're not seekable, even though read_seek would work. (My guess is that this can't be fixed because even though seekable is in theory a combination of elaborate flags [of which only 1 is defined, AVIO_SEEKABLE_NORMAL], a seekable!=0 always means it's byte-seekable in some way.) So the FFmpeg API is being garbage _again_, and all what we can do is determining this via protocol name and a whitelist. Should fix the behavior reported in #1701.
* stream/stream_lavf: user-agent option is deprecatedRiCON2016-09-181-1/+1
| | | | | | There was both user-agent and user_agent options, the former is deprecated in FFmpeg/FFmpeg@27714b462 master. Libav uses both forms. This avoids constant `[ffmpeg] http: the user-agent option is deprecated, please use user_agent option` warnings using ytdl_hook.
* stream_cb: don't add "*://" to protocol listwm42016-09-102-5/+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", which also gets rid of the special-cased "*" entry.
* stream, demux, config: remove some dead/unneeded option-related codewm42016-09-092-92/+0
| | | | | | | | | | This has all been made unnecessary recently. The change not to copy the global option struct in particular can be made because now nothing accesses the global options anymore in the demux and stream layers. Some code that was accidentally added/changed in commit 5e30e7a0 is also removed, because it was simply committed accidentally, and was never used.
* stream_cdda: remove weird option parsing stuffwm42016-09-091-29/+12
| | | | | | | | | | Mostly untested. This is not compatible. It removes the URL fields for track range and cdrom speed (what did this even do). The device is not not to be prefixed with an additional "/" if it's put into the URL. I can't be bothered to keep these things compatible, just rip your damn CDs instead.
* tv: remove weird option parsing stuffwm42016-09-091-17/+0
| | | | Mostly untested.
* stream_dvb: remove weird option parsing stuffwm42016-09-091-24/+24
| | | | Mostly untested.
* stream_dvd, stream_dvdnav: remove weird option parsing stuffwm42016-09-084-66/+93
| | | | | | Same deal as with stream_bluray. Untested because I don't give a fuck about your shitty DVDs.
* stream_bluray: fix a minor memory leakwm42016-09-081-2/+3
|
* stream_bluray: remove weird option parsing stuffwm42016-09-081-51/+45
| | | | | | | Instead, parse manually. This is to get rid of the option API usages, which seem unnecessary and shoehorned. (Just look at the URL pseudo parsing and the dumb url_options map. They were pretty much artifacts from refactoring old mplayer code.)
* osdep: rename atomics.h to atomic.hwm42016-09-071-1/+1
| | | | | The standard header is stdatomic.h, so the extra "s" freaks me out every time I look at it.
* demux: do not access global optionswm42016-09-063-27/+65
| | | | | | | | | | | | | | | | | Don't access MPOpts directly, and always use the new m_config.h functions for accessing them in a thread-safe way. The goal is eventually removing the mpv_global.opts field, and the demuxer/stream-layer specific hack that copies MPOpts to deal with thread-safety issues. This moves around a lot of options. For one, we often change the physical storage location of options to make them more localized, but these changes are not user-visible (or should not be). For shared options on the other hand it's better to do messy direct access, which is worrying as in that somehow renaming an option or changing its type would break code reading them manually, without causing a compilation error.
* stream_cb: remove broken castwm42016-08-311-1/+1
| | | | | | | seek_fn is supposed to return the new file offset, or a negative error code. Our code doesn't use the offset, and only wants to know if any errors happened. The int cast is completely broken and might treat a successful seek as failed depending on whether the sign bit will be set.
* cache: don't use a backbuffer if the cache is as large as the filewm42016-08-261-10/+14
| | | | | | | | | | | | It's just wasted memory. One corner case is when a file grows during playback, but this is rare and usually happens on-disk only. The cache size was generally limited before this change already, so no reason to care. As an unrelated change, move the cache size info to the resize_cache() function. There's really no reason not to do this, and it's slightly more informative if the user changes the cache size at runtime.
* stream_memory: disable stream cachewm42016-08-261-0/+1
| | | | Obviously makes no sense and just wastes resources.
* stream/stream_bluray: display list of available titles on verboseRicardo Constantino2016-08-111-0/+6
| | | | Based on similar code on FFmpeg and libbluray's list_titles example.
* stream: fix double-free if cache init failswm42016-08-081-1/+3
| | | | | | | | | | | | If the normal stream cache init fails, and a file cache was initialized before, we free the file cache as well. But since the file cache is chained to the real stream, the real stream will also be freed. This has to be prevented by clearing the pointer to the original stream in the uncached_stream field. This could in particular be triggered by using --cache-initial=1000 and aborting playback during loading. (Without that option, stream cache init failure is far less likely.)
* client API: add stream_cb API for user-defined stream implementationsAman Gupta2016-08-073-0/+128
| | | | | | Based on #2630. Some heavy changes by committer. Signed-off-by: wm4 <wm4@nowhere>
* tvi_v4l2: fix style in the uninit functionBen Boeckel2016-08-051-4/+6
|
* tvi_v4l2: explicitly brace the codeBen Boeckel2016-08-051-1/+4
| | | | | It's fine either way, but this code is weirdly formatted. Make it more explicit.
* libarchive: sanitize non-UTF8 archive entrieswm42016-07-181-2/+2
| | | | | | | | | Some client API users simply don't like such filenames. For their sake, don't return them, but return a dummy filename instead. (Returning a latin1-ized version would work too, but is slightly more work.) Also remove the "\n" from the replacement dummy filename. This was accidental.
* libarchive: unify entry iteration between stream/demux layerswm42016-07-182-26/+51
| | | | No really good reason to duplicate this.
* cache: minor simplificationwm42016-07-111-7/+10
| | | | | Every cache_wakeup_and_wait() caller has to deal with asynchronous stream abort, so why not make it somehow part of the function.
* cache: fix previous commitwm42016-07-111-1/+11
| | | | | | | | | | | The cache reader thread actually unlocks the mutex protecting the underlying stream while reading from it. That's why other code goes out of its way to run certain stream operations on the cache thread. Do the same. We could have this simpler by creating a mechanism that would "park" the cache thread and make it wait for the lock (while we have it) in order to gain exclusive access. This could be done in the future.
* cache: propagate seek failureswm42016-07-111-7/+17
| | | | | | | | | | | Eagerly execute seeks to the underlying stream in the cache seek entrypoint itself. While asynchronous execution is a goal of the cache, it doesn't matter too much for seeks. They always were executed within the lock, so the reader was blocked anyway. It's not necessary to ensure async. execution here either, because seeks are relatively rare, and the demuxer can just stay blocked for a while. Fixes: mpv http://samples.mplayerhq.hu/V-codecs/DIV5/ayaneshk-test.avi
* Fix misspellingsstepshal2016-06-261-1/+1