summaryrefslogtreecommitdiffstats
path: root/demux
Commit message (Collapse)AuthorAgeFilesLines
* demux_mkv: ebml: turn an int shift into int64wm42017-01-091-1/+1
| | | | | | | | | This was probably the intention all along. But I honestly have no idea what this code even does. Due to what ebml_read_vlen_int() is used for, this is unlikely to have mattered anyway as it rarely/never reads huge values. Which is probably why this has worked for over a decade.
* demux_mkv: trust keyframe flags for TrueHDwm42016-12-201-1/+2
| | | | | | | | | | TrueHD is a fucked up audio codec with extremely small frame sizes. Some of these frames start with full headers, which are usually marked as keyframes, and from which decoding can be started (or at least that's what you'd expect). So for such tracks we should probably trust the keyframe flags. Doesn't really improve seek behavior, though.
* demux_mkv: fix seeking in some broken fileswm42016-12-191-1/+16
| | | | | | | | | | | | | | | | | | | | | | Some files have audio tracks with packets that do not have a keyframe flag set at all. I don't think there's any audio codec which actually needs keyframe flags, so always assume an audio packet is a keyframe (which, in Matroska terminology, means it can start decoding from that packet). The file in question had these set: | + Multiplexing application: Lavf57.56.100 at 313 | + Writing application: Lavf57.56.100 at 329 Garbage produced by garbage... There are other such files produced by mkvmerge, though. It's not perfectly sure whether these have been produced by FFmpeg as well (mkvmerge often trusts the information in the source file, even if it's wrong - so other samples could have been remuxed from FFmpeg). Fixes #3920.
* Remove compatibility thingswm42016-12-072-28/+2
| | | | | | Possible with bumped FFmpeg/Libav. These are just the simple cases.
* demux, stream: add option to prevent opening referenced fileswm42016-12-049-3/+39
| | | | Quite irresponsibly hacked together. Sue me.
* demux_lavf: blacklist ffm (ffserver)wm42016-12-041-0/+2
|
* demux_mkv: distinguish mp2 and mp3wm42016-11-231-2/+4
| | | | | demux_mkv.c has returned mp3 for mp2 since the initial commit. Normally not a problem.
* demux_timeline: always signal new segment after a seekwm42016-11-091-3/+1
| | | | | | | | This is needed to put the decoders into the correct state. In particular, decoders will not initialize the current segment without this flag. The intention of not setting the flag for seeks within the segments were to avoid costly decoder reinits, but it seems this is better handled explicitly in the decoder wrappers.
* demux: expose demuxer colorimetry metadata to playerNiklas Haas2016-11-082-0/+3
| | | | | | Implementation-wise, the values from the demuxer/codec header are merged with the values from the decoder such that the former are used only where the latter are unknown (0/auto).
* demux_mkv: parse colorimetry metadataNiklas Haas2016-11-081-0/+39
| | | | | | | | | Matroska actually has lots of colorimetry metadata that video tracks can use, including mastering metadata (HDR signal peak) etc. This commit adds the EBML definitions and parses the most basic fields. Note that nothing uses these fields yet, this commit is just adding the necessary parsing and infrastructure.
* demux: improve buffer estimation in a corner casewm42016-11-011-3/+4
| | | | | | | | | | | | | This deals with the estimation of buffered packets, which is used mostly for display, but also things like pausing on low buffer levels. If a stream is fully EOF (no more packets), we don't want to include it in the total buffer amount. This also means we should make ds->eof less flaky and more stable, so don't reset it in ds_get_packets() (this function reset ds->eof just to retrigger a packet read attempt - we can have this slightly simpler). This somewhat fixes buffering display when e.g. issuing a refresh seek after re-enabling audio/video when playing with subtitles only.
* demux_mkv: fix ordered chapter sources with ordered editionsUoti Urpala2016-10-222-13/+18
| | | | | | | | | | | | | | | | | | | | | | | | Commit f72a900892 (and others) added support for ordered editions that recursively refer to other ordered editions. However, this recursion code incorrectly activated if the source files had ordered chapters even if the main file only wanted to use them as raw video, resulting in broken timeline info overall. Ordered chapters can specify a ChapterSegmentEditionUID value if they want to use a specific edition from a source file. Otherwise the source is supposed to be used as a raw video file. The code checked demuxer->matroska_data.num_ordered_chapters for an opened source file to see whether it was using a recursive ordered edition, but demux_mkv could enable a default ordered edition for the file using the normal playback rules even if the main file had not specified any ChapterSegmentEditionUID. Thus this incorrectly enabled recursion if a source file had a default edition using ordered chapters. Check demuxer->matroska_data.uid.edition instead, and ensure it's never set if a file is opened without ChapterSegmentEditionUID. Also fix what seems like a memory leak in demux_mkv.c. Signed-off-by: wm4 <wm4@nowhere>
* demux_mkv: don't recursively resolve timeline for opened reference fileswm42016-10-223-10/+14
| | | | Instead, resolve all references and so on in the top-level timeline.
* demux: don't try to refresh unselected streamswm42016-10-211-1/+1
| | | | | This could cause nonsensical queue overflow warnings, but was otherwise probably harmless.
* demux_lavf: set title on hearing and visual impaired tracksAman Gupta2016-10-201-0/+4
|
* demux_lavf: don't accidentally enable edit list crap on Libavwm42016-10-181-1/+2
| | | | You really don't get a break from all the multiple bullshit.
* demux_lavf: "support" mov edit lists and log errors if usedwm42016-10-181-0/+4
| | | | | | | | | | | | | | | | | | | | | | | FFmpeg recently got "support" for mov edit lists. This is a terrible hack that will fail completely at least with some decoders (in particular wrappers for hardware decoding might be affected). As such it makes no point to pretend they are supported, even if we assume that the "intended" functionality works, that there are no implementation bugs (good luck with all that messy code added to the already huge mov demuxer), and that it covers enough of the mov edit list feature to be of value. So log an error if the FFmpeg code for mov edit lists appears to be active - AV_PKT_FLAG_DISCARD is used only for "clipping" edit list segments on non-key frame boundaries. In the first place, FFmpeg committed this only because Google wanted it in, and patch review did not even pick up obvious issues. (Just look how there was no lavc version bump when AV_PKT_FLAG_DISCARD was added.) We still pass the new packet flag to the decoders (av_common.c change), which means we "support" FFmpeg's edit list code now. (Until it breaks due to FFmpeg not caring about all the details.)
* player: fix instant subtitle refresh on track switcheswm42016-09-241-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | When switching a subtitle track, the subtitle wasn't necessarily updated, especially when playback was paused. Some awfully subtle and complex interactions here. First off (and not so subtle), the subtitle decoder will read packets only on explicit update_subtitles() calls, which, if video is active, is called only when a new video frame is shown. (A simply video frame redraw doesn't trigger this.) So call it explicitly. But only if playback is "initialized", i.e. not when it does initial track selection and decoder init, during which no packets should be read. The second issue is that the demuxer thread simply will not read new packets just because a track was switched, especially if playback is paused. That's fine, but if a refresh seek is to be done, it really should do this. So if there's either 1. a refresh seek requested, or 2. a refresh seek ongoing, then read more packets. Note that it's entirely possible that we overflow the packet queue with this in unpredicated weird corner cases, but the queue limit will still be enforced, so this shouldn't make the situation worse.
* stream, demux, config: remove some dead/unneeded option-related codewm42016-09-091-1/+0
| | | | | | | | | | This has all been made unnecessary recently. The change not to copy the global option struct in particular can be made because now nothing accesses the global options anymore in the demux and stream layers. Some code that was accidentally added/changed in commit 5e30e7a0 is also removed, because it was simply committed accidentally, and was never used.
* tv: remove weird option parsing stuffwm42016-09-091-6/+14
| | | | Mostly untested.
* demux: do not access global optionswm42016-09-067-66/+137
| | | | | | | | | | | | | | | | | Don't access MPOpts directly, and always use the new m_config.h functions for accessing them in a thread-safe way. The goal is eventually removing the mpv_global.opts field, and the demuxer/stream-layer specific hack that copies MPOpts to deal with thread-safety issues. This moves around a lot of options. For one, we often change the physical storage location of options to make them more localized, but these changes are not user-visible (or should not be). For shared options on the other hand it's better to do messy direct access, which is worrying as in that somehow renaming an option or changing its type would break code reading them manually, without causing a compilation error.
* input, demux_tv: remove some older option access methodswm42016-09-061-2/+2
|
* demux_mkv: don't crash if --ordered-chapters-files failswm42016-09-061-1/+1
| | | | It just crashed.
* demux: close underlying stream if it's fully read anywaywm42016-08-263-3/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is for text subtitles. libavformat currently always reads text subtitles completely on init. This means the underlying stream is useless and will consume resources for various reasons (network connection, file handles, cache memory). Take care of this by closing the underlying stream if we think the demuxer has read everything. Since libavformat doesn't export whether it did (or whether it may access the stream again in the future), we rely on a whitelist. Also, instead of setting the stream to NULL or so, set it to an empty dummy stream. This way we don't have to litter the code with NULL checks. demux_lavf.c needs extra changes, because it tries to do clever things for the sake of subtitle charset conversion. The main reason we keep the demuxer etc. open is because we fell for libavformat being so generic, and we tried to remove corresponding special-cases in the higher-level player code. Some of this is forced due to ass/srt mkv/mp4 demuxing being very similar to external text files. In the future it might be better to do this in a more straight-forward way, such as reading text subtitles into libass and then discarding the demuxer entirely, but for aforementioned reasons this could be more of a mess than the solution introduced by this commit. Probably fixes #3456.
* player: don't directly access demuxer->streamwm42016-08-262-0/+3
| | | | | | | | | | Cleaner and makes it easier to change the underlying stream. mp_property_stream_capture() still directly accesses it directly via demux_run_on_thread(). This is evil, but still somewhat sane and is not getting into the way here. Not sure if I got all field accesses.
* demux: demote packet queue overflow to a warningwm42016-08-221-3/+3
| | | | | | | | | It doesn't necessarily have to mean anything bad. We're still too lazy to provide any more detailed information (e.g. whether this happened to likely bad interleaving, excessive amount of packets like with some ASS subs, or that the readahead user option is limitted by the packet queue size).
* demux: change fps field to doublewm42016-08-191-1/+1
| | | | Because why not.
* video/audio: always provide "proper" timestamps to libavcodecwm42016-08-194-0/+11
| | | | | | | | | | | | | | | | | | | Instead of passing through double float timestamps opaquely, pass real timestamps. Do so by always setting a valid timebase on the AVCodecContext for audio and video decoding. Specifically try not to round timestamps to a too coarse timebase, which could round off small adjustments to timestamps (such as for start time rebasing or demux_timeline). If the timebase is considered too coarse, make it finer. This gets rid of the need to do this specifically for some hardware decoding wrapper. The old method of passing through double timestamps was also a bit questionable. While libavcodec is not supposed to interpret timestamps at all if no timebase is provided, it was needlessly tricky. Also, it actually does compare them with AV_NOPTS_VALUE. This change will probably also reduce confusion in the future.
* demux_lavf: don't report start time for oggwm42016-08-181-2/+6
| | | | | Better with ogg shoutcast streams. These have PTS resets on each playlist item, so the PTS would usually reset to some negative value.
* demux: fix undefined behavior with ogg metadata updatewm42016-08-161-1/+1
| | | | | | | | | | When an ogg track upodates metadata, we have to perform a complicated runtime update due to the demux.c architecture. A detail was broken and an array was allocated with the previous number of streams, which usually led to invalid memory write accesses at least on the first update. See github commit comment on commit b9ba9a89.
* demux: minor cleanup to replaygain error handlingwm42016-08-131-12/+9
| | | | | | | If the PEAK tag is invalid, return an error. Make the error signalling conventions more uniform by strictly returning a negative value on error, and treating >=0 as success.
* demux: make ALBUM replaygain tags optionalwm42016-08-131-3/+7
| | | | IF they're missing, use the TRACK ones instead. See #3405.
* audio: log replaygain values in af_volume instead demuxerwm42016-08-131-6/+1
| | | | | | | The demuxer layer usually doesn't log per-stream information, and even the replaygain information was logged only if it came from tags. So log it in af_volume instead.
* demux: add per-track metadatawm42016-08-125-59/+143
| | | | | | | | | | | | | | | | | ...and ignore it. The main purpose is for retrieving per-track replaygain tags. Other than that per-track tags are not used or accessed by the playback core yet. The demuxer infrastructure is still not really good with that whole synchronization thing (at least in part due to being inherited from mplayer's single-threaded architecture). A convoluted mechanism is needed to transport the tags from demuxer thread to user thread. Two factors contribute to the complexity: tags can change during playback, and tracks (i.e. struct sh_stream) are not duplicated per thread. In particular, we update the way replaygain tags are retrieved. We first try to use per-track tags (common in Matroska) and global tags (effectively formats like mp3). This part fixes #3405.
* demux: do not add packets between refresh seek requested and donewm42016-08-081-1/+1
| | | | | Could cause strange issues on seeks or track switches, was only visible as race condition.
* demux_timeline: enable refresh seeks in some situationswm42016-08-071-0/+5
| | | | | | | | | | | | | Play a trick to make the packet pos field monotonically increasing over segment boundaries if the source demuxers return monotonically increasing pos values. This allows the demuxer to uniquely identify packets with the pos field, and can do refresh seeks using that. Normally, the packet pos field is used as a fallback for determining the playback position if the demuxer returns no proper duration. But demux_timeline.c always will, and the packet pos fields usually make no sense in relation to the returned file size anyway if the timeline source demuxers originate from separate streams.
* demux: make refresh seek handling more genericwm42016-08-064-19/+34
| | | | | | | | | | | | | | | | | Remove the explicit whitelisting of formats for refresh seeks. Instead, check whether the packet position is somewhat reliable during demuxing. If there are packets without position, or the packet position is not monotonically increasing, then do not use them for refresh seeks. This does not make sure of some requirements, such as deterministic seeks. If that happens, mpv will mess up a bit on stream switching. Also, add another method that uses DTS to identify packets, and prefer it to the packet position method. Even if there's a demuxer which randomizes packet positions, it hardly can do that with DTS. The DTS method is not always available either, though. Some formats do not have a DTS, and others are not always strictly monotonic (possibly due to libavformat codec parsing and timestamp determination issues).
* demux: fix a minor race conditionwm42016-08-061-10/+12
| | | | | | | | | | | | If the packet read function returns, and EOF was detected, and a seek was issued in the meantime, then don't use the EOF result. The seek will be processed later, and reset the EOF state anyway. The main effect is probably that we don't return EOF to the decoders (which the playback core resets before issuing the seek), and that we won't log an EOF message. Not important, but slightly more correct.
* player: improve instant track switchingwm42016-08-064-63/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When switching tracks, we normally have the problem that data gets lost due to readahead buffering. (Which in turn is because we're stubborn and instruct the demuxers to discard data on unselected streams.) The demuxer layer has a hack that re-reads discarded buffered data if a stream is enabled mid-stream, so track switching will seem instant. A somewhat similar problem is when all tracks of an external files were disabled - when enabling the first track, we have to seek to the target position. Handle these with the same mechanism. Pass the "current time" to the demuxer's stream switch function, and let the demuxer figure out what to do. The demuxer will issue a refresh seek (if possible) to update the new stream, or will issue a "normal" seek if there was no active stream yet. One case that changes is when a video/audio stream is enabled on an external file with only a subtitle stream active, and the demuxer does not support rrefresh seeks. This is a fuzzy case, because subtitles are sparse, and the demuxer might have skipped large amounts of data. We used to seek (and send the subtitle decoder some subtitle packets twice). This case is sort of obscure and insane, and the fix would be questionable, so we simply don't care. Should mostly fix #3392.
* audio: use --audio-channels=auto behavior, except on ALSAwm42016-08-041-4/+13
| | | | | | | | | | | | | | | | | | | | | | | This commit adds an --audio-channel=auto-safe mode, and makes it the default. This mode behaves like "auto" with most AOs, except with ao_alsa. The intention is to allow multichannel output by default on sane APIs. ALSA is not sane as in it's so low level that it will e.g. configure any layout over HDMI, even if the connected A/V receiver does not support it. The HDMI fuckup is of course not ALSA's fault, but other audio APIs normally isolate applications from dealing with this and require the user to globally configure the correct output layout. This will help with other AOs too. ao_lavc (encoding) is changed to the new semantics as well, because it used to force stereo (perhaps because encoding mode is supposed to produce safe files for crap devices?). Exclusive mode output on Windows might need to be adjusted accordingly, as it grants the same kind of low level access as ALSA (requires more research). In addition to the things mentioned above, the --audio-channels option is extended to accept a set of channel layouts. This is supposed to be the correct way to configure mpv ALSA multichannel output. You need to put a list of channel layouts that your A/V receiver supports.
* demux_raw: s16be support was missing due to small typoEric Toombs2016-07-301-1/+1
| | | | Signed-off-by: wm4 <wm4@nowhere>
* demux_lavf: remove subtitle seeking special-casewm42016-07-241-22/+7
| | | | | | | | It used not to work - but now it apparently does. Not sure when that got fixed in FFmpeg, but there's no longer a reason to keep this hack. This also gets rid of the check for the read_seek2 field, which is not part of the public API.
* libarchive: unify entry iteration between stream/demux layerswm42016-07-181-16/+3
| | | | No really good reason to duplicate this.
* demux_timeline: restore mkv edition switchingwm42016-07-141-0/+3
|
* demux_mkv: support Matroska webvttwm42016-06-141-0/+1
| | | | | | | They're different from the Google/WebM subtitle types, and use a new codec ID. Fixes #3247.
* demux_lavf: assume fully read files (subtitles) are always seekablewm42016-06-081-0/+1
| | | | | | | Since the libavformat API is crap, we have to apply tons of heuristics to check whether seeking will work. (No, checking it at seek time isn't going to work either, because if a seek fails, the demuxer will be in an undefined state. Because the libavformat API is crap.)
* demux: fix memory leak when loading of ordered chapter file is abortedwm42016-06-071-0/+1
|
* demux_edl: adjust warnings and variable nameswm42016-05-231-14/+14
| | | | | | | Don't warn against unknown sourve length if the segment length is explicitly provided. Rename "len" to "end_time", because that's what it actually is.
* demux_mkv: better resync behavior for broken google-created webmswm42016-05-211-0/+2
| | | | | | | | | | | | | | | | | | | | | I've got a broken webm that fails to seek correctly with "--start=0". The problem is that every index entry points to 1 byte before cluster start (!!!). demux_mkv tries to resync to the next cluster, but since it already has read 2 bytes with ebml_read_id(), it doesn't get the first cluster, but the following one. Actually, it can be any amount of bytes from 1-4, whatever happens to look valid at this essentially random byte position. Improve this by resyncing from the original position, instead of the one after the EBML element ID has been attempted to be read. The file shows the following headers: | + Muxing application: google at 177 | + Writing application: google at 186 Indeed, the file was downloaded with youtube-dl. I can only guess that Google got it completely wrong.
* demux_playlist: recognize m3u8 as playlist extensionwm42016-05-171-2/+9
| | | | Whatever. As mentioned in #3154.
* demux_lavf: fix a minor memory leakwm42016-05-081-1/+5
|
* demux_playlist: read directories recursivewm42016-04-181-17/+57
| | | | | | | | | | | |