summaryrefslogtreecommitdiffstats
path: root/player
<
Commit message (Collapse)AuthorAgeFilesLines
* options: make decoder options local to decoder wrapperwm42020-03-013-20/+3
| | | | | | | | | | | | | | | 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.
* player: add optional separate video decoding threadwm42020-02-291-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* f_decoder_wrapper: replace most public fields with setters/getterswm42020-02-295-19/+26
| | | | | | | | | | | | | | | | | | | 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.
* 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).
* osc: use default hr-seek when dragging progress bar to seekwm42020-02-281-2/+5
| | | | | | | 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-286-47/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | 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).
* command: remove unintended newlinewm42020-02-271-1/+1
| | | | This just made it print a blank line.
* 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.
* ta: remove two pointless wrapperswm42020-02-232-2/+2
|
* 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.
* ytdl_hook: fix URL extraction for manifestssfan52020-02-231-4/+4
|
* ytdl_hook: prefer "format" over "format_note" field for track titleswm42020-02-211-1/+1
| | | | | Much more verbose, but on the other hand format_note is useless for the alphabetic site with fragmented DASH streams.
* ytdl_hook: use "format" as fallback for "format_note" for stream titleswm42020-02-211-1/+1
| | | | | "format_note" normally contains a semi-informative description of the format. But some extractors, confusingly, have it in the "format" field.
* ytdl_hook: fix audio codec with some extractorswm42020-02-211-5/+11
| | | | | E.g. soundcloud. While it still worked, not having the audio codec was pretty annoying.
* ytdl_hook: fix Lua escapeswm42020-02-211-3/+3
| | | | | | This was obviously nonsense. In Lua 5.1 this appeared to work correctly, but it really turned "\." into "." (making the pattern accept any character). The proper way is using "%" for escaping.
* ytdl_hook, edl: add fps, samplerate codec parameterswm42020-02-211-2/+9
| | | | Well, didn't help much in the case I was interested it.
* ytdl_hook: make codec mapping more declarativewm42020-02-211-12/+9
|
* ytdl_hook: remove some old playlist redirection hackwm42020-02-211-6/+0
| | | | Should not be needed anymore. In fact, it's probably dangerous.
* ytdl_hook: enable default selection via --ytdl-format with all_formatswm42020-02-211-1/+25
| | | | | | | | | In all_formats mode, we've ignored what --ytdl-format did so far, since we've converted the full format list, instead of just the formats selected by youtube-dl. But we can easily restore --ytdl-format behavior: just mark the selected tracks as default tracks.
* ytdl_hook: add length parameter to delay-loaded tracks only oncewm42020-02-211-3/+3
| | | | | This was done for each media type, so muxed tracks had it twice, which logged a dumb warning. Move it out of the per-media type loop.
* ytdl_hook: remove bitrate estimation from file sizewm42020-02-211-4/+0
| | | | | I think this is unnecessary, and at worst done by youtube-dl itself (didn't check).
* ytdl_hook: use tbr for all tracks if vbr/abr not availablewm42020-02-211-0/+9
| | | | | | | | | | | | | | | | | | vbr and abr are the video and audio bitrates. Sometimes there is a weird mix of any of them available, but in these cases, it's not good to fall back to tbr if a specific track has no vbr/abr. For example, the alphabetic site provides tbr only for the muxed fallback stream, but using tbr would make the primitive mpv hls_bitrate selection pick the compatibility stream for audio, because it appears to have a higher bitrate than the other audio-only streams (because the bitrate includes video). So we must not use tbr in this case. On the other hand, formats coming from youtube-dl HLS master playlist use will only have tbr set. So as a heuristic, use the tbr only if it's the only bitrate available in any track entry.
* ytdl_hook: replace skip_muxed with force_all_formats optionwm42020-02-211-26/+10
| | | | | | | | | | | | | I don't think the skip_muxed option was overlay useful. While it was nice to filter out the low quality muxed versions (as it happens on the alphabetic site, I suspect it's compatibility stuff), it's not really necessary, and just makes for another tricky and rarely used configuration option. (This was different before muxed tracks were also delay-loaded, and including the muxed versions slowed down loading.) Add the force_all_formats option instead, which handles the HLS case. Set it to true because they are also delay-loaded now, and don't slow down startup as much.
* ytdl_hook: delay-load interleaved fileswm42020-02-211-23/+36
| | | | | | (Or if it's about HLS, just "muxed"/multiplexed streams.) This only affects all_formats=yes,skip_muxed=no modes.
* ytdl_hook: signal duration in all_formats modewm42020-02-201-1/+6
| | | | | | If all streams were delay loaded, there was actually no duration present at all in the EDL metadata. So the length was considered unknown by the player frontend.
* ytdl_hook: attempt to filter out muxed streams if all_formats is usedwm42020-02-201-74/+147
| | | | | | | | | | | | | See manpage additions. We would have to extend delay_open to support multiple sub-tracks (for audio and video), and we'd still don't know (?) whether it might contain more than one stream each (thinking of HLS master streams). And if it's a true interleaved file (such as a "normal" mp4 file provided as fallback for more primitive players), we'd either have to signal such "bundled" tracks, or waste bandwidth. This restructures a lot. The if/else tree in add_single_video for format selection was a bit annoying, so it's split into separate if blocks, where it checks each time whether a URL was determined yet.
* ytdl_hook: remove forgotten debug messagewm42020-02-201-1/+0
| | | | It even has a typo.
* ytdl_hook: use bitrate fields for bitrate metadata instead of file sizeswm42020-02-201-1/+8
| | | | If available.
* ytdl_hook: try to skip interleaved streams with all_formatswm42020-02-201-2/+11
| | | | | | | | | | | | | | | | | If a "format" has both audio and video codec set, it might contain both audio and video. all_format assumes that each format is just a quality variant containing a single track. This seems to happen with sites that provide a HLS master URL. youtube-dl tends to "butcher" it, and the result isn't very ideal. I guess HLS "renditions" simply don't map well to youtube-dl's output format and what mpv expects. Playing master HLS directly is also less than ideal, because of libavformat's stupid probing. Fix this by not using the delay-opening mechanism if it appears like we detected such a case. Add a metadata override to set the track titles to "muxed-N", to indicate that they form a single unit. (Mostly helpful for testing.)
* ytdl_hook: iterate format list by array orderwm42020-02-201-1/+1
| | | | | Shouldn't have any consequences. Probably makes the user-visible order more stable.
* player: change bitrate in track listing back to kilobitswm42020-02-201-1/+1
| | | | Because the --hls-bitrate option takes the same unit.
* scripting: add a way to run sub processes as "scripts"wm42020-02-192-10/+80
| | | | | | | | | | This is just a more convenient way to start IPC client scripts per mpv instance. Does not work on Windows, although it could if the subprocess and IPC parts are implemented (and I guess .exe/.bat suffixes are required). Also untested whether it builds on Windows. A lot of other things are untested too, so don't complain.
* ytdl_hook: add all_formats optionwm42020-02-191-18/+85
| | | | | | | | | Pretty worthless I guess. I only tested one site (and 2 videos), it's somewhat likely that it will break with other sites. Even if you leave the option disabled (the default). Slightly related to #3548. This will allows you to use the bitrate stream selection mechanism, that was added for HLS, with normal videos.
* ytdl_hook: add a way to not pass --format to the command linewm42020-02-191-2/+5
| | | | Might be helpful for... whatever.
* player: print manifest per-stream bitrate information to terminalwm42020-02-191-0/+2
| | | | | Aka hls-bitrate. In turn, remove the demux_lavf.c hack, which made the track title use this.
* audio: remove outdated commentwm42020-02-191-2/+0
| | | | | | Neither does it (directly) mess with filters, nor does it return a bool. As noticed by a comment in #6333.
* sub: make filter_sdh a "proper" filter, allow runtime changeswm42020-02-161-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Until now, filter_sdh was simply a function that was called by sd_ass directly (if enabled). I want to add another filter, so it's time to turn this into a somewhat more general subtitle filtering infrastructure. I pondered whether to reuse the audio/video filtering stuff - but better not. Also, since subtitles are horrible and tend to refuse proper abstraction, it's still messed into sd_ass, instead of working on the dec_sub.c level. Actually mpv used to have subtitle "filters" and even made subtitle converters part of it, but it was fairly horrible, so don't do that again. In addition, make runtime changes possible. Since this was supposed to be a quick hack, I just decided to put all subtitle filter options into a separate option group (=> simpler change notification), to manually push the change through the playloop (like it was sort of before for OSD options), and to recreate the sub filter chain completely in every change. Should be good enough. One strangeness is that due to prefetching and such, most subtitle packets (or those some time ahead) are actually done filtering when we change, so the user still needs to manually seek to actually refresh everything. And since subtitle data is usually cached in ASS_Track (for other terrible but user-friendly reasons), we also must clear the subtitle data, but of course only on seek, since otherwise all subtitles would just disappear. What a fucking mess, but such is life. We could trigger a "refresh seek" to make this more automatic, but I don't feel like it currently. This is slightly inefficient (lots of allocations and copying), but I decided that it doesn't matter. Could matter slightly for crazy ASS subtitles that render with thousands of events. Not very well tested. Still seems to work, but I didn't have many test cases.
* ytdl_hook.lua: delay load subtitleswm42020-02-151-2/+12
| | | | | | | | | | | | | | | | Uses the infrastructure added in the previous commits. This is admittedly a bit weird (constructing EDL URLs and such). But on the other hand, adding this as "first class" mechanism directly to the sub-add command or so would increase weirdness and unexpected behavior in other places, or at least that's what I think. To reduce confusion, this goes through the effort of mapping the webvtt codec, so it's shown "properly" in the codec list. Without this it would show "null", but still work. In particular, any non-webvtt codecs should still work if libavcodec supports it. Not sure if I should remove the --all-subs hack from the code. But I guess it does no harm.
* audio: slightly simplify pull underrun message printingwm42020-02-131-1/+4
| | | | | | | | | | | | | | | A previous commit moved the underrun reporting to report_underruns(), and called it from get_space(). One reason was that I worried about printing a log message from a "realtime" callback, so I tried to move it out of the way. (Though there's little justification other than a bad feeling. While an older version of the pull code tried to avoid any mutexes at all in the callback to accommodate "requirements" from APIs like jackaudio, we gave up on that. Nobody has complained yet.) Simplify this and move underrun reporting back to the callback. But instead of printing the message from there, move the message into the playloop. Change the message slightly, because ao->log is inaccessible, and without the log prefix (e.g. "[ao/alsa]"), some context is missing.
* player: consider audio buffer if AO driver does not report underrunswm42020-02-131-6/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | AOs can report audio underruns, but only ao_alsa and ao_sdl (???) currently do so. If the AO was marked as not reporting it, the cache state was used to determine whether playback was interrupted due to slow input. This caused problems in some cases, such as video with very low video frame rate: when a new frame is displayed, a new frame has to be decoded, and since there it's so much further into the file (long frame durations), the cache gets into an underrun state for a short moment, even though both audio and video are playing fine. Enlarging the audio buffer didn't help. Fix this by making all AOs report underruns. If the AO driver does not report underruns, fall back to using the buffer state. pull.c behavior is slightly changed. Pull AOs are normally intended to be used by pseudo-realtime audio APIs that fetch an audio buffer from the API user via callback. I think it makes no sense to consider a buffer underflow not an underrun in any situation, since we return silence to the reader. (OK, maybe the reader could check the return value? But let's not go there as long as there's no implementation.) Remove the flag from ao_sdl.c, since it just worked via the generic mechanism. Make the redundant underrun message verbose only. push.c seems to log a redundant underflow message when resuming (because somehow ao_play_data() is called when there's still no new data in the buffer). But since ao_alsa does its own underrun reporting, and I only use ao_alsa, I don't really care. Also in all my tests, there seemed to be a rather high delay until the underflow was logged (with audio only). I have no idea why this happened and didn't try to debug this, but there's probably something wrong somewhere. This commit may cause random regressions. See: #7440
* player: add ab-loop-count option/propertywm42020-02-083-1/+9
| | | | | | | | | | | | As requested I guess. It behaves quite similar to the --loop* options. Not quite happy with the idea that 1) the option is mutated on each operation (but at least it's consistent with --loop* and doesn't require more properties), and 2) the ab-loop command will do nothing once all loop iterations are done. As a concession, the OSD shows something about "disabled". Fixes: #7360
* js: require: directory-scripts: first look at <dir>/modules/Avi Halachmi (:avih)2020-02-072-0/+10
| | | | | Also, add the function mp.get_script_directory() to let scripts know if they're loaded as a directory and where.
* js: require: don't use ~~/scripts/modules.js/Avi Halachmi (:avih)2020-02-071-1/+6
| | | | | | | | | Directories inside ~~/scripts/ are now loaded as scripts, so don't use it also for modules. Now there are no default module paths. To compensate, we now try to run ~~/.init.js right after defaults.js, so the user may extend the js init procedure via this script, e.g. for adding default paths to mp.module_paths .