summaryrefslogtreecommitdiffstats
path: root/demux/demux.c
Commit message (Collapse)AuthorAgeFilesLines
* demux: update cache state when pausedwm42014-11-121-1/+11
| | | | | | | | | | | | | This was removed in commit 480f82fa. This caused the cache display not to update while paused, because the update_cache() function is never called in the thread (now I remember why the extra call was "needed"). The old implementation intentionally run update_cache() only before waiting on a mutex, with no further checks for the condition variable. In theory, this is strictly not sane, but since it was just for the retrieval of the very fuzzy cache status, it was ok. Now we want to call update_cache() outside of the mutex though - which means that in order to avoid missed wakeups, a proper condition has to be used.
* demux: report 0s readahead time as fallback in some situationswm42014-11-051-1/+5
| | | | | | | | | | If no packets are queued, the readahead time is obviously 0. If the end time is smaller than the start time, the problem is probably that audio and video start at slightly different times - report 0 in this case too. Do this because seeing "???" as readahead time is a bit annoying.
* demux: don't account known range for streams that are EOFwm42014-11-031-2/+4
| | | | | | | | | This influences the demuxer readahead display. If a stream has reached EOF, we want to ignore it for the purpose of this calculation. Note that if a stream contains no packets, it still should cause the value 0s to be displayed (unless it's EOF), because that's just the actual situation.
* demux: fix PTS comparisonwm42014-11-031-2/+4
| | | | | | | | This was relying on the fact that timestamps will always be numerically larger than MP_NOPTS_VALUE, but the trick didn't actually work for MP_PTS_MIN. Be a bit more sincere, and don't rely on this anymore. This fixes the comparison, and avoids the readahead amount displaying as "???" in some situations (since one of the values was NOPTS).
* demux: don't consider stream EOF an underrunwm42014-11-031-1/+1
| | | | | | | | | | | | In this case, we didn't find any new packets for this stream, even though we've read ahead as much as possible. (If reading ahead in this case, the "Too many packets in the demuxer packet queues" error is normally printed.) If we do consider this an underrun, handle_pause_on_low_cache() will pause and show the "buffering" state, which is not useful. Could also happen on very bad interleaving.
* player: always use demux_chapterwm42014-11-021-5/+15
| | | | | | | | | Instead of defining a separate data structure in the core. For some odd reason, demux_chapter exported the chapter time in nano-seconds. Change that to the usual timestamps (rename the field to make any code relying on this to fail compilation), and also remove the unused chapter end time.
* demux: fix demux_seek signaturewm42014-10-291-1/+1
| | | | Probably doesn't matter much.
* demux: move some seek flag sanitation to generic codewm42014-10-291-0/+13
| | | | No reason why only demux_mkv.c should do this.
* demux: seek to position 0 when loading, instead of restoring itwm42014-10-281-7/+7
| | | | | | | | | | This was originally done for DVD/BD/DVB, where the start position could be something different from 0, and seeking back to 0 would mess it up completely. Since we're not quite sure that these streams are unseekable, we can simplify this somewhat, and also make sure we also start at 0 for normal files. Helps a little bit with the following edition reloading commit.
* demux: don't access stream while lock is heldwm42014-10-241-22/+30
| | | | | | | | | | Although this is fine when the stream cache is active (which caches these and returns the result immediately), it seems cleaner not to rely on this detail. Remove the update_cache() call from demux_thread(), because it's sort of in the way. I forgot why it exists, and there's probably no good reason for it to exist anyway.
* demux: cache STREAM_CTRL_GET_BASE_FILENAMEwm42014-10-241-0/+18
| | | | | | | | It's needed for some obscure feature in combination with .rar reading. However, it's unconditionally used by the subtitle loader code, so take care of not blocking the main thread unnecessarily. (Untested.)
* player: add stream selection by ffmpeg indexwm42014-10-211-0/+1
| | | | | | | | | Apparently using the stream index is the best way to refer to the same streams across multiple FFmpeg-using programs, even if the stream index itself is rarely meaningful in any way. For Matroska, there are some possible problems, depending how FFmpeg actually adds streams. Normally they seem to match though.
* Set thread name for debuggingwm42014-10-191-0/+2
| | | | | | | | | | 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.
* demux: print a warning if stream is not seekablewm42014-10-171-2/+3
|
* demux: allow increasing filepos onlywm42014-09-031-1/+2
| | | | | | | | | | | The last demuxed file position (demuxer->filepos) is used to estimate the total playback percentage in files with possible timestamp resets (like MPEG-PS). Until know, reading from any stream set this position freely. This makes the position jump around. Fix this by allowing icnreasing file position only. Reset it on seeking. With crazy formats, this still could go wrong, but there's only so much you can do.
* demux: get rid of old wrapperwm42014-09-011-5/+0
| | | | | demux_info_get() used to be central, but was turned into a wrapper, and now there was only one caller left. Get rid of it.
* demux: eliminate redundant checkshdown2014-08-301-1/+1
| | | | | pkt can't be NULL since it's initialized from ds->head, which is checked at the beginning.
* player: slightly better cache underrun detectionwm42014-08-271-0/+1
| | | | | | | | | | | | | | | | | | Use the "native" underrun detection, instead of guessing by a low cache duration. The new underrun detection (which was added with the original commit) might have the problem that it's easy for the playloop to miss the underrun event. The underrun is actually not stored as state, so if the demuxer thread adds a new packet before the playloop happens to see the state, it's as if it never happened. On the other hand, this means that network was fast enough, so it should be just fine. Also, should it happen that we don't know the cached range (the ts_duration < 0 case), just wait until the demuxer goes idle (i.e. read_packet() decides to stop). This pretty much should affect broken or unusual files only, and there might be various things that could go wrong. But it's more robust in the normal case: this situation also happens when no packets have been read yet, and we don't want to consider this as reason to resume playback.
* demux: reset idle state on seekswm42014-08-271-2/+2
|
* player: better cache status on status linewm42014-08-271-0/+3
| | | | | | | | | | | | | | The cache percentage was useless. It showed how much of the total stream cache was in use, but since the cache size is something huge and unrelated to the bitrate or network speed, the information content of the percentage was rather low. Replace this with printing the duration of the demuxer-cached data, and the size of the stream cache in KB. I'm not completely sure about the formatting; suggestions are welcome. Note that it's not easy to know how much playback time the stream cache covers, so it's always in bytes.
* player: fix basic playbackwm42014-08-271-1/+1
| | | | | | | | | | | | | The "buffering" logic was active even if the stream cache was disabled. This is contrary to what the manpage says. It also breaks playback because of another bug: the demuxer cache is smaller than 2 seconds, and thus the resume condition never becomes true. Explicitly run this code only if the stream cache is enabled. Also, fix the underlying problem of the breakage, and resume when the demuxer thread stops reading in any case, not just on EOF. Broken by previous commit. Unbreaks playback of local files.
* player: redo how stream caching and pausing on low cache workswm42014-08-271-1/+27
| | | | | | | | | | | | | | | | | | | 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.
* demux: reduce wakeups if no cache is activewm42014-08-271-1/+5
| | | | | | | | | | | | The purpose of the unconditional pthread_cond_signal() when reading cached DEMUXER_CTRLs and STREAM_CTRLs was apparently to update the stream cache state. Otherwise, the cached fields would never be updated when the stream is e.g. paused. The same could be said about other CTRLs, but these aren't as important, since they are normally updated while reading packet data. In order to reduce wakeups, make this logic explicit.
* demux: avoid unnecessary wakeupswm42014-08-241-1/+1
| | | | | | | | | If a packet is appended to a stream, and there were already packets queued, nothing about the state changed, as far as the user (i.e. the player) is concerned. Thus no wakeup is needed. The pthread_cond_signal() call following this is not interesting - it will simply be a NOP if there are actually no waiters.
* demux: add option to control the readahead buffer by a duration valuewm42014-08-161-1/+19
| | | | | | | | | | | | | --demuxer-readahead-secs now controls how much the demuxer should readahead by an amount of seconds. This is based on the raw packet timestamps. It's not always very exact. For example, h264 in Matroska does not store any linear timestamps (only PTS values which are going to be reordered by the decoder), so this heuristic is usually off by several hundred milliseconds. The decision whether to readahead is basically OR-ed with the other --demuxer-readahead-packets options. Change the manpage descriptions to subtly convey these semantics.
* demux: remove unused functionwm42014-08-161-12/+0
|
* demux: reduce log spam if threading is disabledwm42014-08-111-3/+11
|
* demux: fix playback abort if --demuxer-thread is not usedwm42014-08-071-9/+9
| | | | | | | | | | | | Switching tracks caused cached_demux_control() to catch the command to switch tracks, even if no thread was running. Thus, the tracks were never really switched, and EOF happened immediately on playback start. Fix it by not using the cache at all if the demuxer thread is disabled. The cache code still has to be called somewhere, though, because it handles stream metadata update. Regression from today.
* demux: make track switching asynchronouswm42014-08-061-0/+21
| | | | | | | | | | | | | Because why not. This can lead to reordering of operations between seeking and track switching (happens when the demuxer wakes up after seek and track switching operations were queued). Do the track switching strictly before seeks if there is a chance of reordering, which guarantees that the seek position will always start with key frames. The reverse (seeking, then switching) does not really have any advantages. (Not sure if the player relies on this behavior.)
* demux: asynchronous seekingwm42014-07-211-9/+43
| | | | | | | | | | | | | | | | | This tells the demuxer thread that it should seek, instead of waiting until the demuxer thread is ready. Care has to be taken about the state between seek request and actual seeking: newly demuxed packets have to be discarded. We can't just flush when doing the actual seek, because the user thread could read these packets. I'm wondering if this could lead to issues due to relaxed ordering of operations. But it should be fine, since seeking influences packet reading only, and seeking is always strictly done before that. Currently, this will have no advantages; unless audio is disabled. Then seeking as well as normal playback can be non-blocking.
* demux: don't start reading if no packets were requested yetwm42014-07-201-1/+1
| | | | | | | | | | | Instead of starting to fill the packet queue if at least 1 stream is selected, wait until there is at least 1 stream had new packets requested. In theory this is cleaner, because it allows you to e.g. do a seek and then reselect streams without losing packets. Seeking marks all streams as inactive, and without this new logic, the thread would read new packets anyway right after seek.
* demux: make the cache refresh cached STREAM_CTRLswm42014-07-201-0/+1
| | | | | | | This fixes the same symptom as the previous commit, but when the demuxer thread is enabled. In this case, if nothing was read from the demuxer, the STREAM_CTRLs weren't updated either. To the player, this looked like the stream cache was never making progress, so playback was kept paused.
* demux: fix a corner case (2)wm42014-07-191-2/+4
| | | | | | | | | It can happen that read_packet() doesn't read a packet, even if it succeeds. Typically this is because a packet was read, but then thrown away, because it's not part of a selected stream. The result would be a bogus EOF condition. Fix by explicitly checking for EOF.
* demux: ensure demux_read_packet_async() always readswm42014-07-191-2/+3
| | | | | | | | | | | | | In corner cases, it might be possible that a demux_read_packet_async() call fails to make the demuxer thread to read more packets. If a packet is queued, the function will simply return a packet, without marking the stream as active. As a consequence, read_packet() might decide not to read any further packets, and the demuxer will never read a packet and wake up the playback thread. This was originally done to align it with demux_read_packet() semantics; just drop this.
* demux: fix a corner casewm42014-07-191-2/+4
| | | | | | | | | | | | demux_read_any_packet() attempts to call read_packet(), but if no stream is active, it can decide not to read anything. The function will return NULL, which implies EOF. Fix this by explicitly setting demux_stream->active if needed. Also use dequeue_packet() instead of demux_read_packet(), because it's cleaner. (Shouldn't change behavior.) Possibly fixes #938.
* demux: fix opening pipes with demux_lavfwm42014-07-181-0/+5
| | | | | | | | | | | | | | | | | | | | We told the demuxer that a pipe (if stream cache is enabled) is seekable. This is because the stream cache is technically seekable, it's just that seeking may fail at runtime if a non-cached byte range is requested. This caused libavformat to issue seeks on initialization (at least when piping mp4 youtube videos). Initialization failed completely after spamming tons of error messages. So, if an unseekable stream is cached, tell the demuxer that the file is not seekable. This gets reversed later (when printing a message about caching an unseekable stream), so the user can still try his luck by issuing a seek command. The important part is that libavformat initialization will not take code paths that will unnecessarily seek for whatever reasons. CC: @mpv-player/stable: regression from 0.3.x
* demux: fix problems with EOFwm42014-07-181-5/+14
| | | | | | | | | | | | | | | | | | | | It was easy to get into a wakeup feedback loop on EOF. The reason that EOF is complicated is that we try to retry reading when EOF is reached, in case the EOF state actually disappears (e.g. when watching a currently downloaded file). This feature is probably worthless, since in practice you have to do a seek to "unstuck" it anyway, but since the old code also did this, we want to keep this behavior for now. Avoid the feedback loop by introducing another EOF flag (last_eof), that contains the actual previous EOF state, and is not overwritten when retrying reading. Wakeup is skipped if the EOF state didn't change. Also, actually call the wakeup callback when EOF is detected. The line that adds "ds->active = false;" actually does nothing, but in theory it's cleaner.
* demux: add function to read packets asychronouslywm42014-07-181-14/+50
|
* demux: fix debug log outputwm42014-07-171-1/+1
| | | | It printed the PTS instead of the DTS.
* demux: add a demuxer threadwm42014-07-161-162/+548
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/+2
| | | | | | This reverts commit 4b93210e0c244a65ef10a566abed2ad25ecaf9a1. *shrug*
* Remove DVD and Bluray supportwm42014-07-141-2/+0
| | | | It never worked well. Just remux your DVD and BD images to mkv.
* demux: remove accurate_seek fieldwm42014-07-081-1/+0
| | | | It's unused now. (Only the dvd code used it until recently.)
* demux: print initial metadatawm42014-07-071-0/+1
| | | | | This was accidentally broken in 7e209185, and metadata was printed only when it changed.
* Remove stream_pts stuffwm42014-07-061-3/+0
| | | | | This was used by DVD/BD, but its usage was removed with one of the previous commits.
* demux: fix a corner case related to demux_discwm42014-07-061-5/+8
| | | | | | It can happen that demux_fill_buffer() adds more than 1 packet, and then the packets would add up. Affects demux_disc.c only (nothing else uses this function).
* dvd: fix first subtitle with delayed subtitle streamswm42014-07-061-0/+1
| | | | | | This was accidentally broken with moving the DVD code to demux_disc.c. Also remove an abort() call meant for debugging.
* demux: minor simplificationwm42014-07-061-1/+1
| | | | Oops, should have been part of commit 37085788.
* demux: minor simplification to internal APIwm42014-07-051-19/+11
| | | | Also some other unrelated minor changes.
* dvd: move angle switching codewm42014-07-051-39/+0
| | | | | No need to provide a "nice" API for it; just do this stuff directly in the command code.
* dvd, bluray, cdda: add demux_disc containing all related hackswm42014-07-051-71/+15
| | | | | | | | | | | | 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: set filepos field when dequeuing a packetwm42014-07-051-3/+2
| | | | Otherwise the position can be too far ahead.
* demux: cosmetics: minimize codewm42014-07-051-16/+3
|
* demux: make start time a simple fieldwm42014-07-051-10/+0
| | | | Simpler, especially for later changes.
* demux, stream: change metadata notificationwm42014-07-051-21/+12
| | | | | | | | | | | | (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.
* demux: make replaygain per-trackwm42014-07-051-3/+6
| | | | | | It's unlikely that files with multiple audio tracks and with replaygain actually happen, but this change might help avoid minor corner cases with later changes.
* demux: move packet functions to a separate source filewm42014-07-051-100/+0
|
* demux: move packet list functionswm42014-07-051-66/