summaryrefslogtreecommitdiffstats
path: root/demux
Commit message (Collapse)AuthorAgeFilesLines
* command, demux: make drop-buffers reset state even harderwm42020-09-171-2/+9
| | | | Leave nothing left when it's executed.
* Revert "demux_lavf: always give libavformat the filename when probing"wm42020-08-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 41243e7c4f98b410195397b6758f9796acd9de57. This fixes image format detection. FFmpeg has an utter called "image2", which is designed to read patterns in filenames (so you can play something like "%*.jpg" for all jpg files in the current directory). "image2" is not what we want; it's just broken with custom I/O like mpv uses it, and we don't want to "accidentally" interpret filenames as pattern. That's why mpv blacklists it. Unfortunately, "image2" is sometimes the format that FFmpeg's probe API returns as best match. Thus demux_lavf fails to detect the file type, and after some more futile attempts, we end up at demux_mf, which uses detection by file extension. (Not sure why. I guess MPlayer did that, and foudn that sufficient.) If the file extension is wrong (which happens a lot because apparently the world is full of idiots who don't manage to get the most simple things right), the image "loads", but decoding obviously fails. There's no easy way around this. The FFmpeg API has no mechanism to exclude a specific format from probing (like image2, which breaks stuff for us). Out of the 5 probe functions the API provides, none can probe a specific format or include or exclude specific formats. The main problem is that AVInputFormat.read_probe is a private symbol. FFmpeg itself has no problem opening such files. It turns out that it works, because even though image2 by itself uses detection by file extension, it uses private API to further probe the exact format. It explicitly excludes itself to prevent recursion. But fortunately, that also means that it's impossible to get the image2 format if no filename is passed to the prober. (No filename, no file extension.) Apparently we pass it in because it helps in corner cases. Until almost 3 years ago, we passed the filename only when normal probing already failed. Restore this by this revert. It makes incorrectly named files work. The revert also makes the (apparently forgotten) comment above the touched line of code true again. Yes, quite possible that this breaks some mp3s again. You can't win with FFmpeg. Thanks FFmpeg for making us fail at opening simple image files and/or the most widely used file format for audio.
* demux_mf: actually report errorswm42020-08-221-0/+6
| | | | | | Well, whatever. Only results in an error message being printed, because there is no other error reporting mechanism, and the general policy is to keep trying with the rest of the data (i.e. not report EOF).
* demux_mkv: warn against some other aspects of mismatching codec datawm42020-08-161-0/+5
| | | | | | Such files violate the specification. Unfortunately, I could not test whether it really works correctly, since I don't have a sample at hand that is not broken in this regard.
* demux_lavf: workaround reading gif from unseekable streamswm42020-07-091-0/+19
| | | | | | | FFmpeg, being the pile of trash as usual, recently broke this. Add our own trash hack to trashily workaround this shit. Fixes: #7893
* build: change filenames of generated fileswm42020-06-042-2/+2
| | | | Force them into a more consistent naming schema.
* stream_libarchive: remember archive headers from initial openKevin Mitchell2020-04-281-1/+1
| | | | | | | | | | | | | | | | | | The header probing hacks were previously all broken. They only worked the first time the archive file was open. Since subsequent opens (on seek) occured in the middle of the source stream rather than at the beginning, the stream_read_peek calls meant to retrieve the headers were instead returning random bytes in the middle of the file. Perhaps the worst manifestation of this was when seeking within a multi-volume .rar archive with the "legacy" file naming pattern. If the seek required a reopen, the fact that the archive was multi-volume would be forgotten and the file would appear truncated terminating playback. To solve this, only perform the header probling the first time the archive is opened. Save the results and reuse them on subsequent reopens. Put this in a wrapper so this is transparent to demux_libarchive.
* demux_mkv: add png intra supportwm42020-04-161-0/+1
| | | | | | | Evil, non-standard shit. Sample file and script: https://github.com/mpv-player/random-stuff/tree/master/matroska/png
* demux_mkv: concatenate multiple tagswm42020-04-131-2/+8
| | | | | | | | | | | Instead of just picking the last tag that was encountered. The order of the tags still depends on the file order. This is probably wrong, and we should respect TargetTypeValue. But despite staring at the spec, I have no idea what the hell this should do, so fuck that. Fixes: #7604
* demux: don't let --sub-create-cc-track add a track for attached pictureswm42020-04-131-1/+1
| | | | | | | | Unfortunately, attached pictures (from tags etc.) are treated as video tracks. That meant --sub-create-cc-track added a CC track for them as well. Stop doing that. See: #7608
* options: cleanup .min use for OPT_CHANNELSwm42020-04-091-1/+1
| | | | | | | | Replace use of .min==1 with a proper flag. This is a good idea, because it has nothing to do with numeric limits (also see commit 9d32d62b61547 for how this can go wrong). With this, m_option.min/max are strictly used for numeric limits.
* stats: some more performance graphswm42020-04-091-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add an infrastructure for collecting performance-related data, use it in some places. Add rendering of them to stats.lua. There were two main goals: minimal impact on the normal code and normal playback. So all these stats_* function calls either happen only during initialization, or return immediately if no stats collection is going on. That's why it does this lazily adding of stats entries etc. (a first iteration made each stats entry an API thing, instead of just a single stats_ctx, but I thought that was getting too intrusive in the "normal" code, even if everything gets worse inside of stats.c). You could get most of this information from various profilers (including the extremely primitive --dump-stats thing in mpv), but this makes it easier to see the most important information at once (at least in theory), partially because we know best about the context of various things. Not very happy with this. It's all pretty primitive and dumb. At this point I just wanted to get over with it, without necessarily having to revisit it later, but with having my stupid statistics. Somehow the code feels terrible. There are a lot of meh decisions in there that could be better or worse (but mostly could be better), and it just sucks but it's also trivial and uninteresting and does the job. I guess I hate programming. It's so tedious and the result is always shit. Anyway, enjoy.
* demux: average reported download speed some morewm42020-03-211-1/+5
| | | | | | Currently, this reported the number of received bytes per second. Improve this slightly by averaging over 2 seconds (but still updating every second).
* options: fix OPT_BYTE_SIZE upper limitswm42020-03-181-6/+2
| | | | | | | | | | | | | | | | | | | | | | | | As an unfortunate disaster, min/max values use the type double, which causes tons of issues with int64_t types. Anyway, OPT_BYTE_SIZE is often used as maximum for size_t quantities, which can have a size different from (u)int64_t. OPT_BYTE_SIZE still uses in64_t, because in theory, you could use it for file sizes. (demux.c would for example be capable of caching more than 2GB on 32 bit platforms if a file cache is used. Though for some reason the accounting code still uses size_t, so that use case is broken. But still insist that it _could_ be used this way.) There were various inconsistent attempts to set m_option.max to a value such that the size_t/int64_t upper limit is not exceeded. Due to the double max field, this didn't really work correctly. Try to fix this with the M_MAX_MEM_BYTES constant. It's a good approximation, because on 32 bit it should allow 2GB (untested, also would probably exhaust address space in practice but whatever), and something "high enough" in 64 bit. For some reason, clang 11 still warns. But I think this might be a clang bug, or I'm crazy. The result is correct anyway.
* demux_mkv: fix another integer/float conversion warningwm42020-03-181-1/+2
| | | | This code could assign INT64_MAX+1 (as double) to int64_t.
* options: change option macros and all option declarationswm42020-03-187-93/+96
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change all OPT_* macros such that they don't define the entire m_option initializer, and instead expand only to a part of it, which sets certain fields. This requires changing almost every option declaration, because they all use these macros. A declaration now always starts with {"name", ... followed by designated initializers only (possibly wrapped in macros). The OPT_* macros now initialize the .offset and .type fields only, sometimes also .priv and others. I think this change makes the option macros less tricky. The old code had to stuff everything into macro arguments (and attempted to allow setting arbitrary fields by letting the user pass designated initializers in the vararg parts). Some of this was made messy due to C99 and C11 not allowing 0-sized varargs with ',' removal. It's also possible that this change is pointless, other than cosmetic preferences. Not too happy about some things. For example, the OPT_CHOICE() indentation I applied looks a bit ugly. Much of this change was done with regex search&replace, but some places required manual editing. In particular, code in "obscure" areas (which I didn't include in compilation) might be broken now. In wayland_common.c the author of some option declarations confused the flags parameter with the default value (though the default value was also properly set below). I fixed this with this change.
* options: change how option range min/max is handledwm42020-03-132-8/+11
| | | | | | | | | | | | | | | | | Before this commit, option declarations used M_OPT_MIN/M_OPT_MAX (and some other identifiers based on these) to signal whether an option had min/max values. Remove these flags, and make it use a range implicitly on the condition if min<max is true. This requires care in all cases when only M_OPT_MIN or M_OPT_MAX were set (instead of both). Generally, the commit replaces all these instances with using DBL_MAX/DBL_MIN for the "unset" part of the range. This also happens to fix some cases where you could pass over-large values to integer options, which were silently truncated, but now cause an error. This commit has some higher potential for regressions.
* demux: bump --cache-secs default valuewm42020-03-071-1/+1
| | | | | | Change to it 1000 hours, which is "infinite" enough. (Hesitant to use INFINITY, as that is not in the option's range. The option parser rejects it because it causes only problems in API users and so on.)
* demux: mark recently added debug option as deprecatedwm42020-03-071-1/+2
| | | | | It was the intention to remove it again after a release or two; mark it was deprecated so nobody thinks it gets to stay.
* demux: deprecate --cache-secswm42020-03-051-1/+2
| | | | | Because it's confusing and useless. If nobody complains, we'll have one weird cache configuration option less.
* demuxer-lavf: udp_multicast rtsp-transport optionmg2020-03-031-1/+4
|
* demux: another hack to deal with track switching refreshwm42020-02-291-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The demuxer cache employs a strange method to make track switching instant with caching enabled. Normally this would mean you have to wait until the cache has played out (and you get new packets, including packets from the newly selected track), or you have to perform a slow high level seek (decoding video again etc.). The strange method is that it performs a demuxer-level seek without a high level seek so it looks like a continuous stream to the decoder, and the newly select stream gets packets at the current playback position. This is called a refresh seek. This works only if some weird heuristics work. It needs a packet "unique ID", for which it uses either dts or pts. The value must be strictly monotonic increasing. If this doesn't work, the referesh seek can't be executed, and the user has to wait until the end of the cache. Sometimes there are files that simply do not work. In the present case, there's actually a hack that we can extend. Packets with unset position are likely generated by the parser, and the hack which this commit touches simply attempts to make up a new (hopefully unique) position value, even if the value itself makes no sense. It only ha to be deterministic. It turns out libavcodec sometimes output packets with repeating position values. This commit tries to handle this case too with the same hack. Fixes: #7498
* demux: add a way to block reading after seekswm42020-02-292-0/+7
| | | | | | Preparation for a future commit. The demuxer queues might be read from other threads than the one to issue the seek, and passing SEEK_BLOCK with such a seek will provide a convenient way to synchronize this.
* demux_lavf: don't interpret errors as EOFwm42020-02-281-3/+9
| | | | | | | | | | | | | | | It seems sporadic errors are possible, such as connection timeouts. Before the recent demuxer change, the demuxer thread retried many times even on EOF, so an error was only interpreted as EOF once the decoder queues ran out. Change it to use EOF only. Since this may actually lead to the demuxer thread being "stuck" and retrying forever (depending on libavformat API behavior), I'm also adding a heuristic to prevent this, using a random retry counter. This should not be necessary, but libavformat cannot be trusted. (This retrying forever could be stopped by the user, but obviously it would still heat the CPU for a longer time if the user is not present.)
* demux: make seek ranges work for static images + audiowm42020-02-281-1/+3
| | | | | | | | | | | | | In this case the video track has seek_start == seek_end, and due to the "seek_start >= seek_end" condition, this was considered broken, and no seek range was created, breaking cached seeking. Fix this by allowing the case if they're equal, and a valid timestamp. (NB: seeking backward in this will still jump to position 0, because it is the video timestamp. This is unfortunately how it's supposed to work. HR-seeks will also do this, but decode and skip the entire audio until the seek target, so it will mostly appear to work.)
* demux_timeline: fix bad EOF reportingwm42020-02-281-11/+10
| | | | | | | | | | | | | | | | Exposed by commit b56e2efd5f3d. demux_timeline reported a bogus EOF if "parallel" streams were used. If a virtual source reported EOF, it was propagated as global EOF, without serving packets of other virtual sources that have not ended yet. Fix this by not reporting global EOF just because a source has not returned a packet. Instead make the reader retry by returning no packet and no EOF state, which will call d_read_packet() again with a different source. Rely on the eof_reached flags to signal global EOF. Since eof_reached is now more important, set it in a certain other case when it apparently should have been set. do_read_next_packet()'s return value is now ignored, so get rid of it.
* demux_mkv: document probe-start-time option and enable it by defaultwm42020-02-271-1/+2
| | | | | | | | | | | | This is useful with live streams, and it's not much worse than the h264 first packet hack, which reads some data anyway. For some reason, the option wasn't even documented, so do that. In addition, print the start time even if it's negative. That should not be possible, but for some reason, the field is an int64_t copied from an uint64_t so... whatever. Keeping the logging slightly more straight forward is better anyway.
* demux: simplify some internals, stop trying to read packets after EOFwm42020-02-271-27/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | Remove some redundant fields that controlled or indicated whether the demuxer was/could/should prefetch. Redefine how the eof/reading fields work. The in->eof field is now always valid, instead of weirdly being reset to false in random situations. The in->reading field now corresponds to whether the demuxer thread is working at all, and is reset if it stops doing anything. Also, I always found it stupid that dequeue_packet() forced the demuxer thread to retry reading if it was EOF. This makes little sense, but was probably added for files that are being appended to (running downloads). It makes no sense, because if the cache really tried to read until file EOF, it would encounter partial packets and throw errors, so all is lost anyway. Plus stream_file now handles this better. So stop this behavior, but add a temporary option that enables the old behavior. I think checking for ds->eager when enabling prefetching never really made sense (could be debated, but no, not really). On the other hand, the change above exposed a missing wakeup in the backward demuxing code. Some chances of regressions that could make it stuck in certain states or so, or incorrect demuxer cache state reporting to the player frontend.
* sub, demux: improve behavior with negative subtitle delay/muxed subswm42020-02-272-4/+41
| | | | | | | | | | | | | | | | | | | | | | | | A negative subtitle delay means that subtitles from the future should be shown earlier. With muxed subtitles, subtitle packets are demuxed along with audio and video packets. But since they are demuxed "lazily", nothing guarantees that subtitle packets from the future are available in time. Typically, the user-observed effect is that subtitles do not appear at all (or too late) with large negative --sub-delay values, but that using --cache might fix this. Make this behave better. Automatically extend read-ahead to as much as needed by the subtitles. It seems it's the easiest to pass the subtitle render timestamp to the demuxer in order to guarantee that everything is read. This timestamp based approach might be fragile, so disable it if no negative sub-delay is used. As far as the player frontend part is concerned, this makes use of the code path for external subtitles, which are not lazily demuxed, and may already trigger waiting. Fixes: #7484
* demux: avoid some queue management corner cases with subtitleswm42020-02-271-2/+3
| | | | | | | | | | | | | | | | | | | Subtitle tracks are usually "lazy" (ds->eager=false), There are a number of weird special cases associated with it. One of them is that they have some sort of "temporary" EOF (to signal that there isn't a packet right now, and the decoder should not block playback by waiting for more packets). In a the next commit, I want to call mark_stream_eof() in case of (some) of these temporary EOFs. The problem is that mark_stream_eof() also calls the functions touched by this commit. Basically they shouldn't do any complex work due to these temporary EOFs (because they might happen very often). It turns out that lazy tracks barely matter here: they do not extend the seek range of a packet/EOF happens on them, they do not trigger seek range joining, and they do not support backward demuxing. This change should enable the following commit, while not causing any behavior changes (i.e. bugs) with the current state.
* ytdl_hook, edl: add fps, samplerate codec parameterswm42020-02-211-0/+2
| | | | Well, didn't help much in the case I was interested it.
* edl: make it possible to set the track "default" flagwm42020-02-211-0/+11
| | | | | Also, the forced flag (and in the future, potentially a number of other flags not implemented yet). See next commit for purpose.
* demux_edl: correct warning on duplicate parameterswm42020-02-211-2/+4
| | | | | | | | A parameter that is actually used is removed from the param_names[] array, so we can report unused parameters. This also happened on duplicate parameters, so adjust the warning to make it less confusing. (In any case, you're not supposed to provide duplicate parameters.)
* edl: make it possible to delay-load files with multiple trackswm42020-02-213-17/+49
| | | | | | | | | | | | | | Until now, delay-loading was for files with single tracks only (basically what DASH and HLS like to expose, so adaptive streaming and codec selection becomes easier - for sites, not for us). But they also provide some interleaved versions, probably for compatibility. Until now, we were forced to eagerly load it (making startup slightly slower). But there is not much missing. We just need a way to provide multiple metadata entries, and use them to represent each track. A side effect is now that the "track_meta" header can be used for normal EDL files too.
* demux_lavf: signal no seeking for RTSP streams without durationwm42020-02-201-0/+5
| | | | | | | | | | | | RTSP supports seeking, but at least the libavformat implementation makes this dependent on runtime behavior. So you have to perform a seek, and check if it fails. But even if you do this, the stream is interrupted and restarted, and there seem to be other issues. Assume that RTSP with unknown duration means it's a live stream, and disable seeking in this case, as suggested by the issue reporter. Fixes: #7472
* demux_timeline: don't open every delayed-open track on seekingwm42020-02-201-1/+1
| | | | | | | Now this was stupid. To seek a source, it obviously has to be opened... so just don't try to seek any unused source. If the track is actually selected during playback, a seek to the correct position is performed anyway.
* demux: fix seek range caching with delay_open hackwm42020-02-201-1/+2
| | | | | | These have ->segmented set (so the codec can be initialized properly), but have no segment start or end times. This code was (probably) the only thing which didn't handle this case.
* demux_timeline: warn if streams are invisiblewm42020-02-201-0/+6
| | | | | | | | ytdl_hook.lua can do this with all_formats and when delay_open is used, and if the source stream actually contains both audio and video. In this case, it might accidentally hide a media type completely, or waste bandwidth (if the stream has true interleaved audio/video). So it's important to warn.
* player: print manifest per-stream bitrate information to terminalwm42020-02-191-2/+0
| | | | | Aka hls-bitrate. In turn, remove the demux_lavf.c hack, which made the track title use this.
* demux: cosmetic changewm42020-02-171-2/+1
| | | | This was sort of asymmetric and annoying.
* demux: update file-size property even when pausedwm42020-02-161-0/+3
| | | | | | | | | | | While paused, the decoders typically stop reading data from the demuxer. But for some reason, the file size is returned as a public field in struct demuxer (wat...), and updated only when the packet reading function is called. This caused the file size property to always return the same value when paused, even though the demuxer thread was reading new data, and the internal file size was updated. Fix with a simple hack.
* demux: only query stream size at most once per secondwm42020-02-161-5/+9
| | | | | | | | | | Instead of every packet. Doing it every packet led to the performance regression mentioned in the fstat() commit. This should now be over, but out of being careful, don't query the file size that often. This is only used for user interface things, so this should not cause any problems. For the sake of leaving the code compact, abuse another thing that is updated only every second (speed statistics).
* demux: invert update_cache() lockingwm42020-02-161-9/+7
| | | | Equivalent, just slightly more convenient for the following change.
* Remove remains of Libav compatibilitywm42020-02-163-12/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Libav seems rather dead: no release for 2 years, no new git commits in master for almost a year (with one exception ~6 months ago). From what I can tell, some developers resigned themselves to the horrifying idea to post patches to ffmpeg-devel instead, while the rest of the developers went on to greener pastures. Libav was a better project than FFmpeg. Unfortunately, FFmpeg won, because it managed to keep the name and website. Libav was pushed more and more into obscurity: while there was initially a big push for Libav, FFmpeg just remained "in place" and visible for most people. FFmpeg was slowly draining all manpower and energy from Libav. A big part of this was that FFmpeg stole code from Libav (regular merges of the entire Libav git tree), making it some sort of Frankenstein mirror of Libav, think decaying zombie with additional legs ("features") nailed to it. "Stealing" surely is the wrong word; I'm just aping the language that some of the FFmpeg members used to use. All that is in the past now, I'm probably the only person left who is annoyed by this, and with this commit I'm putting this decade long problem finally to an end. I just thought I'd express my annoyance about this fucking shitshow one last time. The most intrusive change in this commit is the resample filter, which originally used libavresample. Since the FFmpeg developer refused to enable libavresample by default for drama reasons, and the API was slightly different, so the filter used some big preprocessor mess to make it compatible to libswresample. All that falls away now. The simplification to the build system is also significant.
* edl: add mechanism for delay loading streamswm42020-02-154-33/+147
| | | <