summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* disable file size cachingstream_no_size_cachingwm42020-02-161-2/+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
| | | | | | | | | | | | The zimg wrapper "needs" these formats as intermediary when repacking the normal gray/alpha packed format. The packed format is used by the png decoder and encoder, and is thus interesting. Unfortunately, mpv-only formats are a mess right now, because all the existing code is focused around using the FFmpeg metadata for pixel formats. This should be improved, but not now, so make the mess worse. This commit doesn't add support for it to the zimg wrapper yet.
* zimg: add alpha supportwm42020-02-092-18/+69
| | | | | | | | | | | libzimg recently added direct alpha support and new API for it. (The API change is rather minimal, and it turns out we can easily support old and new zimg versions.) This does not support _all_ alpha formats. For example, gray + alpha is not supported yet, because my stupid design in the zimg wrapper would require a planar gray + alpha format, while ffmpeg provides only a packed one.
* vo: fix typo in commentwm42020-02-091-1/+1
|
* vf_format: add w, h parameterswm42020-02-092-3/+15
| | | | Yes, this thing became vf_scale through the back door.
* sub: enhance SDH filteringDan Oscarsson2020-02-091-0/+8
| | | | | It is not uncommon with a speaker label with [xxxx] inside. They should also be filtered out.
* github: fix a typo in the contact links infoder richter2020-02-091-2/+2
|
* github: ask users to first reproduce the issue with --no-configder richter2020-02-094-0/+12
|
* mac: always include the macOS config when cocoa is availableder richter2020-02-091-1/+1
| | | | | | | | | | the macOS config was only used in cocoa-cb before and only included when it was available. since this config is meant for general macOS options and backend independent options we include it when cocoa is available. one of the options is already used in the old cocoa backend, which broke using it when build without swift or cocoa-cb support. Fixes #7449
* bash completion: complete ao/af/vo/vf optionsPhilip Langdale2020-02-081-1/+1
| | | | | I didn't handle these originally, but it turns out that they can be handled with the samel logic as Choice options.
* bash completion: Cache the options listPhilip Langdale2020-02-081-8/+11
| | | | | | The bash completion seems to be working decently at this point, so I feel comfortable caching the options output to improve the performance of the completion.
* sub: fix SDH filtering after changeDan Oscarsson2020-02-081-1/+1
| | | | | | | | The change, in an earlier commit, in format for ass to handle results in a different number of fields to skip. Correct that so SDH filtering works. Should fix issue #7188
* player: add ab-loop-count option/propertywm42020-02-086-1/+21
| | | | | | | | | | | | 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
*