summaryrefslogtreecommitdiffstats
path: root/stream/cache.c
Commit message (Collapse)AuthorAgeFilesLines
* 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
| | | | No functional changes yet.
* cache: fix typo in commentwm42014-04-091-1/+1
|
* cache: always update cached controls after running a stream controlwm42014-04-091-0/+1
| | | | | | | Seems like a good idea. One possible bad effect would be slowing down uncached controls, but they're already slow. The good thing is that many controls make intrusive changes to the stream (at least controls which do write accesses), so the cached parameters should be updated.
* stream: remove old chapter handling codewm42014-03-251-1/+0
| | | | | | | | Stream-level chapters (like DVD etc.) did potentially not have timestamps for each chapter, so STREAM_CTRL_SEEK_TO_CHAPTER and STREAM_CTRL_GET_CURRENT_CHAPTER were needed to navigate chapters. We've switched everything to use timestamps and that seems to work, so we can simplify the code and remove this old mechanism.
* command: set 'media-title' property for bluray disc with meta-dataxylosper2014-03-131-7/+7
|
* cache: cache DVD volume IDwm42014-02-231-0/+13
| | | | | Since this might be queried every frame or so, it's important not to stall the cache by doing a synchronous stream_control().
* cache: refuse to seek outside of cache boundarieswm42014-01-311-4/+18
| | | | | | | | | | | | | | | | | Note that this still happens in the stream level, so we can't have nice highlevel behavior restricting seeking. Instead, if a seek leads to the demuxer requesting data outside of the cached range, the seek will simply fail. This might confuse the demuxer, and the resulting behavior is not necessarily useful. Note that this also doesn't try to skip data on a forward seek. This would just freeze the stream with slow unseekable streams. One nice thing is that stream.h has a separate function for merely skipping data (separate from seeking forward), which is pretty useful in this case: we want skipping of data to work, even if we reject seeking forward by skipping data as too expensive. This probably is or will be useful for demux_mkv.c.
* cache: remove debug codewm42014-01-171-1/+0
| | | | | | This was accidentally committed. <rcombs> `mp_sleep_us(100000);` <-- are you drunk?
* cache: reduce message spamwm42014-01-161-7/+16
| | | | Output only 1 message every 5 seconds at most.
* stream: mp_msg conversionswm42013-12-211-22/+21
| | | | We also drop some slave mode stuff from stream_vcd.
* Split mpvcore/ into common/, misc/, bstr/wm42013-12-171-2/+2
|
* Replace mp_tmsg, mp_dbg -> mp_msg, remove mp_gtext(), remove set_osd_tmsgwm42013-12-161-2/+2
| | | | | | | | | The tmsg stuff was for the internal gettext() based translation system, which nobody ever attempted to use and thus was removed. mp_gtext() and set_osd_tmsg() were also for this. mp_dbg was once enabled in debug mode only, but since we have log level for enabling debug messages, it seems utterly useless.
* cache: add a way to explicitly resume cachewm42013-12-141-0/+4
|
* cache: try harder on EOFwm42013-12-141-5/+11
| | | | | | | | | | | | | EOF is a special case. Normally, the reader will block until the cache thread has new data. Obviously we don't want to do this on EOF, because we'd potentially block forever. On the other hand, EOF will put the cache thread into a waiting state, so if EOF recovers, this will happen at a "later" point. This is bad if there is some kind of external event that ends the EOF condition. In this case, a steram_read() call would still return EOF. Make it so that the reader waits at least for one iteration of the cache trying to rad a new block. Also adjust some debug messages to not print file positions in hex.
* Add prelimimary (basic, possibly broken) dvdnav supportwm42013-12-121-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | This readds a more or less completely new dvdnav implementation, though it's based on the code from before commit 41fbcee. Note that this is rather basic, and might be broken or not quite usable in many cases. Most importantly, navigation highlights are not correctly implemented. This would require changes in the FFmpeg dvdsub decoder (to apply a different internal CLUT), so supporting it is not really possible right now. And in fact, I don't think I ever want to support it, because it's a very small gain for a lot of work. Instead, mpv will display fake highlights, which are an approximate bounding box around the real highlights. Some things like mouse input or switching audio/subtitles stream using the dvdnav VM are not supported. Might be quite fragile on transitions: if dvdnav initiates a transition, and doesn't give us enough mpeg data to initialize video playback, the player will just quit. This is added only because some users seem to want it. I don't intend to make mpv a good DVD player, so the very basic minimum will have to do. How about you just convert your DVD to proper video files?
* stream: split out pthread helper functionwm42013-11-171-26/+3
| | | | Also split the function itself into 3.
* core: move contents to mpvcore (2/2)Stefano Pigozzi2013-08-061-2/+2
| | | | Followup commit. Fixes all the files references.
* cache: fix time check for printing warningwm42013-07-201-1/+1
| | | | | This actually waited 2 seconds, because CACHE_WAIT_TIME happened to be 0.5.
* w32: silence some warningsJames Ross-Gowan2013-07-131-1/+1
|
* cache: fix compilation without posix timersStefano Pigozzi2013-07-081-0/+1
| | | | | | This is a regression caused by 854303a. This commit removed the include of `sys/time.h` which was included in `cache.c` through a chain of recurvive includes.
* core: update metadata during playback, allow streams to export metadatawm42013-07-021-1/+22
| | | | | | | STREAM_CTRL_GET_METADATA will be used to poll for streamcast metadata. Also add DEMUXER_CTRL_UPDATE_INFO, which could in theory be used by demux_lavf.c. (Unfortunately, libavformat is too crappy to read metadata mid-stream for mp3 or ogg, so we don't implement it.)
* cache: fix per-block metadata memory leakwm42013-07-021-0/+1
|
* cache: cache number of chapterswm42013-06-241-0/+10
| | | | | | | | | Querying this caused the cache to block and wait. Some parts of the frontend (like progress bar) call this very often, so cache performance was ruined in these cases. Also print a message in -v mode when the cache is blocked for a STREAM_CTRL. This should make debugging similar issues easier.
* cache: fix stream_pts cachingwm42013-06-181-20/+20
| | | | | | | | | | | | | | | | | | | | | | | | Or rather, keep hacking it until it somehow works. The problem here was that trying to avoid calling STREAM_CTRL_GET_CURRENT_TIME too often didn't really work, so the cache sometimes returned incorrect times. Also try to avoid the situation that looking up the time with an advanced read position doesn't really work, as well as when trying to look it up when EOF or cache end has been reached. In that case we have read_filepos == max_filepos, which is "outside" of the cache, but querying the time is still valid. Should also fix the issue that demuxing streams with demux_lavf and if STREAM_CTRL_GET_CURRENT_TIME is not supported messed up the reported playback position. This stuff is still not sane, but the way the player tries to fix the playback time and how the DVD/BD stream inputs return the current time based on the current byte position isn't sane to begin with. So, let's leave it at bad hacks. The two changes that touch s->eof are unrelated and basically of cosmetic nature (separate commit would be too noisy.)
* cache: actually use time instead of retry count for slow cache warningwm42013-06-181-9/+11
| | | | | There's actually no reason to maintain a retry count, and this is more robust against spurious wakeups.
* cache: fix build on OSX (again)wm42013-06-161-0/+7
| | | | | | | | | | | | | OSX doesn't support the POSIX API we were using. We check for _POSIX_TIMERS. 0 or -1 means unsupported. See: http://pubs.opengroup.org/onlinepubs/009696699/functions/clock_getres.html http://pubs.opengroup.org/onlinepubs/009696699/basedefs/unistd.h.html The workaround of using gettimeofday() is suggested by Apple: https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man3/pthread_cond_timedwait.3.html Thanks to AStorm for providing help here.
* cache: fix compilation on Libavwm42013-06-161-1/+8
| | | | Appears Libav doesn't have av_clip64(). So implement our own.
* cache: use correct header for clock_gettimewm42013-06-161-0/+1
| | | | Fixes compilation on OSX.
*