summaryrefslogtreecommitdiffstats
path: root/demux
Commit message (Collapse)AuthorAgeFilesLines
* 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.)
* Improve setting AVOptionswm42014-08-021-14/+5
| | | | | | | | Use OPT_KEYVALUELIST() for all places where AVOptions are directly set from mpv command line options. This allows escaping values, better diagnostics (also no more "pal"), and somehow reduces code size. Remove the old crappy option parser (av_opts.c).
* demux_lavf: don't consider EAGAIN as EOF conditionwm42014-07-301-2/+3
| | | | | | | | | | This happens apparently randomly with rtmp:// and after seeks. This eventually leads to audio decoding returning an EOF status, which basically disables audio sync. This will lead to audio desync, even if audio decoding later "recovers" when the demuxer actually returns audio packets. Hack-fix this by special-casing EAGAIN.
* stream: hack-fix rtmp-level seekingwm42014-07-301-4/+7
| | | | | | | | | | | | | 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_mf: allow seeking past the endwm42014-07-301-1/+1
| | | | How's this for a corner case.
* demux: fix timestamp type for seek callswm42014-07-217-8/+8
| | | | | mpv/mplayer2/MPlayer use double for timestamps, but the demuxer API used float.
* 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-182-14/+51
|
* dvd, bd: fix A/V syncwm42014-07-181-30/+29
| | | | | Slightly less robust, but simpler, and usually guarantees that audio and video are properly in sync.
* demux: fix debug log outputwm42014-07-171-1/+1
| | | | It printed the PTS instead of the DTS.
* demux: drop some unused definitionswm42014-07-172-3/+0
|
* demux_lavf: reverse rotation direction with new APIwm42014-07-171-1/+1
| | | | | | | The old FFmpeg API and the new Libav API disagree about mp4 display rotation direction. Well, whatever, fix it trial-and-error-style. CC: @mpv-player/stable: add
* demux: add a demuxer threadwm42014-07-165-178/+596
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-152-0/+349
| | | | | | This reverts commit 4b93210e0c244a65ef10a566abed2ad25ecaf9a1. *shrug*
* Remove DVD and Bluray supportwm42014-07-142-349/+0
| | | | It never worked well. Just remux your DVD and BD images to mkv.
* demux_lavf: don't let metadata update mess up ogm playbackwm42014-07-141-1/+4
| | | | | | For OGG audio files, we usually merge the per-stream metadata back to the file-global metadata. Don't do that for OGM, because with OGM most metadata is actually per-stream.
* dvdnav: fix time display when starting in the middle of the DVDwm42014-07-131-0/+5
| | | | | | | | | | | | | | | | | | | libdvdnav can actually jump into the middle of the DVD (e.g. scene selection menus do that). Then time display is incorrect: we start from 0, even though playback time is somewhere else. This really matters when seeking. If the display time mismatches, a small relative seek will apparently jump to the beginning of the movie. Fix this by initializing the PTS stuff on opening. We have to do this after some small amount of data has been read from the stream (because libdvdnav is crap and doesn't always update the time between seeks and the first read; also see STREAM_CTRL_GET_CURRENT_TIME remarks in cache.c; although this was not observed when testing with scene selection menus). On the other hand, we want to do it before opening the demuxer, because that will read large amounts of data and likely will change the stream position. Also see commit 49813670.
* dvd: potentially fix video aspect ratiowm42014-07-121-1/+1
| | | | | This overwrote the source stream header, instead of the stream header exported to the decoder.
* build: include <strings.h> for strcasecmp()wm42014-07-103-2/+4
| | | | | | | It happens to work without strings.h on glibc or with _GNU_SOURCE, but the POSIX standard requires including <strings.h>. Hopefully fixes OSX build.
* demux: remove accurate_seek fieldwm42014-07-082-4/+0
| | | | It's unused now. (Only the dvd code used it until recently.)
* demux_disc: flush slave demuxer packet queue on resyncwm42014-07-071-0/+3
| | | | | | Technically needed, but not strictly. It seems it works without in practice, because demux_lavf.c reads exactly one packet for fill_buffer call, so there are never packets queued.
* cache, dvd, bluray: simplify stream time handlingwm42014-07-071-4/+0
| | | | | | | | | | | | | | | | | | 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).
* 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-064-7/+0
| | | | | This was used by DVD/BD, but its usage was removed with one of the previous commits.
* dvd, bd: enable precise seekingwm42014-07-061-4/+1
| | | | | | | | | | | | | | | | | | | This should work now, at least kind of. Note that actual success depends on the behavior of the underlying lib{dvd{nav,read},bluray} implementation, which could go very wrong. In the worst case, it could happen that the underlying implementation seeks a long time before the seek target time. In this case, the player will just decode video until the target time is reached, even if that requires e.g. decoding 30 mintues of video before refreshing. In the not-so-bad but still bad case, it would just miss the seek target, and seek past it. In my tests, it works mostly ok, though. Seeking backwards usually fails, unless something like --hr-seek-demuxer-offset=1 is used (this makes it seek to 1 second before the target, which may or may not be enough to compensate for the DVD/BD imprecision).
* dvd, bluray: handle playback display time handling differentlywm42014-07-061-12/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a pretty big change. Instead of doing a half-hearted passthrough of the playback timestamp, we attempt to rewrite the raw MPEG timestamps such that they match with the playback time. We add the offset between raw start timestamp and playback time to the packet timestamps. This is the easy part; but the problem is with timestamp resets. We simply detect timestamp discontinuities by checking whether they are more than 500ms apart (large enough for all video faster than 2 FPS and audio with reasonable framesizes/samplerates), and adjust the timestamp offset accordingly. This should work pretty well. There may be some problems with subtitles. If the first packet after a timestamp reset is a subtitle instead of video, it will fail. Also, selecting multiple audio or video streams won't work (but mpv doesn't allow selecting several anyway). Trying to demux subtitles with no video stream enabled will probably fail. Untested with Bluray, because I have no Bluray sample. Background: libdvdnav/libdvdread/libbluray make this relatively hard. They return a raw MPEG (PS/TS) byte stream, and additionally to that provide a function to retrieve the current "playback" time. The playback time is what should be displayed to the user, while the MPEG timestamps can be completely different. Even worse, the MPEG timestamps can reset. Since we use the libavformat demuxer (instead of parsing the MPEG packets in the DVD/BD code), it's hard to associate between these timestamps. As a result, the time display is special cased in the playloop, and of low quality (updates only all 1 or 2 seconds, sometimes is incorrect). The fact that the stream cache can be between demuxer and the stream source makes things worse. All the libs seem to provide an event that tells whether timestamps are resetting. But since this signalling is byte based, it's hard to connect it to the demuxed MPEG packets. It might be possible to create some sort of table mapping file positions to discontinuities and new timestamps. (For simplicity, this table could be 2 entries large, sufficient to catch all discontinuities if the distance between them is larger than the total buffering.)
* 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-063-1/+5
| | | | | | 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-066-11/+8
| | | | Oops, should have been part of commit 37085788.
* tv: move demuxer parts to separate filewm42014-07-051-0/+251
| | | | | Now all demuxer implementations (at least demuxer API-wise) are in the demux directory.
* demux: minor simplification to internal APIwm42014-07-058-31/+21
| | | | Also some other unrelated minor changes.
* dvd: move angle switching codewm42014-07-052-46/+0
| | | | | No need to provide a "nice" API for it; just do this stuff directly in the command code.
* dvd: flush buffers properly on seekwm42014-07-051-3/+4
| | | | | | | | | | | Suggested by tholin on github issue #882. This is not entirely clean, but the fields we're accessing might be considered internal to libavformat. On the other hand, existence of the fields is guaranteed by the ABI, and nothing in the libavformat doxygen suggestes they're not allowed to be accessed. CC: @mpv-player/stable
* dvd, bluray, cdda: add demux_disc containing all related hackswm42014-07-054-88/+295
| | | | | | | | | | | | 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-053-17/+8
| | | | Simpler, especially for later changes.
* demux, stream: change metadata notificationwm42014-07-053-22/+22
| | | | | | | | | | | | (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-054-8/+10
| | | | | | 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-054-108/+133
|
* demux: move packet list functionswm42014-07-053-73/+49
| | | | Move them to the only place where they are used, demux_subreader.c.
* demux_lavf: for now, ignore the new libavformat image demuxerswm42014-07-051-0/+3
| | | | | | | | | | | | Recently, libavformat added demuxers to open image files like normal demuxers. This is a good thing, but for now they interfere with the operation of demux_mf. Add them to the blacklist until there is a proper solution. (The list doesn't contain _all_ recognized image formats, just those that might interfere with demux_mf.) CC: @mpv-player/stable
* demux_lavf: support OTF fonts in Matroskawm42014-07-051-3/+10
| | | | Apparently it's FFmpeg only.
* demux_lavf: don't dump transport stream programswm42014-07-051-13/+0
| | | | Probably useless.
* demux_lavf: cleanup debug outputwm42014-07-051-19/+10
| | | | Remove unnecessary prefix, remove some messages.
* demux_lavf: fix read_seek return valuewm42014-07-051-3/+1
| | | | | | | This returned a stream error value directly to libavformat, which can't make sense. For example STREAM_ERROR (0) means success in libavformat error codes. (The meaning of the libavformat read_seek return value is underdocumented too.)
* demux_mkv: cosmeticswm42014-07-051-45/+27
|
* demux: drop AVI special codewm42014-07-021-8/+0
| | | | | | | I'm pretty sure libavformat does this automatically, and we don't have other demuxers where this could happen. Still, slightly "risky" - so let's see.
* demux_mkv: minor improvement to overflow checkwm42014-07-021-2/+3
| | | | CC: @mpv-player/stable
*