summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* audio: remove unreferenced af_lavrresamplewm42019-09-193-151/+0
| | | | | | | | | | | | | | This filter wasn't referenced anywhere and thus was dead code. It should have been in the audio filter list in user_filters.c. This was intended as compatibility wrapper (to avoid breaking old command lines and config files), and has no real use. Apparently I forgot to add it to the filter list (did I even test this shit?), and so it was rotting around for 1.5 years doing nothing (just like myself). Note that users can just use the libavfilter provided filter to force resampling, just that it has a different name and different options. There's also af_format to force inserting auto conversion through the internal f_swsresample filter.
* vo_gpu: remove vdpau/GLX backendwm42019-09-193-422/+0
| | | | | | | Useless garbage. This was once added to test whether vdpau presentation feedback could be used. Results were always unsatisfactory, and now vdpau is dead.
* vo_gpu: remove mali-fbdevwm42019-09-195-176/+2
| | | | | Useless at this point, I don't even know if it still works, or how to test it.
* manpage: fix minor typowm42019-09-191-1/+1
|
* stats.lua: add graphs for readahead time and total byte usagewm42019-09-191-6/+58
| | | | | | | | | | | | | The readahead time should be interesting for latency vs. underruns (which idiot protocols like HLS suffer from). The total byte usage is less interesting than I hoped; maybe the frequency at which it samples should be reduced. (Kind of dumb - you want high frequency for the readahead field, but much lower for byte usage.) Of course, the code was copy&pasted from the DS ratio/jitter stuff. Some of the choices may not make any sense for the new code.
* msg: remove unnecessary conditionwm42019-09-191-4/+0
| | | | Atomics were made mandatory some time ago.
* demux_mkv: add hacks to avoid a single warningwm42019-09-191-9/+26
| | | | | | | | | | | | | | It prints "Unexpected end of file (no clusters found)" when opening a webm init fragment. The warning is correct, but unwanted in this case. Add tons of kludges to avoid it. (Actually it prints that twice, for audio and video each.) Also, suppress another warning about a seek head entry that points exactly to the end of the file. This is a MATROSKA_ID_CUES, which is harmless, and, very strangely, doesn't point at any cues when you concatenate the init fragment with a media fragment. No idea what that crap is supposed to be.
* demux: make webm dash work by using init fragment on all demuxerswm42019-09-192-32/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Retarded webshit streaming protocols (well, DASH) chop a stream into small fragments, and move unchanging header parts to an "init" fragment to save some bytes (in the case at hand about 300 bytes for each fragment that is 100KB-200KB, sure was worth it, fucking idiots). Since mpv uses an even more retarded hack to inefficiently emulate DASH through EDL, it opens a new demuxer for every fragment. Thus the fragment needs to be virtually concatenated with the init fragment. (To be fair, I'm not sure whether the alternative, reusing the demuxer and letting it see a stream of byte-wise concatenated fragmenmts, would actually be saner.) demux_lavc.c contained a hack for this. Unfortunately, a certain shitty streaming site by an evil company, that will bestow dytopia upon us soon enough, sometimes serves webm based DASH instead of the expected mp4 DASH. And for some reason, libavformat's mkv demuxer can't handle the init fragment or rejects it for some reason. Since I'd rather eat mushrooms grown in Chernobyl than debugging, hacking, or (god no) contributing to FFmpeg, and since Chernobyl is so far away, make it work with our builtin mkv demuxer instead. This is not hard. We just need to copy the hack in demux_lavf.c to demux_mkv.c. Since I'm not _that_ much of a dumbfuck to actually do this, remove the shitty gross demux_lavf.c hack, and replace it by a slightly less bad generic implementation (stream_concat.c from the previous commit), and use it on all demuxers. Although this requires much more code, this frees demux_lavf.c from a hack, and doesn't require adding a duplicated one to demux_mkv.c, so to the naive eye this seems to be a much better outcome. Regarding the code, for some reason stream_memory_open() is never meant to fail, while stream_concat_open() can in extremely obscure situations, and (currently) not in this case, but we handle failure of it anyway. Yep.
* stream: add a generic concat implementationwm42019-09-193-0/+165
| | | | | | This is not available to users. It can be used only though the stream_concat_open(). It's unused yet; to be used in the following commit.
* demux: never set demux->stream for timeline messwm42019-09-191-27/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Timeline (demux_timeline, for EDL and mkv ordered chapters) are a mess, because it's the only nested demuxer case. Part of the mess comes from shared struct stream pointers. This makes no sense, because the wrapper (demux_timeline) doesn't have any business setting it. Try to lessen it by not passing down streams. Instead, pass down NULL. This prevents unintended interference, and tightens the ownership rules. Now a demuxer always owns its stream. On the other hand, demuxer->stream can now be NULL. This was never the case before, and consequently there will be new bugs. At least they will be spotted, because they've been bugs before. struct stream is also used to access stream properties (such as whether something is considered a network stream). Most of these have been mirrored in struct demuxer (because the frontend has been forbidden to access struct stream because of threading). But during initialization was still used, so introduce an awkward struct parent_stream_info, which unifies these. Commit e0419fb181b3d2 changed demux_is_network_cached() to use demuxer->stream->streaming instead of demuxer->is_network. To enable timeline stuff to use the cache anyway, change it so that both flags can contribute to it. The stream NULL-check is obviously due to changes in this commit.
* stream: create memory streams in more straightforward waywm42019-09-197-44/+62
| | | | | | | | | | | | | | | Instead of having to rely on the protocol matching, make a function that creates a stream from a stream_info_t directly. Instead of going through a weird indirection with STREAM_CTRL, add a direct argument for non-text arguments to the open callback. Instead of creating a weird dummy mpv_global, just pass an existing one from all callers. (The latter one is just an artifact from the past, where mpv_global wasn't available everywhere.) Actually I just wanted a function that creates a stream without any of that bullshit. This goal was slightly missed, since you still need this heavy "constructor" just to setup a shitty struct with some shitty callbacks.
* demux_playlist: extend maximum line sizewm42019-09-191-1/+1
| | | | | | | | Raise it from 8KB to 512KB. Do this because ytdl_hook.lua generated a 40KB EDL file (from 80KB youtube-dl JSON output), and putting it into a .m3u file for easier debugging failed due to the size limit.
* common: add macro for checking whether a value is a power of twowm42019-09-191-0/+1
| | | | | | | I think I repeated this inline in some places (or maybe not), and some experimental but discarded code used it. Add it anyway, maybe it'll be useful. Or it'll give someone a chance to get a contribution into mpv by removing an unused macro.
* demux: fix backward demuxing not grabbing all audio packetswm42019-09-191-5/+5
| | | | | | | | | | | | | | | | The previous commit broke audio playback (maybe this is what 4. was about?). But it wasn't the fault of the commit; it just exposed pre-existing issues. If the packet queue search can't get all packets, it checked queue->is_bof to see whether there could be previous packets. But obviously, is_bof can be set, even if the search start packet wasn't the first one. This was especially observable with audio, because audio by default needs preroll packets, and plays artifacts if they're missing. Fix by using the BOF playback condition for this purpose too.
* demux: another questionable backwards playback mud partywm42019-09-191-5/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In theory, backward demuxing does way too much work by doing a full cache seek every time you need to step back through a packet queue. In theory, it would be exceedingly more efficient to just iterate backwards through the queue, but this is not possible because I'm too stingy to add 8 bytes per packet for backlinks. (In theory, you could probably come up with some sort of deque, that'd allow efficient iteration into any direction, but other requirements make this tricky, and I'm currently too dumb/lazy to do this. For example, the queue can grow to millions of elements, all while packet pointers need to stay valid.) Another possibility is to "locally" seek the queue. This still has less overhead than a full seek. Also, it just so happens that, as a side effect, this avoids performing range merging, which commit f4b0e7e942 "broke". That wasn't a bug at all, but since range joining is relatively slow, avoiding it is good. This is really just a coincidental side effect, I'm not even quite sure why it happens this way. There are 4 ugly things about this change: 1. To get a keyframe "before" a certain one, we recompute the target PTS, and then subtract 0.001 as arbitrary number to "fudge" it. This isn't the first place where this is done, and hey, it wasn't my damn idea that MPlayer should use floats for timestamps. (At first, it even used 32 bit timestamps.) 2. This is the first time reader_head is reset to an earlier position outside of the seek code. This might cause conceptual problems since this code is now "duplicated". 3. In theory, find_backward_restart_pos() needs to be run again after the backstep. Normally, the seek code calls it explicitly. We could call it right in the new code, but then the damn function would be recursive. We could shuffle the code around to make it a loop, but even then there'd be an offchance into running into an unexpected corner case (aka subtle bug), where it would loop forever. To avoid refactoring the code and having to think too hard about it, make it deferred - add some new state and the check_backward_seek() function for this. Great, even more subtle mutable state for this backwards shit. 4. I forgot this one, but I can assure you, it's bad. Without doubt someone will have to clean up this slightly in the future (or rip it out), but it won't be me.
* demux: remove some redundancy in backward playback codewm42019-09-191-6/+5
| | | | | | | | | | | This code tries to determine the "current" position, which is used as base for the seek target when it needs to seek back more (the point is to prevent seeking back too far). But compute_keyframe_times() almost computes the same thing, so use that. Unfortunately needs a forward declaration. ("Almost", because it differs in some details that should not really matter.)
* demux_mkv: fix subtitle preroll in some caseswm42019-09-191-7/+6
| | | | | | | | | | | | | | | | | | | | | | Subtitle packets with a timestamp before the seek target may overlap with the seek target anyway. This is why this subtitle preroll crap exists: it needs to return packets before the seek target to ensure that the subtitle is displayed at the seek target. This didn't always work. Maybe it's a regression, but it must have been an old one. The breakage is triggered by heuristic that is to prevent excessive queuing of packets in garbage files (this heuristic apparently became immediately necessary when this preroll mechanism was implemented). If a video keyframe packet was found, but no audio packet yet, then subtitle_preroll was set to 0, and since a_skip_to_keyframe was still 0, the subtitle packet was discarded. The dumb thing is that subtitle and video seeking is finished at this point, so the preroll crap should not be applied at all. Fix this by moving the preoll overflow code into the block that handles preroll.
* osc: add feature to bottombar to not cover the videowm42019-09-192-1/+67
| | | | | | | | | | | | | | | | | | | | | | Normally I use the OSC like this: not at all, but have a key binding that does "cycle osc" to show it. And in that case, I don't really want it to overlap the damn video. I could use the zoom/pan options to move the video out of the way, but this is also sort of annoying. Likewise, you could write a script or so which does this automatically if the OSC appears, but that's still annoying, and computing values for these options such that the video is moved correctly is tricky. So I added a bunch of options that set explicit video borders (previous commit), and a option for the OSC to use them (this commit). Disabled by default, since I'm afraid this is too awkward and unpolished, especially with OSC default settings. I'm also using "osc-visibility=always". Effectively, making the OSC appear will box the video, and making it disappear (by unloading osc.lua) will restore the video back to normal.
* aspect: add video margin optionswm42019-09-194-5/+73
| | | | | | | | | | | | | | | Semantics a bit questionable. This is done for the OSC (next commit), and a comment added the manpage explicitly states this. Meaning this is probably garbage and needs to revisit when the OSC changes and/or someone wants to use this margin feature for something else. Not sure about the subtitle thing. It's imaginable that someone uses these options to create empty borders for subtitles on the bottom, so subtitles should be located there. On the other hand, this gives a rather unpolished user experience when using the (later added) OSC feature to not overlap with the video. There's not much of a point if the OSC still overlaps the video. However, I'm too lazy to think about this, so it stays like it is.
* aspect: fix some UB problems in corner caseswm42019-09-191-6/+6
| | | | | | | | | | | --video-margin-ratio-left=0.2 --video-margin-ratio-right=0.9 (added in the the next commit) will set f_w to inf, resulting in some garbage being propagated. Later, the OSD margins are computed from values before various sanity clamping is applied, which makes libass suffer from bullshit values. I'm very sure it's OK and more correct to compute the OSD margins using the later values, but I'm not sure about that.
* stats.lua: add cache info pagewm42019-09-191-4/+69
| | | | Uses page 3, which was apparently reserved for filter info.
* manpage: fix false statementwm42019-09-191-2/+2
|
* demux: turn some redundant assignments into assertswm42019-09-191-3/+5
| | | | | | | | demux_packet.next should not be used outside of demux.c, and in this case it's a packet that was just passed to demux.c from the outside. demux_packet.stream is already set by the demuxer, and this is assured by the add_packet_locked() caller.
* demux: move a functionwm42019-09-191-14/+12
| | | | | | The new location makes equally much sense (or more, since it's close to its per-stream companion function), and we don't need a forward declaration.
* demux: disable backward demuxing if it fatally failswm42019-09-191-0/+13
| | | | | | | | | | | | | | We don't care much about this case, because backward playback can fail terribly without a good way to detect it, so this was fine. However, this froze in certain situations. Reading from a subtitle file for which backward demuxing failed could make it get stuck in demux_read_packet_async() in unthreaded mode. (That we don't support backwards subtitle decoding anyway doesn't matter for this.) So aggressively disable backward demuxing to prevent worse in these situations. The behavior will still be awful, because the frontend is still in backwards playback mode, but at least it won't freeze.
* demux: add a on-disk cachewm42019-09-1912-39/+510
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Somewhat similar to the old --cache-file, except for the demuxer cache. Instead of keeping packet data in memory, it's written to disk and read back when needed. The idea is to reduce main memory usage, while allowing fast seeking in large cached network streams (especially live streams). Keeping the packet metadata on disk would be rather hard (would use mmap or so, or rewrite the entire demux.c packet queue handling), and since it's relatively small, just keep it in memory. Also for simplicity, the disk cache is append-only. If you're watching really long livestreams, and need pruning, you're probably out of luck. This still could be improved by trying to free unused blocks with fallocate(), but since we're writing multiple streams in an interleaved manner, this is slightly hard. Some rather gross ugliness in packet.h: we want to store the file position of the cached data somewhere, but on 32 bit architectures, we don't have any usable 64 bit members for this, just the buf/len fields, which add up to 64 bit - so the shitty union aliases this memory. Error paths untested. Side data (the complicated part of trying to serialize ffmpeg packets) untested. Stream recording had to be adjusted. Some minor details change due to this, but probably nothing important. The change in attempt_range_joining() is because packets in cache have no valid len field. It was a useful check (heuristically finding broken cases), but not a necessary one. Various other approaches were tried. It would be interesting to list them and to mention the pros and cons, but I don't feel like it.
* osdep: add mkostemps() emulationwm42019-09-192-2/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Supposed to follow the standard function. The standard function is not standard, but a GNU extension. Adding some ifdef mess is pointless too - it has no advantages other than having a mess, and not spotting implementation bugs in the emulation due to running it only on "obscure" platforms (like Windows, so most computers actually, except the developer's platform). There is mkstemp(), which at least is in POSIX 2008. But it's 100% useless, except in some obscure cases: it doesn't set O_CLOEXEC, nor can you pass it to it. Without O_CLOEXEC, we'd leak the temporary file to all child processes. (The fact that the file, which is expected to reach double or tripple digit GB sizes, will be deleted only once all processes unreference the FD, makes this sort of a big deal. You could ftruncate() it, but that doesn't fix all the other problems.) Why did POSIX standardize mkstemp() and O_CLOEXEC apparently at the same time, but provided no way to pass O_CLOEXEC to mkstemp()? With the introduction of O_CLOEXEC, they acknowledged that there's a need to atomically set the FD_CLOEXEC flag when creating file descriptors. (FD_CLOEXEC was standard before that, but setting it with fcntl() is racy.) You're much more likely to need a temp file that is CLOEXEC rather than the opposite, and even if they were somehow opposed to CLOEXEC by default (such as for compat. reasons), surely POSIX could have standardized mkostemp() too or instead. And then there's the fact that this whole O_CLOEXEC mess is stupid. Surely there would have been a better way to handle this, instead of requiring adding O_CLOEXEC to almost ALL instances of open() in all code that has been written ever. The justification for this is that the historic default was wrong, and you can't change it (e.g. this won't work: changing the behavior of exec() and not inherit the FD to the child process, unless a hypothetical O_KEEP_EXEC flag is set). But on the other hand, surely you could have introduced an exec() variant which does close all FDs, except a whitelist of FDs passed to it. Let's call it execve2(). In fact, I'm going to argue that exec() call sites are the most aware of whether (and which) FDs to inherit. Some programs even tried to explicitly iterate over all opened FDs and explicitly close "unwanted" FDs (which of course was problematic for other reasons), and such an execve2() call would have been the ideal solution. Maybe this proposed solution would have had problems too. But surely revisiting and reviewing every exec*() call would have been simpler than reviewing every open() call. And more importantly, having to extend every damn library function that either calls open() or creates FDs in some other way, like mkstemp(). What argument are there going to be against this? That there will be library code that can't keep working correctly with processes that use the "old" exec? Well, what about all my legacy library code that uses open() incorrectly, and that will break no matter what? Well, I'm not going to claim that I can come up with better solutions than POSIX (generally or in this case), but this situation is ABSOLUTELY ATROCIOUS. It makes win32 programming look attractive compared to POSIX, that standard pandering to dead people from the past. (Note: not trying to insult dead people.) I'm not sure what POSIX is even doing. Anything useful? Doesn't look like it to me. Are they paid? Why? They didn't even fix the locale mess, nor do they intend to. I bet they're proud of discussing compatibility to 70ies code day in and day out iwtohut ever producing anything useful. What a load of crap. They seriously got to do better than this. Oh, and my wrapper is probably buggy. Fortunately that doesn't matter. Also I'm dumping this into io.h. Originally, io.h was just supposed to replace broken implementation of standard functions by MinGW (and then by Android), but whatever, just give a dumping ground for shit code.
* demux: move comment to slightly better locationwm42019-09-191-1/+1
|
* demux: fix excessive backwards seeking with backwards playbackwm42019-09-191-1/+2
| | | | | | | | | | | | | | | | Backwards demuxing usually seeks back back by a "random" amount (set by a user option) when it needs new preceding packets. It turns out a past change made these backwards seek amounts add up when it didn't need to (i.e. subtracting the amount from the seek pos without properly resetting it), which could possibly slow down playback as it went on. The reason for this was that back_seek_pos was set for every stream on every seek. This made the reset not affect other streams (in particular streams which weren't used and never were reset, or which didn't reset that often). But as the commit adding it showed, this is needed only to set the initial position. So do that. Fixes: "demux: fix initial backward demuxing state in some cases"
* demux: fix minor seek_preroll consistency issuewm42019-09-191-0/+2
| | | | | | | | | When packet appending sets the start of the range, it adjusts the range by seek_preroll. Do this when packets are pruned from the start of the range too. (Yeah, seek_preroll handling is probably broken in some other cases. It was halfhearted to begin with.)
* demux: mess with seek range updates and pruningwm42019-09-193-118/+156
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The main thing this commit does is removing demux_packet.kf_seek_pts. It gets rid of 8 bytes per packet. Which doesn't matter, but whatever. This field was involved with much of seek range updating and pruning, because it tracked the canonical seek PTS (i.e. start PTS) of a packet range. We have to deal with timestamp reordering, and assume the start PTS is the lowest PTS across all packets (not necessarily just the first packet). So knowing this PTS requires looping over all packets of a range (no, the demuxer isn't going to tell us, that would be too sane). Having this as packet field was perfectly fine. I'm just removing it because I started hating extra packet fields recently. Before this commit, this value was cached in the kf_seek_pts field (and computed "incrementally" when adding packets). This commit computes the value on demand (compute_keyframe_times()) by iterating over the placket list. There is some similarity with the state before 10d0963d851fa, where I introduced the kf_seek_pts field - maybe I'm just moving in circles. The commit message claims something about quadratic complexity, but if the code before that had this problem, this new commit doesn't reintroduce it, at least. (See below.) The pruning logic is simplified (I think?) - there is no "incremental" cached pruning decision anymore (next_prune_target is removed), and instead it simply prunes until the next keyframe like it's supposed to. I think this incremental stuff was only there because of very old code that got refactored away before. I don't even know what I was thinking there, it just seems complex. Now the seek range is updated when a keyframe packet is removed. Instead of using the kf_seek_pts field, queue->seek_start is used to determine the stream with the lowest timestamp, which should be pruned first. This is different, but should work well. Doing the same as the previous code would require compute_keyframe_times(), which would introduce quadratic complexity. On the other hand, it's fine to call compute_keyframe_times() when the seek range is recomputed on pruning, because this is called only once per removed keyframe packet. Effectively, this will iterate over the packet list twice instead of once, and with some locality. The same happens when packets are appended - it loops over the recently added packets once again. (And not more often, which would go above linear complexity.) This introduces some "cleverness" with avoiding calling update_seek_ranges() even when keyframe packets added/removed, which is not really tightly coupled to the new code, and could have been in a separate commit. Removing next_prune_target achieves the same as commit b275232141f56, which is hereby reverted (stale is_bof flags prevent seeking before the current range, even if the beginning of the file was pruned). The seek range is now strictly computed after at least one packet was removed, and stale state should not be possible anymore. Range joining may over-allocate the index a little. It tried hard to avoid this before by explicitly freeing the old index before creating a new one. Now it iterates over the old index while adding the entries to the new one, which is simpler, but may allocate twice the memory in the worst case. It's not going to matter for anything, though. Seeking will be slightly slower. It needs to compute the seek PTS values across all packets in the vicinity of the seek target. The previous code also iterated over these packets, but now it iterates one packet range more. Another minor detail is that the special seeking code for SEEK_FORWARD goes away. The seeking code will now iterate over the very last packet range too, even if it's incomplete (i.e. packets are still being appended to it). It's fine that it touches the incomplete range, because the seek_end fields prevent that anything particularly incorrect can happen. On the other hand, SEEK_FORWARD can now consider this as seek target, which the deleted code had to do explicitly, as kf_seek_pts was unset for incomplete packet ranges.
* demux: fix a commentwm42019-09-191-1/+1
| | | | | | | | | Obviously doesn't sense with this order. The git history shows that this comment was touched multiple times, without ever fixing it. It was originally added in 2016, where the "for" was missing. Later, the "for" was added, but to the wrong position. What the fuck?
* demux: cache a valuewm42019-09-191-10/+9
| | | | | Just for readability purposes. Although the field is mutable, it never changes within the function.
* demux: redo timed metadatawm42019-09-196-195/+201
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |