summaryrefslogtreecommitdiffstats
path: root/stream/stream.c
Commit message (Collapse)AuthorAgeFilesLines
* options: introduce --cache=yes choicewm42015-03-121-0/+2
| | | | | | I think this is what I alwass missed ever since I found the MPlayer cache options: a way to enable the cache on local files with the default settings, whatever they are.
* stream: use relaxed atomic loads for checking playback abortswm42015-03-091-1/+1
| | | | | | | Seems appropriate, and will probably avoid performance surprises with scary architectures which don't have trivial implementations for atomic loads. (Consider that demux_mkv calls this very often now, and libavformat demuxers and streams did this for a while now.)
* player: refine rar:// playlist-safety handlingwm42015-03-021-1/+0
| | | | | | | | | | | | It was possible to make the player play local files by putting rar:// links into remote playlists, and some other potentially unsafe things. Redo the handling of it. Now the rar-redirector (the thing in demux_playlist.c) sets disable_safety, which makes the player open any playlist entries returned. This is fine, because it redirects to the same file anyway (just with different selection/interpretation of the contents). On the other hand, rar:// itself is now considered fully unsafe, which means that it is ignored if found in normal playlists.
* stream: remove stream filter conceptwm42015-02-271-33/+11
| | | | Unused since the previous commit. (Apparently it was a stupid idea.)
* stream_rar: treat rar files as playlistswm42015-02-271-4/+2
| | | | | | | | | | | | Refactors an older hack, which for some reason used a more complicated way. This generates the playlist representing the contents of the rar file in demux_playlist.c. The pseudo-demuxer could easily be separate from the the playlist parsers (and in fact there's almost no shared code), but I don't think this obscure feature deserves a separate file. Sample files created with: rar a -v20000k -m0 files.rar file1.mkv file1.mkv
* stream: get rid of remaining uses of the end_pos fieldwm42015-02-061-16/+2
| | | | | | | | Most things stopped using this field for better support of growing files. Go through the trouble to repalce the remaining uses, so it can be removed. Also move the "streaming" field; saves 4 bytes (wow!).
* stream: minor cleanupswm42015-02-061-82/+59
| | | | | | | | | | | | | | | | Fix return types and return values to make them more consistent. Some reformatting and making code more concise. In stream_reconnect(), avoid the additional mp_cancel_test() call by moving the "connection lost" message below the mp_cancel_wait() call, which effectively leads to the same behavior when the stream was already canceled. (The goal is not to show the message in this case.) Merge stream_seek_long() into stream_seek(). It was the only caller. Always clear the eof flag on seeks. Reduce access to stream internals in cache.c and stream_lavf.c.
* stream: slightly improve reconnect behaviorwm42015-02-061-18/+28
| | | | | Wait for a longer time between reconnects. Introdeuce and use mp_cancel_wait(), so that quitting is still immediate.
* stream: reject overly long URLswm42015-01-211-0/+4
|
* stream_lavf: escape disallowed characters in http URLswm42015-01-211-2/+2
| | | | | | | | | | | | | | | | | In my opinion, libavformat should be doing this. But a patch handling a very safe case rejected, so I suppose we have to do it manually. (This patch was only escaping spaces, which can never work because they break the basic syntax of the HTTP protocol.) This commit attempts to do 2 things: - Try to guess whether libavformat will use the URL for http. This is not always trivial, because some protocols will recursively pass part of the user URL to http in some way. - Try to fix invalid URLs. We fix only the simplest case: only characters that are never valid are escaped. This excludes invalid escape codes, which happen with freestanding '%' characters. Fixes #1495.
* stream: always make stream dumping/capturing append to output filewm42014-12-271-1/+1
| | | | Partially fixes #1393 (but not really).
* stream: always disable cache for pseudo-streamswm42014-12-241-0/+3
| | | | | Streams which don't have a full_buffer function never return any actual data. Slight improvement over commit 5640c195.
* Do not call strerror()wm42014-11-261-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | ...because everything is terrible. strerror() is not documented as having to be thread-safe by POSIX and C11. (Which is pretty much bullshit, because both mandate threads and some form of thread-local storage - so there's no excuse why implementation couldn't implement this in a thread-safe way. Especially with C11 this is ridiculous, because there is no way to use threads and convert error numbers to strings at the same time!) Since we heavily use threads now, we should avoid unsafe functions like strerror(). strerror_r() is in POSIX, but GNU/glibc deliberately fucks it up and gives the function different semantics than the POSIX one. It's a bit of work to convince this piece of shit to expose the POSIX standard function, and not the messed up GNU one. strerror_l() is also in POSIX, but only since the 2008 standard, and thus is not widespread. The solution is using avlibc (libavutil, by its official name), which handles the unportable details for us, mostly. We avoid some pain.
* stream: fix endian swappingwm42014-11-211-2/+2
| | | | | | | | | | In addition to the messed-up expression, the endianness was also inverted. The code reads big endian by default. It "worked" by coincidence, but for little endian, codepoints outside of latin1 were broken. The broken expression was found by Coverity.
* stream: reduce ifdeffery for win32 somewhatwm42014-11-181-12/+7
| | | | Remove the ones which are not strictly needed.
* stream: signal a Windows event object on cancelJames Ross-Gowan2014-11-181-0/+31
| | | | | This will be used in the following commit to cancel subprocesses started by Lua.
* stream: fix --stream-dump dropping the file headerwm42014-10-251-10/+12
| | | | | | | | | | | | | | | | | | stream_rar.c peeks the first few bytes when trying to open, which means that opening any stream reads at least 2KB of data (internal buffer size) on opening. This broke --stream-dump, which saved only the data following this initial buffer. Hack it around by writing the current buffer to the capture file too, and move stream_capture_write() above stream_set_capture_file() for this purpose. Cleaner solutions might include: handling the terrible rar thing differently, or using the "proper" stream API for dumping. (The latter is not done, because --stream-dump shares code with the --stream-capture misfeature.) Fixes #1215.
* stream: remove duplicate messagewm42014-10-251-1/+1
|
* stream: stupid compilation workaround for win32wm42014-10-191-1/+1
| | | | | | | | On win32, open() is a function-like macro. The line of code changed with this commit accidentally expanded the macro. Prevent this macro expansion. Not sure why that happened now. Since as far as I remember system functions can be defined as macros, this affects in theory not only win32.
* lua: add an utility function for starting processeswm42014-10-191-7/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Because 1) Lua is terrible, and 2) popen() is terrible. Unfortunately, since Unix is also terrible, this turned out more complicated than I hoped. As a consequence and to avoid that this code has to be maintained forever, add a disclaimer that any function in Lua's utils module can disappear any time. The complexity seems a bit ridiculous, especially for a feature so far removed from actual video playback, so if it turns out that we don't really need this function, it will be dropped again. The motivation for this commit is the same as with 8e4fa5fc. Note that there is an "#ifndef __GLIBC__". The GNU people are very special people and thought it'd be convenient to actually declare "environ", even though the POSIX people, which are also very special people, state that no header declares this and that the user has to declare this manually. Since the GNU people overtook the Unix world with their very clever "embrace, extend, extinguish" strategy, but not 100%, and trying to build without _GNU_SOURCE is hopeless; but since there might be Unix environments which support _GNU_SOURCE features partially, this means that in practice "environ" will be randomly declared or not declared by system headers. Also, gcc was written by very clever people too, and prints a warning if an external variable is declared twice (I didn't check, but I suppose redeclaring is legal C, and not even the gcc people are clever enough to only warn against a definitely not legal C construct, although sometimes they do this), ...and since we at mpv hate compiler warnings, we seek to silence them all. Adding a configure test just for a warning seems too radical, so we special-case this against __GLIBC__, which is hopefully not defined on other libcs, especially not libcs which don't implement all aspects of _GNU_SOURCE, and redefine "environ" on systems even if the headers define it already (because they support _GNU_SOURCE - as I mentioned before, the clever GNU people wrote software THAT portable that other libcs just gave up and implemented parts of _GNU_SOURCE, although probably not all), which means that compiling mpv will print a warning about "environ" being redefined, but at least this won't happen on my system, so all is fine. However, should someone complain about this warning, I will force whoever complained about this warning to read this ENTIRE commit message, and if possible, will also force them to eat a printed-out copy of the GNU Manifesto, and if that is not enough, maybe this person could even be forced to convince the very clever POSIX people of not doing crap like this: having the user to manually declare somewhat central symbols - but I doubt it's possible, because the POSIX people are too far gone and only care about maintaining compatibility with old versions of AIX and HP-UX. Oh, also, this code contains some subtle and obvious issues, but writing about this is not fun.
* stream: better error message for unmatched protocolwm42014-10-171-1/+3
| | | | See #1187.
* stream: change internal instead of external pos when dropping bufferswm42014-10-081-0/+1
| | | | | | | | | | | | | | | | | | | stream provides a read buffer (so even something like stream_read_char() is very fast). This means the stream reads ahead by a few KBs, and implies that the internal position (s->pos, which would match e.g. the file position in stream_file.c), and the external position (stream_tell()) can be different. stream_tell() shows how these are related. When dropping buffers, which happens on byte-level discontinuities with a bunch of streams (including DVB), we should not change the position as seen by the demuxer. On the other hand, the internal position is not really meaningful, since these streams aren't seekable anyway. So just change the code such that stream_drop_buffers() doesn't change the demuxer visible position. I'm hoping that this will fix a few problems with DVB. (Also see previous commit.)
* stream: don't drop buffers on failed seekswm42014-09-291-6/+2
| | | | | | | | | | | Might matter when libavformat tries to do tiny seekbacks in an unseekable stream, and the seekback buffer isn't large enough. In this case, seeking would fail, and would drop the current buffer. The seekback would end up dropping future data. This change probably doesn't have any observable effects. libavformat normally has its own stream buffer, and demux_mkv.c tries carefully never to seek back.
* stream: change malloc+memset to callocBruno George Moraes2014-09-271-3/+1
| | | | | | | Also removed some memset that were left on some calloc that was already in the code. Signed-off-by: wm4 <wm4@nowhere>
* stream_bluray: allow opening BDMV directories directlywm42014-09-261-0/+2
| | | | | | | | Similar as the previous commits. Most of the code is actually copied from the stream_dvdnav.c code, but I'd rather prefer to duplicate it, than to entangle them. The latter would probably result in terrible things in a few years.
* stream_dvdnav: allow opening DVD directories directlywm42014-09-261-0/+2
| | | | | | | | Same hack as with stream_dvd.c. VIDEO_TS.IFO files are now opened via stream_dvdnav.c. Directories containing a VIDEO_TS.IFO or VIDEO_TS/VIDEO_TS.IFO file are also opened with it.
* Remove mpbswap.hwm42014-09-251-2/+1
| | | | | | This was once central, but now it's almost unused. Only vf_divtc still uses it for extremely weird and incomprehensible reasons. The use in stream.c is trivial. Replace these, and remove mpbswap.h.
* stream: fix build with emulated atomicswm42014-09-131-3/+3
| | | | | This code was legal with C11 atomics, but it fails with our compatibility wrapper.
* stream: redo playback abort handlingwm42014-09-131-16/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This mechanism originates from MPlayer's way of dealing with blocking network, but it's still useful. On opening and closing, mpv waits for network synchronously, and also some obscure commands and use-cases can lead to such blocking. In these situations, the stream is asynchronously forced to stop by "interrupting" it. The old design interrupting I/O was a bit broken: polling with a callback, instead of actively interrupting it. Change the direction of this. There is no callback anymore, and the player calls mp_cancel_trigger() to force the stream to return. libavformat (via stream_lavf.c) has the old broken design, and fixing it would require fixing libavformat, which won't happen so quickly. So we have to keep that part. But everything above the stream layer is prepared for a better design, and more sophisticated methods than mp_cancel_test() could be easily introduced. There's still one problem: commands are still run in the central playback loop, which we assume can block on I/O in the worst case. That's not a problem yet, because we simply mark some commands as being able to stop playback of the current file ("quit" etc.), so input.c could abort playback as soon as such a command is queued. But there are also commands abort playback only conditionally, and the logic for that is in the playback core and thus "unreachable". For example, "playlist_next" aborts playback only if there's a next file. We don't want it to always abort playback. As a quite ugly hack, abort playback only if at least 2 abort commands are queued - this pretty much happens only if the core is frozen and doesn't react to input.
* stream: change cache return valueswm42014-09-071-3/+3
| | | | | Basically a cosmetic change, because currently the player just continues even if the cache fails initializing.
* player: don't allow remote playlists to load local fileswm42014-09-011-0/+4
| | | | | | | | Because that might be a bad idea. Note that remote playlists still can use any protocol marked with is_safe and is_network, because the case of http-hosted playlists containing URLs using other streaming protocols is not unusual.
* player: always load playlistswm42014-08-311-0/+16
| | | | | | | | | Until now, you had to use --load-unsafe-playlists or --playlist to get playlists loaded. Change this and always load playlists by default. This still attempts to reject unsafe URLs. For example, trying to invoke libavdevice pseudo-demuxer is explicitly prevented. Local paths and any http links (and some more) are always allowed.
* stream: correctly propagate uncached stream typewm42014-08-301-1/+1
| | | | | This makes the ordered chapter code not think that a stream from the local filesystem is not a local file (it checks uncached_type).
* Move compat/ and bstr/ directory contents somewhere elsewm42014-08-291-2/+2
| | | | | | | | | bstr.c doesn't really deserve its own directory, and compat had just a few files, most of which may as well be in osdep. There isn't really any justification for these extra directories, so get rid of them. The compat/libav.h was empty - just delete it. We changed our approach to API compatibility, and will likely not need it anymore.
* stream: tweaks to network reconnection codewm42014-08-291-3/+1
| | | | | | | | | | | | | | Don't reconnect to the cache (since the cached stream already handles reconnection). This is necessary, because since commit 0b428e44 the "streaming" field (which also controls whether attempting to reconnect makes sense at all) is inherited to the cache stream wrapper. Also, let the stream reset its own position on reconnect. This removes some assumptions and messy handling from the reconnect function. Make sure the cache is dropped on reconnect. This takes care of readjusting the stream position if necessary. (Also drop the cache on DVB channel switching commands.)
* player: redo how stream caching and pausing on low cache workswm42014-08-271-0/+1
| | | | | | | | | | | | | | | | | | | Add the --cache-secs option, which literally overrides the value of --demuxer-readahead-secs if the stream cache is active. The default value is very high (10 seconds), which means it can act as network cache. Remove the old behavior of trying to pause once the byte cache runs low. Instead, do something similar wit the demuxer cache. The nice thing is that we can guess how many seconds of video it has cached, and we can make better decisions. But for now, apply a relatively naive heuristic: if the cache is below 0.5 secs, pause, and wait until at least 2 secs are available. Note that due to timestamp reordering, the estimated cached duration of video might be inaccurate, depending on the file format. If the file format has DTS, it's easy, otherwise the duration will seemingly jump back and forth.
* Revert "Remove DVD and Bluray support"wm42014-07-151-0/+15
| | | | | | This reverts commit 4b93210e0c244a65ef10a566abed2ad25ecaf9a1. *shrug*
* Remove DVD and Bluray supportwm42014-07-141-15/+0
| | | | It never worked well. Just remux your DVD and BD images to mkv.
* stream: don't sleep for reconnecting network if playback is stoppedwm42014-07-121-0/+2
| | | | | | Also silences the bogus message if that happens. CC: @mpv-player/stable
* dvd, bluray, cdda: add demux_disc containing all related hackswm42014-07-051-5/+0
| | | | | | | | | | | | DVD and Bluray (and to some extent cdda) require awful hacks all over the codebase to make them work. The main reason is that they act like container, but are entirely implemented on the stream layer. The raw mpeg data resulting from these streams must be "extended" with the container-like metadata transported via STREAM_CTRLs. The result were hacks all over demux.c and some higher-level parts. Add a "disc" pseudo-demuxer, and move all these hacks and special-cases to it.
* options: add --list-protocols optionAlessandro Ghedini2014-06-301-0/+22
|
* stream: add a file cachewm42014-06-221-16/+32
| | | | | | | | | For remarks, pretty much see the manpage additions. Could help with network streams that require too much seeking (maybe), or might be extended to help with the use case of watching and downloading a file at the same time. In general, it might be a useless feature and could be removed again.
* Add more constwm42014-06-111-1/+1
| | | | | | | While I'm not very fond of "const", it's important for declarations (it decides whether a symbol is emitted in a read-only or read/write section). Fix all these cases, so we have writeable global data only when we really need.
* stream_dvd, stream_dvdnav, stream_bluray: remove global option variableswm42014-06-111-4/+0
|
* stream_cdda: remove global option variableswm42014-06-111-1/+0
|
* stream: add a generic way to setup stream priv defaultswm42014-06-111-0/+2
| | | | | | | | | | | | | | | Usually, each stream driver declares the size and option list of its private data. This was pretty natural for when most streams still used global variables to setup their defaults. They did by pointing priv_defaults to the (mutable) struct containing the option values. But falls short when storing the option values in MPOpts. So provide a somewhat inelegant but simple way to let the stream implementation setup the priv struct at initialization time. This is done with the get_defaults callback. It should return a copy of the struct used in MPOpts. (A copy, because if MPOpts is changed, string fields might be deallocated, and if that field is not described by stream_info.options, it won't be copied on init.)
* stream: remove VCD supportwm42014-06-011-4/+0
| | | | | | | | | If a single person complains, I will readd it. But I don't expect that this will happen. The main reason for removing this is that it's some of the most unclean code remaining, it's unmaintained, and I've never ever heard of someone using it.
* stream: unbreak writeable streamswm42014-05-271-2/+2
| | | | | | | | | So, basically this worked only with streams that were not local files, because stream_dvd.c "intercepts" local files to check whether they point to DVD images. This means if a stream is not writeable, we have to try the next stream implementation. Unbreaks 2-pass encoding.
* stream: remove chaos related to writeable streamswm42014-05-241-2/+8
| | | | | | | | | | For some reason, we support writeable streams. (Only encoding uses that, and the use of it looks messy enough that I want to replace it with FILE or avio today.) It's a chaos: most streams do not actually check the mode parameter like they should. Simplify it, and let streams signal availability of write mode by setting a flag in the stream info struct.
* stream: don't use end_poswm42014-05-241-34/+29
| | | | | | | | | | | | | | | | | | | Stop using it in most places, and prefer STREAM_CTRL_GET_SIZE. The advantage is that always the correct size will be used. There can be no doubt anymore whether the end_pos value is outdated (as it happens often with files that are being downloaded). Some streams still use end_pos. They don't change size, and it's easier to emulate STREAM_CTRL_GET_SIZE using end_pos, instead of adding a STREAM_CTRL_GET_SIZE implementation to these streams. Make sure int64_t is always used for STREAM_CTRL_GET_SIZE (it was uint64_t before). Remove the seek flags mess, and replace them with a seekable flag. Every stream must set it consistently now, and an assertion in stream.c checks this. Don't distinguish between streams that can only be forward or backwards seeked, since we have no such stream types.
* stream: kill start_pos, remove --sb optionwm42014-05-241-1/+0
| | | | | | | | | | | | | | | | | | | | stream.start_pos was needed for optical media only, and (apparently) not for very good reasons. Just get rid of it. For stream_dvd, we don't need to do anything. Byte seeking was already removed from it earlier. For stream_cdda and stream_vcd, emulate the start_pos by offsetting the stream pos as seen by the rest of mpv. The bits in discnav.c and loadfile.c were for dealing with the code seeking back to the start in demux.c. Handle this differently by assuming the demuxer is always initialized with the stream at start position, and instead seek back if initializing the demuxer fails. Remove the --sb option, which worked by modifying stream.start_pos. If someone really wants this option, it could be added back by creating a "slice" stream (actually ffmpeg already has such a thing).
*