summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* 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.
* stream_file: remove file size cachingwm42020-02-161-14/+7
| | | | With the last 3 commits, this caching should be completely unnecessary.
* 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.
* stream_file: use fstat() instead of lseek() to determine file sizewm42020-02-161-3/+8
| | | | | | | | | | | | | | | It appears using lseek() to seek to the end and back to determine file size is inefficient in some cases. With CIFS, this restores the performance regression that happened when the stream cache was removed (which called read() from a thread). This is probably faster than the old code too, because it's the seeking that was slowing down CIFS. According to the user who tested this, the size caching does not help with fstat() (although it did with the old method). Fixes: #7408, #7152
* manpage: improve command_native_async descriptionwm42020-02-161-6/+13
|
* subprocess: implement proper detached processes on POSIXwm42020-02-163-10/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The previous method for this sucked: for every launched detached process, it started a thread, which then would leak if the launched process didn't end before the player uninitialized. This was very racy (although I bet the race condition wouldn't trigger in a 100 years), and wasteful (threads aren't a cheap resource). Implement it for POSIX directly. posix_spawn() has no direct support for this, so we need to do it ourselves with fork(). We could probably do it without fork(), and attempt to collect the PID in another thread. But then we'd either have a waiting thread again, or we'd need to do an unsafe waitpid(-1, ...) call. (POSIX process management sucks so badly, how did they even manage this. Hopefully I'm just missing something, but I'm not.) So now we depend on both posix_spawn() _and_ fork(), isn't it fun? Also call setsid(), to essentially detach the child process from the terminal. (Otherwise it can receive various signals from the terminal, which is probably not what you want.) posix_spawn() adds POSIX_SPAWN_SETSID in newer POSIX releases, but we don't want to rely on this yet. The posix_spawnp() call is duplicated, but this is better than somehow trying to unify the code paths. Only somewhat tested, so enjoy the bugs.
* subprocess: change to a fancier APIwm42020-02-163-83/+185
| | | | | | | | | | | | | | Introduce mp_subprocess() and related definitions. This is a bit more flexible than the old stuff. This may or may not be used for a more complicated feature that involves starting processes, and which would require more control. Only port subprocess-posix.c to this API. The player still uses the "old" API, so for win32 and dummy implementations, the new API is simply not available, while for POSIX, the old APIs are emulated on top of the new one. I'm hoping the win32 code can be ported as well, so the ifdefs in subprocess.c can be dropped, and the player can (if convenient or needed) use the new API.
* f_lavfi: don't propagate filter failure if creation failswm42020-02-161-3/+0
| | | | | | | | | | | | | Filters that fail to create are not supposed to do this. Generally it should happen in process() only. This fixes the previous commit. If a filter could not be created, it "trashed" the wrapper filter with the failure. (Even if the wrapper were to handle were to handle failures of sub-filter, it couldn't handle init failure because it cannot call mp_filter_set_error_handler() before the newly created filter is actually returned.) Fixes: #7465 (attempt 2)
* f_auto_filters: always fall back to hw-download+yadif if no hw deint filterwm42020-02-161-3/+8
| | | | | | | | | | | If hw decoding is used, but no hw deinterlacer is available, even though we expect that it is present, fall back to using hw-download and yadif anyway. Until now, it was over if the hw filter was somehow missing; for example, yadif_cuda apparently requires a full Cuda SDK, so it can be missing, even if nvdec is available. (Whether this particular case works was not tested with this commit.) Fixes: #7465
* Remove remains of Libav compatibilitywm42020-02-1621-257/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* sub: add an option to filter subtitles by regexwm42020-02-167-0/+160
| | | | | | | | | | | | | | | | | | | | Works as ad-filter. I had some more plans, for example replacing matching text with different text, but for now it's dropping matches only. There's a big warning in the manpage that I might change semantics. For example, I might turn it into a primitive sed. In a sane world, you'd probably write a simple script that processes downloaded subtitles before giving them to mpv, and avoid all this complexity. But we don't live in a sane world, and the sooner you learn this, the happier you will be. (But I also want to run this on muxed subtitles.) This is pretty straightforward. We use POSIX regexes, which are readily available without additional pain or dependencies. This also means it's (apparently) not available on win32 (MinGW). The regex list is because I hate big monolithic regexes, and this makes it slightly better. Very superficially tested.
* sub: make filter_sdh a "proper" filter, allow runtime changeswm42020-02-169-50/+217
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* TOOLS/lua/autoload.lua: update script commentsThomas Carmichael2020-02-151-6/+6
| | | | | | | | | The example configuration uses values of true/false for the script options. As per DOCS/man/lua.rst boolean values should be represented with yes/no and using true/false will result in an error. This updates the comments and changes the true/false values under the example configuration to yes/no.
* manpage: fix a case of broken indentationwm42020-02-151-15/+16
| | | | | | This renders incorrectly in the html output. I suspect you need one more level here. Increase the indentation level. No other changes, other than re-breaking some lines.
* 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.
* f_decoder_wrapper, sd_add: accept "null" codecwm42020-02-152-2/+12
| | | | | | | | | | | | | This is for easier use with the "delay_open" feature added in the previous commit. The "null" codec is reported if the codec is unknown (because the stream was not opened yet at time the tracks were added). The rest of the timeline mechanism will set the correct codec at runtime. But this means every time a delay-loaded track is selected, it wants to initialize a decoder for the "null" codec. Accept a "null" decoder. But since FFmpeg has no such codec, and out of my own laziness, just let it fall back to "common" codecs that need no other initialization data.
* edl: add mechanism for delay loading streamswm42020-02-155-33/+219
| | | | | | | | | | | | | Add something that will access an URL embedded in EDL only when the track it corresponds to is actually selected. This is meant to help with ytdl_hook.lua and to improve loading speeds. In theory, all this stuff is available to any mpv user, but discourage using it, as it's so specialized towards ytdl_hook.lua, that there's danger we'll just break this once ytdl_hook.lua stops using it, or similar. Mostly untested.
* demux_edl: warn if no_clip is used with multiple partswm42020-02-152-1/+5
| | | | Well whatever.
* demux_edl: allow a redundant new_stream at the beginningwm42020-02-152-1/+16
| | | | | | | Normally, the first sub-stream is implicitly created. This change lets the user use more orthogonal syntax, and use a new_stream header for every sub-stream, instead of having to skip the header for the first one.
* demux_edl: accept protocol entries in EDL entries againwm42020-02-151-1/+4
| | | | | | Accidentally broken by commit 99700bc52c1317. mp_path_join() does not check for this, because it's supposed to work on filesystem strings (and e.g. "http://fubar" is a valid relative path in UNIX).
* demux_edl: improve parsing slightlywm42020-02-152-46/+101
| | | | | | | | | | | Add a mp_log context to the parse_edl() function, and report some errors. Previously, this just told you that something was wrong. Add some error reporting to make it slightly less evil. Put all parameters in a list before processing them. This makes adding parameters for special headers easier, and we can report parameters that were not understood. (For "compatibility", which probably doesn't matter at all, still don't count them as errors; as before.)
* demux_timeline: fix another cursed memory management issuewm42020-02-151-3/+7
| | | | | | | | | | | | | The timeline stuff has messed up memory management because there are no clear ownership rules between a some demuxer instances (master or demux_timeline) and the timeline object itself. This is another subtle problem that happened: apparently, demux_timeline.open is supposed to take over ownership of timeline, but only on success. If it fails, it's not supposed to free it. It didn't follow this, which lead to a double-free if demux_timeline.open failed. The failure path in demux.c calls both timeline_destroy() and demux_timeline.close on failure.
* demux_timeline: fix a commentwm42020-02-151-2/+2
|
* demux_timeline: reorder some functionswm42020-02-151-157/+153
| | | | | | Move them around in the source code to get rid of the forward declarations. Other than rearranging the lines and removing the 2 forward declarations, there are no other changes at all.
* msg: slightly improve --msg-time outputwm42020-02-142-2/+5
| | | | Cut the arbitrary offset, and document what unit/timesource it uses.
* stream: early-out in stream_seek_skip() if nothing is skippedwm42020-02-141-2/+7
| | | | | | | stream_seek() might somewhat show up in the profiler, even if it's a no-OP, because of the MP_TRACE() call. I find this annoying. Otherwise, this should be of no consequence, and should not break or improve anything.
* stream_file: cache file sizewm42020-02-141-4/+11
| | | | | | | | | | | | | | | | | | | | | Some cache logic in demux.c queries the raw byte stream size on every packet read. This is because it reports the value to the user. (It has to be polled like this because there is no change notification in most underlying I/O APIs, and also the user can't just block on the demuxer thread to update it explicitly.) This causes a very high number of get_size calls with low packet sizes, so cache the size, and update it on every read. Reads only happen approximately all 64KB read with default settings, which is way less frequent than every packet in such extreme cases. In theory, this could in theory cause problems in some cases. Actually this is whole commit complete non-sense, because why micro-optimize for broken cases like patent troll codecs. I don't need to justify it anyway. As a minor detail, off_t is actually specified as signed, so the off_t cast is never needed.
* manpage: clarify --player-operation-modewm42020-02-142-6/+13
| | | | | | | options.rst to clarify the option, some more text in mpv.rst to separate out the compatibility stuff a little. Fixes: #7461 (options.rst change only)
* wayland: make resizing betterDudemanguy2020-02-132-6/+32
| | | | | | | | | Resizing the window while preserving the aspect ratio actually kind of sucked. The window size could make big dramatic changes which was pretty unintuitive with respect to where the mouse was actually located. Instead, let's just do some math to ensure that the window size is always contained inside the width/height reported by handle_toplevel_config while preserving the aspect ratio. Fixes #7426.
* audio: slightly simplify pull underrun message printingwm42020-02-133-20/+11
| | | | | | | | | | | | | | | 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.
* wayland: fix autofit and rotating issuesDudemanguy2020-02-131-5/+7
| | | | | | Fixes #7441. Just set screenrc to be equal to current_output's geometry. Also remove some pointless/extra variables and print a warning/fallback to screen 0 if a bad id is passed to --fs-screen.
* player: consider audio buffer if AO driver does not report underrunswm42020-02-138-23/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* ao: avoid unnecessary wakeupswm42020-02-133-9/+14
| | | | | | | | | | | | | If ao_add_events() is used, but all events flags are already set, then we don't need to wakeup the core again. Also, make the underrun message "exact" by avoiding the race condition mentioned in the comment. Avoiding redundant wakeups is not really worth the trouble, and it's actually just a bonus in the change making the ao_underrun_event() function return whether a new underrun was set, which is needed by the following commit.
* zimg: fix previous odd sizes commitwm42020-02-131-4/+2
| | | | | | | | | Obviously, we don't want to lose fractions, and the zimg active_region fields in fact have the type double. The integer division was wrong. Also, always set active_region.width/height. It appears zimg behavior does not change if they're set to the normal integer values, so the extra check to not set them in this case was worthless.
* manpage: fix typo on sub-endwm42020-02-121-1/+1
| | | | Fixes: #7455
* sws_utils: use zimg by default if availablewm42020-02-123-7/+6
| | | | | This seems stable enough to use. Change the default, and remove it from the sw-fast profile.
* zimg: correct output to odd (chroma un-aligned) sizeswm42020-02-121-10/+18
| | | | | | | | | | As suggested by the zimg author: active_region is not supported on outputs (and the API returns an error), so instead scale to the "full" surface, but adjust the source rectangle such that the cropped output image happens to cover the correct region. Does this even work? Since Balmer Peak doesn't work, I can't really say, but it seems to look correct.
* zimg: fix typos in a commentwm42020-02-121-3/+2
| | | | | | Also remove the "o" case, which was never implemented (probably was an idea to output alpha formats, now obsoleted by zimg's full alpha support).
* vo_drm, wo_wlshm: mention that it's software scalingwm42020-02-112-2/+2
| | | | (But does anyone even read --vo=help output?)
* vo_x11: don't call X11 "crap"wm42020-02-111-1/+1
| | | | | | X11 is in fact beautiful and superior to Wayland. Instead, just state what the problem is in most cases: software scaling. (We have accelerated X11 rendering in vo_gpu and others.)
* zimg: add pal8 unpackerwm42020-02-101-0/+39
| | | | Some pngs are paletted, so this is vaguely interesting.
* img_format: add alias for ffmpeg pal8 formatwm42020-02-102-0/+4
| | | | For the next commit.
* manpage: add some blabla about zimg speed vs. libswscalewm42020-02-101-1/+10
| | | | | Of course nobody will read this. I'm just putting it there so I can blame users, who run into problems, for not having read it.
* zimg: rename zplanes fieldwm42020-02-101-4/+4
| | | | | | | | | This was a confusing name, because 1. there's also a z_planes[] field, and 2. it was not specific to zimg indexes. Possibly there used to be an idea involved about supporting alpha to non-alpha formats by discarding the alpha plane, but zimg does this now (and zimg will correctly blend the alpha component too).
* zimg: support gray/alpha conversionwm42020-02-101-6/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | The special thing about this format is 1. mpv assigns the component ID 4 to alpha, and component IDs 2 and 3 are not present, which causes some messy details. 2. zimg always wants the alpha plane as plane 3, and plane 1 and 2 are not present, while FFmpeg/mpv put the alpha plane as plane 1. In theory, 2. could be avoided, since FFmpeg actually doesn't have a any 2 plane formats (alpha is either packed, or plane 3). But having to skip "empty" planes would break expectations. zplanes is not equivalent to the mpv plane count (actually it was always used this way), while zimg does not really have a plane count, but does, in this case, only use plane 0 and 3, while 2 and 3 are unused and unset. z_planes[] (not zplanes) is now always valid for all 4 array entries (because it uses zimg indexes), but a -1 entry means it's an unused plane. I wonder if these conventions taken by mpv/zimg are not just causing extra work. Maybe component IDs should just be indexes by the "natural" order (e.g. R-G-B-A, Y-U-V-A, Y-A), and alpha should be represented as a field that specifies the component ID for it, or just strictly assume that 2/4 component formats always use the last component for alpha.
* zimg: fix some confusion about plane permutationwm42020-02-101-4/+9
| | | | | | | | | | | | | We reorder the planes between mpv and zimg conventions. It turns out the code still confused when which convention was used. So the way it actually works is that the _only_ place where zimg order is used is the zimg_image_buffer.plane[] array. plane_aligned[] and zmask[] were accessed incorrectly, although I guess it rarely had a reason to fail (plane reordering is mostly for RGB, which has planes of all the same size). Adjust some comments accordingly too.
* img_format: add gray/alpha planar formatswm42020-02-103-2/+88
|