summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* options: make decoder options local to decoder wrapperwm42020-03-016-82/+96
| | | | | | | | | | | | | | | Instead of having f_decoder_wrapper create its own copy of the entire mpv option tree, create a struct local to that file and move all used options to there. movie_aspect is used by the "video-aspect" deprecated property code. I think it's probably better not to remove the property yet, but fortunately it's easy to work around without needing special handling for this option or so. correct_pts is used to prevent use of hr-seek in playloop.c. Ignore that, if you use --no-correct-pts you're asking for trouble anyway. This is the only behavior change.
* 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
* ad_lavc: disable decoder downmix by defaultwm42020-02-292-2/+2
| | | | | | | | Let's see how much everyone hates this. Leaving it enabled seems problematic, because libavcodec returns an unspecific error if it doesn't like it. Fixes: #6300
* player: add optional separate video decoding threadwm42020-02-295-55/+383
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | See manpage additions. This has been a topic in MPlayer/mplayer2/mpv since forever. But since libavcodec multi-threaded decoding was added, I've always considered this pointless. libavcodec requires you to "preload" it with packets, and then you can pretty much avoid blocking on it, if decoding is fast enough. But in some cases, a decoupled decoder thread _might_ help. Users have for example come up with cases where decoding video in a separate process and piping it as raw video to mpv helped. (Or my memory is false, and it was about vapoursynth filtering, who knows.) So let's just see whether this helps with anything. Note that this would have been _much_ easier if libavcodec had an asynchronous (or rather, non-blocking) API. It could probably have easily gained that with a small change to its multi-threading code and a small extension to its API, but I guess not. Unfortunately, this uglifies f_decoder_wrapper quite a lot. Part of this is due to annoying corner cases like legacy frame dropping and hardware decoder state. These could probably be prettified later on. There is also a change in playloop.c: this is because there is a need to coordinate playback resets between demuxer thread, decoder thread, and playback logic. I think this SEEK_BLOCK idea worked out reasonably well. There are still a number of problems. For example, if the demuxer cache is full, the decoder thread will simply block hard until the output queue is full, which interferes with seeking. Could also be improved later. Hardware decoding will probably die in a fire, because it will run out of surfaces quickly. We could reduce the queue to size 1... maybe later. We could update the queue options at runtime easily, but currently I'm not going to bother. I could only have put the lavc wrapper itself on a separate thread. But there is some annoying interaction with EDL and backward playback shit, and also you would have had to loop demuxer packets through the playloop, so this sounded less annoying. The food my mother made for us today was delicious. Because audio uses the same code, also for audio (even if completely pointless). Fixes: #6926
* filter: add async queue filterwm42020-02-294-1/+393
| | | | | | | | | | | | | | | | | | | | | | | | | | This is supposed to enable communication between filter graphs on separate threads. Having multiple threads makes only sense if they can run concurrently with each other, which requires such an asynchronous queue as a building block. (Probably.) The basic idea is that you have two independent filters, which can be each part of separate filter graphs, but which communicate into one direction with an explicit queue. This is rather similar to unix pipes. Just like unix pipes, the queue is limited in size, so that still some data flow control enforced, and runaway memory usage is avoided. This implementation is pretty dumb. In theory, you could avoid avoid waking up the filter graphs in quite a lot of situations. For example, you don't need to wake up the consumer filter if there are already frames queued. Also, you could add "watermarks" that set a threshold at which producer or consumer should be woken up to produce/consume more frames (this would generally serve to "batch" multiple frames at once, instead of performing high-frequency wakeups). But this is hard, so the code is dumb. (I just deleted all related code when I still got situations where wakeups were lost.) This is actually salvaged and modified from a much older branch I had lying around. It will be used in the next commit.
* filter: decide how multi-threading is supposed to workwm42020-02-292-8/+24
| | | | | | | | | | Instead of vague ideas about making different filter graphs on different threads interact directly, this have no direct support. Instead, helpers are required (such as added with the next commit). Document it. Different root filters (i.e. separate filter graphs) are now considered to be part of separate threads, so assert() if they're found to accidentally interact.
* skip-logo.lua: remove lua 5.2 warning messagewm42020-02-291-1/+0
| | | | (OK, I tested it.)
* build: pick up Lua 5.2 by defaultwm42020-02-291-4/+4
| | | | | | | | | | | | Previously: 5.1 > 5.2 > luajit Now: 5.2 > luajit > 5.1 I randomly decided that this should be done, since I suspect most environments will prefer the highest Lua version anyway. There is not much of a point picking the older one by default. Maybe 5.1 should be dropped fully, but considering we need to stay compatible with luajit, there is no particular incentive for this.
* 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.
* ta: fix logging of unfreed child allocationswm42020-02-291-1/+1
| | | | | | Broken since commit f6615f00eeb05f072a. This traversed the data structure incorrectly, and caused a stack overflow due to infinite recursion.
* filter: fix possibly lost async wakeupswm42020-02-291-5/+5
| | | | | | | | | | | mp_filter_mark_async_progress() can asynchronously mark a filter for processing, without waking up the filter thread. (It's some sort of idiotic micro-optimization I guess?) But since it sets async_pending without doing the wakeup, a mp_filter_wakeup() after this will do nothing, and the wakeup is lost. Fix it by checking for the needed wakeup separately. Fortunately, nothing used this function yet, so there is no impact.
* f_decoder_wrapper: replace most public fields with setters/getterswm42020-02-297-68/+125
| | | | | | | | | | | | | | | | | | | I may (optionally) move decoding to a separate thread in a future change. It's a bit attractive to move the entire decoder wrapper to there, so if the demuxer has a new packet, it doesn't have to wake up the main thread, and can directly wake up the decoder. (Although that's bullshit, since there's a queue in between, and libavcodec's multi-threaded decoding plays cross-threads ping pong with packets anyway. On the other hand, the main thread would still have to shuffle the packets around, so whatever, just seems like better design.) As preparation, there shouldn't be any mutable state exposed by the wrapper. But there's still a large number of corner-caseish crap, so just use setters/getters for them. This recorder thing will inherently not work, so it'll have to be disabled if threads are used. This is a bit painful, but probably still the right thing. Like speculatively pulling teeth.
* test: update img_formats.txtwm42020-02-291-6/+27
| | | | | | | | | | | | | This explicitly depends on the pixfmt list from FFmpeg (done so to easily spot regression, incompatible changes, and other unexpected things). Some local changes in mpv change some of the output. For pal8 an alias was added back, and the [GENERIC] markers are removed because the mpv aliases are not dependent on the mpv config anymore (which was unnecessary). The other changes are due to ffmpeg adding some new formats.
* player: remove delayed audio seek thingwm42020-02-293-51/+0
| | | | | | | | | | | | | | | | | | | | | | | | This was a hack that attempted to line up external audio tracks with video. The problem is that if you do a keyframe seek backwards, video will usually seek much farther back than audio (due to much higher keyframe aka seek point distances). The hack somehow made seeking a 2 step process. This existed in 4 different forms in the history of this code base, and it was always very cumbersome. We mostly needed this for ytdl_hook (I think?), which uses the 4th form, which is nicely confined to demux_timeline and is unrelated to the "external" audio tracks in the high level player. Since this is (probably) not really widely needed anymore, get rid of it. Better do this now, than when somehow rewriting all the seeking code (which might happen in this decade or the next or so) and when it wouldn't be easily revertable anymore in case we find we "really" need it unlike expected. There is no issue if hr-seeks are used. Also, you can still use edl files to "bundle" multiple streams as if it was a single stream (this is what ytdl_hook does now).
* 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.)
* osc: use default hr-seek when dragging progress bar to seekwm42020-02-282-7/+11
| | | | | | | The "seekbarkeyframes" option is now interpreted such if it's true, the player default is used. Too lazy to make this a choice option or whatever; the Lua option parser doesn't have support for that anyway. Someone who cares can adjust this.
* player: dumb seeking related stuff, make audio hr-seek defaultwm42020-02-288-49/+74
| | | | | | | | | | | | | | | | | | | | | | | | | | Try to deal with various corner cases. But when I fix one thing, another thing breaks. (And it's 50/50 whether I find the breakage immediately or a few months later.) So results may vary. The default for--hr-seek is changed to "default" (not creative enough to find a better name). In this mode, audio seeking is exact if there is no video, or if the video has only a single frame. This change is actually pretty dumb, since audio frames are usually small enough that exact seeking does not really add much. But it gets rid of some weird special cases. Internally, the most important change is that is_coverart and is_sparse handling is merged. is_sparse was originally just a special case for weird .ts streams that have the corresponding low-level flag set. The idea is that they're pretty similar anyway, so this would reduce the number of corner cases. But I'm not sure if this doesn't break the original intended use case for it (I don't have a sample anyway). This changes last-frame handling, and respects the duration of the last frame only if audio is disabled. This is mostly "coincidental" due to the need to make seeking past EOF trigger player exit, and is caused by setting STATUS_EOF early. On the other hand, this might have been this way before (see removed chunk close to it).
* player: attempt to fix playback end on hr-seeking past EOF againwm42020-02-281-3/+6
| | | | | | | | | | This tries to fix #7206 (hr-seeking past EOF does not stop playback) again. Commit 57fbc9cd76f7 should have fixed this, but trying it again (using that git revision), it often did not work. Whatever the fuck. So add another dumb special case that will break within weeks. Note that the check in handle_eof() had no effect, since execute_queued_seek() is called later, which cancels EOF in the same case.
* player: set playback_pts in hr-seek past EOF casewm42020-02-285-7/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Hr-seek past the last frame instantly enters EOF, which means handle_playback_time() will not set playback_pts to the video PTS (as all video frames are skipped), which leads to the playback time being taken from the last seek target. This results in confusing behavior, especially since the seek time will be clipped to the file duration for display, but not for further relative seeks. Obviously, the time should be set to the last video frame, so use the last video frame as fallback if both audio and video have ended. Also, since the same problem exists with audio-only playback, add a fallback for audio PTS too. We don't know which was the "last" fragment of media played (to decide whether to use the audio or video PTS as the fallback), but it doesn't matter since the maximum works. This could lead to some undesired effects. In particular the audio PTS is basically a bad guess, and is for example not clipped against --end. (But the ridiculous way audio syncing and clamping currently works, I'm not going to touch that shit unless I rewrite it completely.) The cover art case is slightly broken: using --keep-open with keyframe seeks will result in 0 as playback PTS (the video PTS). OK, who cares, it got late. Also casually get rid of last_vo_pts, since that barely made any sense at all. Fixes: #7487
* player: remove stale last frame referenceswm42020-02-281-2/+5
| | | | | | | | | | | | | | | | | The seeking logic saves the last video frame it has seen (for example for being able to seek to the last frame, or backstepping). Unfortunately, the frame was fed back to the filtering pipeline in situations when it shouldn't have. Then it's an out of order frame, because it really saves the last _discarded_ frame. For example, seeking to the end of a file with --keep-open, shift+up, shift+down => invalid video pts warning due to saved_frame being fed back. Explicitly discard saved_frame when it's obviously not needed anymore. The removed accesses to "r" are strictly speaking unrelated (just const-propagating them).
* 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.
* command: remove unintended newlinewm42020-02-271-1/+1
| | | | This just made it print a blank line.
* demux_mkv: document probe-start-time option and enable it by defaultwm42020-02-272-1/+8
| | | | | | | | | | | | 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-272-27/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* *.py: cosmetic changesjnozsc2020-02-279-32/+40
|
* sub: do not ignore demuxer wakeupswm42020-02-271-6/+7
| | | | | | | | | | | | | | | | | | Setting demux_set_stream_wakeup_cb() will make all sh_stream (i.e. track) specific wakeups go to this callback. But the callback takes care of only the sub_preload() case (where it tries to pre-load subtitles from already parsed and memory-present subtitles in a blocking way). The old code assumed that the normal demuxer wakeup callback is called. This was disregarded when the newer code was added. (And actually, the original plan was to make _all_ per-sh_stream wakeups go to specialized callbacks to avoid wasted work. dec_sub really should set the callback always, and propagate wakeups to the playloop code. But it's too far into the night to write coherent code.) I couldn't actually observe any manifestation of this bug. Normally, the playloop wakes up for other reasons (such as driving audio and video decoding), so the lost wakeups rarely matter.
* sub: fix typo in commentwm42020-02-271-1/+1
| | | | | Reading this commit and this commit message is a waste of time. I guarantee it.
* sub, demux: improve behavior with negative subtitle delay/muxed subswm42020-02-273-8/+48
| | | | | | | | | | | | | | | | | | | | | | | | 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.
* scripting: fix racy crash if loading .run files failswm42020-02-251-0/+3
| | | | | | | | | args->client was deallocated if the FDs were closed and nothing referenced it (IPC socket codes detected the closed sockets and asynchronously killed the mpv_handle in args->client). The problem was that args->log depended on it, and was also destroyed. Fix this by duplicating the mp_log.
* OpenGL: Also detect softpipe as a software driverlinkmauve2020-02-251-0/+1
| | | Because it is.
* ipc: allow sending commands with named argumentswm42020-02-242-23/+33
| | | | | | | | | | | | | | This has been part of the libmpv for a while, so the implementation in the IPC code is quite simple: just pass the mpv_node representing the value of the "command" field without further checks to mpv_command_node(). The only problem are the IPC-specific commands, which essentially have their own dispatch mechanism. They expect an array. I'm not going to rewrite the dispatch mechanism, so these still work only with an array. I decided make the other case explicit with cmd==NULL. (I could also have set cmd=="", which would have avoided changing each if condition since "" matches no existing command, but that felt dirty.)
* ipc: add more blabla that nobody readswm42020-02-241-0/+23
|
* ipc: implement asynchronous commandswm42020-02-242-11/+90
| | | | | | | | | | | I decided to make this explicit. The alternative would have been making all commands asynchronous always, like a small note in the manpage threatened. I think that could have caused compatibility issues. As a design decision, this does not send a reply if an async command started. This could be a good or bad idea, but in any case, it will make async command look almost like synchronous ones, except they don't block the IPC protocol.
* client API: minor clarification when asynchronous commands send eventswm42020-02-241-0/+5
|
* ta: remove two pointless wrapperswm42020-02-234-7/+3
|
* ta: minor simplificationwm42020-02-231-2/+1
| | | | | Due to the ta_header.parent invariant, the "h->parent->child==h" check is always true.
* client API: fix race condition on client exitwm42020-02-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | The relatively recently added property update code has a race condition when clients exit. It still tried to access mpv_handle during and after it was destroyed. The reason is that it unlocks the lock for the mpv_handle list (while mpv_handle is locked), but nothing in mp_destroy_client() cares about this case. The latter function locks mpv_handle only before/while it makes sure all of its activity is coming to an end, such as asynchronous requests, and property updates that are in progress. It did not include the case when mp_client_send_property_changes() was still calling send_client_property_changes() with mpv_handle locked. Fix this by checking the mpv_handle.destroying field. This field can be set only when mpv_handle is locked. While we're checking the lock, the mpv_handle list is still locked, so at worst we might be at the point before mp_destroy_client() locks the list again and finally destroys the mpv_handle. This is a hard to reproduce race condition which I spotted only once in valgrind by chance, so the fix is unconfirmed.
* ta: change API; ta_set_parent() and ta_set_destructor() never failwm42020-02-233-45/+22
| | | | | | The previous change ensured that these cannot fail anymore (much like in original talloc). Change the APIs to not return a success value anymore, to "cement" this.
* ta: remove seperate internal "ext" headerwm42020-02-231-79/+54
| | | | | | | | | | | | | | | | | | | | | | | | The ta_ext_header was allocated on demand for allocations which have child-allocations or destructors. In theory, it saved 2 words for every TA leaf allocation. It had the very API-visible problem that setting a parent or destructor could fail. (Although in most cases, the failure was part of an allocation call anyway. Also, mpv code generally used the early-failure variants, so it didn't matter.) I think this was a bit too complex. These 2 words don't really matter; if you have memory allocations where you are worried about overhead, then these simply shouldn't use TA. Also, we never added new features to TA that would have nee