summaryrefslogtreecommitdiffstats
path: root/stream/cache.c
Commit message (Collapse)AuthorAgeFilesLines
* 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-041-1/+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.)
* 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.
* cache: throttle wakeupswm42017-10-201-2/+14
| | | | | | | | | | | | | | In the extreme case, reading 1 byte would wake up the cache to make the cache thread read 1 byte. This would be extremely inefficient. This will not normally happen in our cache implementation, but it's still present to some lesser degree. Normally you'd set a predefined "cache too low" boundary, after which you would restart reading. For some reason something like this is already present using a hardcoded value (FILL_LIMIT - I don't even know the deeper reason why this exists). So use that to reduce wakeups. This doesn't fix redundant wakeups on EOFs, which is especially visible should something keep retrying reading on EOF (like in an endless loop).
* build: switch preliminary LGPL mode from v3 to v2.1wm42017-10-051-8/+1
| | | | | | | | | | | iive agreed to relicense things that are still in mpv to LGPLv2.1. So change the licenses of the affected files, and rename the configure switch for LGPL mode to --enable-preliminary-lgpl2. (The "preliminary" part will probably be removed from the configure switch soon as well.) Also player/main.c hasn't had GPL parts since a few commits ago.
* stream: move cache option declarations to cache.cwm42017-06-231-0/+27
| | | | | | | | If they are copyrightable, iive's changes (commits listed in cache.c) would make them LGPL 3+. To avoid that options.c becoming LGPL 3, move the option declarations to cache.c. struct mp_cache_opts is still in options.h, but we consider that irrelevant, and options.h will become LGPL 2.1+ later.
* 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.
* 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.)
* 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.
* 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.
* 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
* cache: simplify speed calculationswm42016-05-121-19/+7
| | | | | | | | | | Remove the attempted cleverness; keep it dumb. This strictly calculates the average speed over an at least 1 second window (longer if I/O blocks it). Since this doesn't reset the speed anymore when reading stops by going idle, the results might actually be more accurate now.
* cache: disable useless "Cache is not responding" warningwm42016-04-031-1/+1
| | | | | | | | | | | | | | | Tuning it in a way to be actually useful is too much effort. As alternative, there's the "buffering" detection, which operates on a much higher level. The only disadvantage is that it's harder to guess for the user whether this is a network problem, or if e.g. libavformat is probing too much data when opening a stream. Maybe the cache-speed property is helpful here. For now, do not remove the associated code, but just silence the warning. Fixes #3019.
* cache: fix incorrect EOF conditionwm42016-03-291-1/+2
| | | | | | Don't assume EOF if we didn't try to read anything in the first place. Fixes regressions in particular with low cache sizes, which triggered the other code paths more often.
* cache: use a single STREAM_CTRL for various cache infowm42016-03-291-19/+14
| | | | | | | | Instead of having a separate for each, which also requires separate additional caching in the demuxer. (The demuxer adds an indirection, since STREAM_CTRLs are not thread-safe.) Since this includes the cache speed, this should fix #3003.
* command: add cache-speed propertywm42016-03-201-14/+47
| | | | | | | Should reflect I/O speed. This could go into the terminal status line. But I'm not sure how to put it there, since it already uses too much space, so it's not there yet.
* cache: remove unused STREAM_CTRL_RESUME_CACHEwm42016-03-031-4/+0
| | | | Went way with DVD/BD menu support.
* cache: add mechanism for disabling readaheadwm42016-01-181-1/+16
| | | | Will be used in a following commit.
* player, stream_dvb: implement dvb-channel-name property.Oliver Freyermuth2016-01-141-0/+1
| | | | | | | | | On read, it returns the name of the current DVB program, on write, it triggers a channel-switch to the program if it is found in the channel list of the currently active card. Compared to the dvb-channel property which already exists and is a pair of integers (card + channel number) this has the limitation of not switching the card, but is probably of much more common use.
* cache: remove useless return valuewm42016-01-111-5/+2
| | | | It was unused, and also returned the wrong value in some cases.
* cache: do not include backbuffer size in total stream cache sizewm42015-09-101-1/+1
| | | | | | | | | This causes weirdness with the "cache-size" property and option. Only the read handler of the property included the backbuffer, while all others did not. Make it consistent, and subtract the backbuffer size from the cache size. Fixes #2305.
* stream: provide a stream_get_size() convenience functionwm42015-08-181-3/+3
| | | | | And use it everywhere, instead of retrieving the size manually. Slight simplification.
* cache: make backbuffer size configurablewm42015-07-221-5/+12
| | | | | | | | | | Allow setting an arbitrary amount, instead of the fixed 50%. This is nto striclty backwards compatible. The defaults don't change, but the --cache/--cache-default options now set the readahead portion. So in practice, users who configured this until now will see the double amount of cache being used, _plus_ the 75MB default backbuffer will be in use.
* cache: fix backbuffer logicwm42015-07-221-4/+5
| | | | | | Currently, this is perfectly equivalent, because back_size is hardcoded to buffer_size/2. But this fixes the logic for the case the back_size can be configured freely.
* cache: limit readahead size to half the cache size at the beginningwm42015-05-291-0/+6
| | | | | | | | | | | | | | | | | | | | | | Normally, the cache keeps 50% of the buffer for seeking backwards. Until now, the cache just used the full buffer size at the beginning of a file, because the 50% normally reserved for the backbuffer are unused. This caused a problem: when streaming from http, the player would first read about 150MB (default cache size), then stop until 75MB of the cache has been played. (Until the 75MB position, the cache is fully used, so nothing new can be read. After that, part of the backbuffer starts getting unreserved, and can be used for readahead.) This long read pause can cause the server to terminate the connection. Reconnecting may be possible, but if youtube-dl is used, the media URL may have become invalid. Fix this by limiting readahead to 50% even if unnecessary. The only exception is when the whole file would fit in the cache. In this case, it won't matter if we can't reconnect, because the cache covers everything anyway, and hopefully the cache will stay valid. Likely fixes #2000.
* threads: use utility+POSIX functions instead of weird wrapperswm42015-05-111-3/+6
| | | | | | | There is not much of a reason to have these wrappers around. Use POSIX standard functions directly, and use a separate utility function to take care of the timespec calculations. (Course POSIX for using this weird format for time values.)
* cache: exit early on cancellationwm42015-04-211-0/+3
| | | | | | | An approximate measure to make it exit possibly slightly earlier. Relatively speaking, some time will pass between cancellation and the cache actually being requested to exit, so it's good if the cache returns EOF immediately.
* cache: another minor simplificationwm42015-04-211-11/+5
| | | | | | | | The caller can check for cache interruption instead. There's no need to define special return values and such. It would be rather hard to make waiting for the condition and stream cancellation atomic too (and pointless, since the underlying stream will also be "cancelled" and exit early), so nothing about cancellation being a separate call will change.
* cache: simplify the check for printing the "cache stuck" messagewm42015-04-211-16/+6
| | | | | | | | | | | | This put some effort into distinguishing between two messages to print - all worthless. Even more so, this kept printing the message, which doesn't feel overly useful either. (The message will be printed repeatedly anyway if network recovers for a while and then gets stuck again.) All in all, the demuxer cache triggering the buffering state does a better job here. But don't remove it completely, since knowing that the network did nothing for a relatively short time is still useful.
* Update license headersMarcin Kurczewski2015-04-131-5/+4
| | | | Signed-off-by: wm4 <wm4@nowhere>
* cache: assume file size from EOF positionwm42015-03-041-2/+8
| | | | | | If we're caching a stream with unknown size, and we reach EOF, then consider the EOF position the file size. Typically makes sense when reading from a pipe or a http connection that did not send a size.
* cache: use MPCLAMP() macrowm42015-02-251-9/+2
|
* cache: limit to file sizewm42015-02-251-1/+8
| | | | | Saves some memory. Should be especially helpful if many small files are loaded, like when mass-loading subtitle files and the cache is enabled.
* cache: silence "EOF reached" messagewm42015-02-181-1/+1
| | | | | | | | | | | | | This message will be printed relatively often once EOF is reached. In some cases this is rather annoying, for example when playing HLS. (With HLS, the stream is just a playlist file, while libavformat opens actual media files without mpv's knowledge, so the cache is completely useless and hits EOF instantly.) That it retries reading is apparently a good thing: at least local files can grow, and even after the player got the EOF, playback _could_ be resumed by basically polling and detecting that there is more data. So I'm not changing this behavior yet.
* stream: minor cleanupswm42015-02-061-2/+1
| | | | | | | | | | | | | | | | 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.
* cache: cache-position needs to be int64_tOliver Freyermuth2015-01-131-1/+1
| | | | | | Both max_filepos and offset are int64_t, so pos can overflow, e.g. causing endless loops in stream implementation.
* Do not call strerror()wm42014-11-261-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | ...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.
* cache: don't relay STREAM_CTRL_AVSEEK if it's unsupportedwm42014-11-011-0/+4
| | | | | | | | Thanks to STREAM_CTRL_HAS_AVSEEK, we actually know whether CTRL_AVSEEK is implemented at all, and we can avoid a blocking wait on the cache if demux_lavf sends CTRL_AVSEEK even if it won't wait. I'm hoping this can't currently happen, but why hope if we can explicitly prevent it. It'll make us more robust against future changes in libavformat.
* demux_lavf: mark as seekable if protocol supports seeking by timewm42014-10-301-0/+4
| | | | | | | | | | | | Basically, this will mark the demuxer as seekable with rtmp* and mmsh protocols. These protocols have network-level time seeking, and whether you can seek on the byte level does not matter. Until now, seeking was typically only enabled because of the cache, and a (nonsensical) warning was shown accordingly. It still could happen that the server doesn't actually support thse requests (or simply rejects them), so this is somewhat imperfect.
* Set thread name for debuggingwm42014-10-191-0/+1
| | | | | | | | | | Especially with other components (libavcodec, OSX stuff), the thread list can get quite populated. Setting the thread name helps when debugging. Since this is not portable, we check the OS variants in waf configure. old-configure just gets a special-case for glibc, since doing a full check here would probably be a waste of effort.
* stream: redo playback abort handlingwm42014-09-131-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-4/+4
| | | | | Basically a cosmetic change, because currently the player just continues even if the cache fails initializing.
* stream: tweaks to network reconnection codewm42014-08-291-0/+3
| | | | | | | | | | | | | | 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.)
* stream: hack-fix rtmp-level seekingwm42014-07-301-0/+1
| | | | | | | | | | | | | This didn't work, because the timebase was wrong. According to the ffmpeg doxygen, if the stream index is -1 (which is what we used), the timebase is AV_TIME_BASE. But this didn't work, and it really expected the stream's timebase. Quite "surprising", since this feature (avio_seek_time) is used by rtmp only. Fixing this properly is too hard, so hack-fix our way around it. STREAM_CTRL_SEEK_TO_TIME is also used by DVD/BD, so a new STREAM_CTRL_AVSEEK is added. We simply pass-through the request verbatim.
* demux: add a demuxer threadwm42014-07-161-23/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds a thread to the demuxer which reads packets asynchronously. It will do so until a configurable minimum packet queue size is reached. (See options.rst additions.) For now, the thread is disabled by default. There are some corner cases that have to be fixed, such as fixing cache behavior with webradios. Note that most interaction with the demuxer is still blocking, so if e.g. network dies, the player will still freeze. But this change will make it possible to remove most causes for freezing. Most of the new code in demux.c actually consists of weird caches to compensate for thread-safety issues (with the previously single-threaded design), or to avoid blocking by having to wait on the demuxer thread. Most of the changes in the player are due to the fact that we must not access the source stream directly. the demuxer thread already accesses it, and the stream stuff is not thread-safe. For timeline stuff (like ordered chapters), we enable the thread for the current segment only. We also clear its packet queue on seek, so that the remaining (unconsumed) readahead buffer doesn't waste memory. Keep in mind that insane subtitles (such as ASS typesetting muxed into mkv files) will practically disable the readahead, because the total queue size is considered when checking wheth