summaryrefslogtreecommitdiffstats
path: root/stream/cache.c
Commit message (Collapse)AuthorAgeFilesLines
* 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 whether the minimum queue size was reached.
* Revert "Remove DVD and Bluray support"wm42014-07-151-0/+30
| | | | | | This reverts commit 4b93210e0c244a65ef10a566abed2ad25ecaf9a1. *shrug*
* Remove DVD and Bluray supportwm42014-07-141-30/+0
| | | | It never worked well. Just remux your DVD and BD images to mkv.
* cache, dvd, bluray: simplify stream time handlingwm42014-07-071-42/+16
| | | | | | | | | | | | | | | | | | We used a complicated and approximate method to cache the stream timestamp, which is basically per-byte. (To reduce overhead, it was only cached per 8KB-block, so it was approximate.) Simplify this, and read/keep the timestamp only on discontinuities. This is when demux_disc.c actually needs the timestamp. Note that caching is currently disabled for dvdnav, but we still read the timestamp only after some data is read. libdvdread behaves well, but I don't know about libbluray, and the previous code also read the timestamp only after reading data, so try to keep it safe. Also drop the start_time offset. It wouldn't be correct anymore if used with the cache, and the idea behind it wasn't very sane either (making the player to offset the initial playback time to 0).
* stream: remove now unused STREAM_CTRL_GET_START_TIMEwm42014-07-061-9/+0
| | | | demux_disc.c takes care of this now.
* dvd, bluray, cdda: add demux_disc containing all related hackswm42014-07-051-6/+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.
* demux, stream: change metadata notificationwm42014-07-051-14/+9
| | | | | | | | | | | | (Again.) This time, we simply make it event-based, as it should be. This is done for both demuxer metadata and stream metadata. For some ogg-over-icy streams, 2 updates are reported on stream start. This is because libavformat reports an update right on start, while including the same info in the "static" metadata. I don't know if that's a bug or a feature.
* cache: clear DVD timestampswm42014-07-021-0/+3
| | | | | | | | | | | | When resizing the cache, the buffer for the DVD timestamps is initialized with 0. This causes the player to always return playback position 0 with any file format (not just DVD), and also makes all relative seeks relative to position 0. Fix this by clearing the timestamps explicitly. Closes #899. CC: @mpv-player/stable
* cache: avoid race condition between cache wakeup and idlingwm42014-06-161-0/+1
| | | | | | | | | | When the reader is out of data, it tries to wake up the cache thread to get more data. In theory, there's a small race condition, which could cause the cache to miss the wakeup and idle before reaction. Most certainly didn't cause real issues, because even if this extremely unlikely race condition happens, the cache won't idle for longer than 1 second (the hardcoded cache idle time).
* cache: print cache size only in verbose modewm42014-06-121-2/+2
| | | | Seems pretty useless in general, so this reduces output noise.
* stream/cache: handle failure of seeking underlying streamwm42014-06-051-1/+4
| | | | | | | | | | | | This could for example happen when serving an incomplete file from http, and the demuxer tries reading data from the end of the file when opening it (e.g. with avi). Seeking past EOF fails with http, so the file could never be opened, and the cache would get stuck trying to seek to the position. We can't really make the cache report seek failure directly (it would suck for various reasons), so just make the cache report EOF if seeking fails.
* stream: don't use end_poswm42014-05-241-6/+10
| | | | | | | | | | | | | | | | | | | 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.
* cache: be silent if no initial fill is requestedwm42014-05-221-1/+3
| | | | Hides the "Cache fill:" message with default settings.
* cache: redo options and default settingswm42014-05-201-5/+7
| | | | | | | | | | | | Some options change from percentages to number of kilobytes; there are no cache options using percentages anymore. Raise the default values. The cache is now 25000 kilobytes, although if your connection is slow enough, the maximum is probably never reached. (Although all the memory will still be used as seekback-cache.) Remove the separate --audio-file-cache option, and use the cache default settings for it.
* threads: use mpv time for mpthread_cond_timedwait wrapperwm42014-05-181-2/+2
| | | | | | Use the time as returned by mp_time_us() for mpthread_cond_timedwait(), instead of calculating the struct timespec value based on a timeout. This (probably) makes it easier to wait for a specific deadline.
* stream: remove interrupt callback global variableswm42014-04-251-2/+2
| | | | | | | | | | | | This used global variables for the asynchronous interrupt callback. Pick the simple and dumb solution and stuff the callback into mpv_global. Do this because interrupt checking should also work in the connect phase, and currently stream creation equates connecting. Ideally, this would be passed to the stream on creation instead, or connecting would be separated from creation. But since I don't know yet which is better, and since moving stream/demuxer into their own thread is something that will happen later, go with the mpv_global solution.
* cache: remove redundant log prefixwm42014-04-231-1/+1
|
* threads: fix function namewm42014-04-231-2/+2
| | | | Closer to the corresponding standard function pthread_cond_timedwait.
* stream_dvd, cache: hack seeking with --cache + dvd:// back into workingwm42014-04-091-1/+1
| | | | | | | | | | | | | | | | | | | This was broken at some unknown point (even before the recent cache changes). There are several problems: - stream_dvd returning a random stream position, confusing the cache layer (cached data and stream data lost their 1:1 corrospondence by position) - this also confused the mechanism added with commit a9671524, which basically triggered random seeking (although this was not the only problem) - demux_lavf requesting seeks in the stream layer, which resulted in seeks in the cache or the real stream Fix this by completely removing byte-based seeking from stream_dvd. This already works fine for stream_dvdnav and stream_bluray. Now all these streams do time-based seeks, and pretend to be infinite streams of data, and the rest of the player simply doesn't care about the stream byte positions.
* cache: fix description of the offset fieldwm42014-04-091-1/+3
| | | | This field sure is a bit strange. I hope the description is correct now.
* cache: change a define to an enumwm42014-04-091-3/+3
| | | | More consistent.
* cache: fix checks/output on initializationwm42014-04-091-8/+3
| | | | | | | resize_cache() checks the size itself and clamps the size to the valid range if necessary, so we don't need these checks. In fact, the checks are different. Also, output the cache size after clamping, instead of before.
* cache: simplifywm42014-04-091-25/+17
| | | | | | | Merge the cache_read function into cache_fill_buffer, since there's not much reason to keep them separate. Also, simply call read_buffer() to see if there's any readable data, instead of checking for the condition manually.
* cache: allow resizing at runtimewm42014-04-091-21/+77
| | | | | | | | | | | The only tricky part is keeping the cache contents, which is made simple by allocating the new cache while still keeping the old cache around, and then copying the old data. To explain the "Don't use this when playing DVD or Bluray." comment: the cache also associates timestamps to blocks of bytes, but throws away the timestamps on seek. Thus you will experience strange behavior after resizing the cache until the old cached region is exhausted.
* cache: minor simplificationwm42014-04-091-11/+7
| | | | | | | | The only difference is that the MP_DBG message is not printed anymore if the current user read position is outside of the current cache range. (In order to handle seek_limit==0 gracefully in the normal case of linear reading, change the comparison from ">=" to ">".)
* cache: adjust stream position if necessarywm42014-04-091-1/+6
| | | | | | | | | Until now, this could never happen, because new data was simply always appended to the end of the cache. But for making stream cache resizing easier, doing it this way seems advantageous. It also makes it harder to make the internal state inconsistent. (Before this change it could happen that cache and stream position went out of sync if the read position was adjusted "inappropriately".)
* cache: no short reads in read_bufferwm42014-04-091-16/+21
| | | | | | | Until now, cache_read() (which calls read_buffer()) could return short reads. This was a simplification allowed by the stream interface. But for cache resizing, it will be more practical to make read_buffer() do a full read.
* cache: move ringbuffer read into a separate functionwm42014-04-091-17/+32