summaryrefslogtreecommitdiffstats
path: root/demux
Commit message (Collapse)AuthorAgeFilesLines
* 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
| | | | | | | | | | | | | | demux_playlist.c recognizes if the source stream points to a directory, and adds its directory entries. Until now, only 1 level was added. During playback, further directory entries could be resolved as directory paths were "played". While this worked fine, it lead to frequent user confusion, because playlist resuming and other things didn't work as expected. So just recursively scan everything. I'm unsure whether it's a good fix, but at least it gets rid of the complaints. (And probably will add others.)
* demux_mkv: fix seeking with files that miss the first index entrywm42016-04-121-3/+6
| | | | | | | | | Now it will always be able to seek back to the start, even if the index is sparse or misses the first entry. This can be achieved by reusing the logic for incremental index generation (for files with no index), and start time probing (for making sure the first block is always indexed).
* demux_lavf, ad_lavc, ad_spdif, vd_lavc: handle FFmpeg codecpar API changewm42016-03-312-2/+18
| | | | | | | | | AVFormatContext.codec is deprecated now, and you're supposed to use AVFormatContext.codecpar instead. Handle this for all of the normal playback code. Encoding mode isn't touched.
* demux_lavf: remove old MicroDVD frame timing guessingwm42016-03-311-6/+1
| | | | | | | | | | This was changed in 2014, so I suppose users will usually have a FFmpeg release which includes the corresponding upstream change. If not, well too bad for those MicroDVD-obsessed users. Also don't try to retrieve the default framerate as exported by the demuxer, and instead hardcode it and trust it won't ever change. this avoids that we have to deal with a larger mess in the codecpar commit.
* demux_lavf: remove some old framerate guessingwm42016-03-311-14/+1
| | | | | | I don't trust it one bit, and it's a bother with the codecpar change. If it turns out to be important for some file formats, it could be added back (or FFmpeg fixed).
* Revert "demux_mkv: don't trust DefaultDuration for audio"wm42016-03-301-3/+5
| | | | | | | | | | This reverts commit 503c6f7fd6c3c542667c93c75db260671c4ba982. There are situations where some decoders (MF apparently) always require a timestamp. Also, this makes bitrate estimation more granular than necessary. It seems it's better to try to detect fiels with broken default durations explicitly instead. Or maybe something should be added to smooth audio timestamps after filters.
* cache: use a single STREAM_CTRL for various cache infowm42016-03-291-26/+8
| | | | | | | | Instead of having a separate for each, which also requires separate additional caching in the demuxer. (The demuxer adds an indirection, since STREAM_CTRLs are not thread-safe.) Since this includes the cache speed, this should fix #3003.
* demux_timeline: request subtitle prefetching on crossing segmentswm42016-03-251-1/+1
| | | | | | | | | | | SEEK_HR is interpreted by demux_mkv.c, and enables subtitle preroll by prefetching additional subtitle pakcets which might overlap with the seek destination. This should make the case work when segment boundaries fall into the middle of subtitle events. This still usually leaves a flicker of at least 1 frame on start, because dec_sub.c does not ensure that enough subtitles are read before rendering after a segment switch. (Probably a WONTFIX.)
* demux_timeline: skip decoder reinit when seeking to same segmentwm42016-03-171-5/+3
| | | | | "Normal" seeks, which don't actually switch the segment, do not need to reinit the decoders.
* demux: remove pausing mechanismwm42016-03-101-43/+22
| | | | | | | | | This is simpler, because it doesn't have to wait from both threads for synchronization. Apart from being simpler/cleaner, this serves vague plans to stop/start the demuxer thread itself automatically on demand (for the purpose of reducing unneeded resource usage).
* demux: replace demux_pause/demux_unpause with demux_run_on_threadwm42016-03-092-16/+43
| | | | | | | This pause stuff is bothersome and is needed only for a few corner- cases. This commit removes it from the demuxer public API and replaces it with a demux_run_on_thread() function and refactors the code which needed demux_pause(). The next commit will change the implementation.
* demux: delay bitrate calculation on packets with unknown timestampswm42016-03-051-2/+2
| | | | | | | | | Commit 503c6f7f essentially removed timestamps from "laces" (Block sub- divisions), which means many audio packets will have no timestamp. There's no reason why bitrate calculation can't just delayed to a point when the next timestamp is known. Fixes #2903 (no audio bitrate with mkv files).
* demux_null: fix segfault with --cache enabledwm42016-03-051-1/+1
| | | | | | stream->info can be NULL if it's the cache wrapper. To be fair, stream->info is considered private API anyway. So don't access it, but check the URL instead.
* demux_mkv: correctly export unknown packet durationswm42016-03-051-2/+3
| | | | Instead of just setting the duration to 0.
* demux: add null demuxerwm42016-03-042-0/+36
| | | | It's useless, but can be used for fancy --lavfi-complex nonsense.
* demux_timeline: set correct seekable flagswm42016-03-032-2/+2
| | | | | | Tricky misleading crap. Fixes #2898.
* demux_lavf: don't copy cover art picturewm42016-03-031-2/+2
| | | | Use the AVPacket refcounting mechanism instead.
* Revert "demux_mkv: pretend waveext channel layouts by default"wm42016-03-021-1/+1
| | | | | | | | | | | | | | | | This reverts commit af66fa8fa5d8e46b26a08a2b241f03d46abb3c2b. The reverted commit caused AVCodecContext.channel_layout to be set, while requesting stereo downmix will make libavcodec output a stupid message: ac3: Channel layout '5.1' with 6 channels does not match specified number of channels 2: ignoring specified channel layout The same happens with --demuxer=lavf (without this change too). I'm not quite sure what acrobatics are required to shut up libavcodec, but for now revert the commit. It was a rather minor, almost cosmetic issue, which I consider less important than clean CLI terminal output.
* demux_mkv: pretend waveext channel layouts by defaultwm42016-02-291-1/+1
| | | | | Not much of an impact, just makes output of the "channels" "track-list" sub-property nicer.
* demux: remove relative seekingwm42016-02-288-102/+40
| | | | | | | | | | | | | | | | | | | Ever since a change in mplayer2 or so, relative seeks were translated to absolute seeks before sending them to the demuxer in most cases. The only exception in current mpv is DVD seeking. Remove the SEEK_ABSOLUTE flag; it's not the implied default. SEEK_FACTOR is kept, because it's sometimes slightly useful for seeking in things like transport streams. (And maybe mkv files without duration set?) DVD seeking is terrible because DVD and libdvdnav are terrible, but mostly because libdvdnav is terrible. libdvdnav does not expose seeking with seek tables. (Although I know xbmc/kodi use an undocumented API that is not declared in the headers by dladdr()ing it - I think the function is dvdnav_jump_to_sector_by_time().) With the current mpv policy if not giving a shit about DVD, just revert our half-working seek hacks and always use dvdnav_time_search(). Relative seeking might get stuck sometimes; in this case --hr-seek=always is recommended.
* demux_timeline: slightly improve reported file formatwm42016-02-251-1/+3
| | | | | Report the underlying demuxer's format. Since there can be many demuxers participating, pick the "main" segment.
* demux: avoid lost wakeup on queue overflowwm42016-02-241-1/+6
| | | | | | | | | If a stream is marked as EOF (due to no packets found in reach), then we need to wakeup the decoder. This is important especially if no packets are found at the start of the file, so the A/V sync logic actually starts playback, instead of waiting for packets that will never come. (It would randomly start playback when running the playback loop due to arbitrary external events like user input.)
* demux_mkv: don't trust DefaultDuration for audiowm42016-02-241-5/+3
| | | | | It's used to interpolate timestamps for sub-packets ("block laces"). It's occasionally broken, and not really needed by us.
* demux_mkv: fix opus gapless behavior (2)wm42016-02-221-2/+2
| | | | | | | Commit 943f76e6, which already tried this, was very stupid: it didn't actually override the samplerate for Opus, but overrode it for all codecs other than Opus. And even then, it failed to use the overridden samplerate. (Sigh...)
* demux_lavf: adjust seeks by maximum codec delaywm42016-02-221-0/+8
| | | | | | | | | | | | | | | Fixes relative seeks. Without this, a seek back could skip so much data that the seek would effectively jump forward. (Or insert silence for files with video.) There's the question whether the frontend should do this instead (by using information from the decoders), but for now this seems more proper. demux_mkv.c does this already, sort of. libavformat doesn't for seeks in .ogg (aka .opus), but might be doing it for mkv. Seems to be a mess as well.
* demux_mkv: add hack to fix opus gapless behaviorwm42016-02-211-0/+6
| | | | |<