summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* stream: fix typos in a commentswm42019-11-072-4/+4
|
* stream: remove eof getterwm42019-11-072-6/+1
| | | | | | | demux_mkv was the only thing using this, and everything else accessed it directly. No need to keep the indirection wrapper around. (Funny how this getter was in the initial commit of MPlayer.)
* vo_gpu: unconditionally clear framebuffer on start of framewm42019-11-061-5/+3
| | | | | | | | | | | | | | | | | | | | | | For some reason, the first frame displayed on X11 with amdgpu and OpenGL will be garbled. This is especially visible if the player starts, displays a frame, but then still takes a while to properly start playback. With --interpolation, the behavior somehow changes (usually gets worse). I'm not sure what exactly is going on, and the code in video.c is way too abstruse. Maybe there is some slight possibility that a frame with uncleared contents gets displayed, which somehow also corrupts another frame that is displayed immediately after that. If clear is unconditionally run, this somehow doesn't happen, and you see a video frame. By any logic this shouldn't happen: a video frame should always overwrite the background. So I can't exclude that this isn't some sort of driver bug, or at least very obscure interaction. Clearing should be practically free anyway, so always do it. Fixes: #7105
* stream: bump default buffer size from 2K to 64Kwm42019-11-062-2/+2
| | | | | | | | | (Only half of the buffer is actually used in a useful way, see manpage or commit which added the option.) Might have some advantages with broken network filesystem drivers. See: #6802
* stream: remove inline buffer optimizationwm42019-11-062-18/+9
| | | | | | | | | | Was probably worthless, and I can't measure a difference anymore (I used to be able and it still seemed worth doing so back then). When the default buffer size is enlarged in the next commit, the inline buffer probably won't even be useful in theory, because the data will rarely be on the same page as the other stream fields. It surely makes the inline buffer seem like a ridiculous micro-optimization. Farewell...
* stream: turn into a ring buffer, make size configurablewm42019-11-0613-178/+317
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In some corner cases (see #6802), it can be beneficial to use a larger stream buffer size. Use this as argument to rewrite everything for no reason. Turn stream.c itself into a ring buffer, with configurable size. The latter would have been easily achievable with minimal changes, and the ring buffer is the hard part. There is no reason to have a ring buffer at all, except possibly if ffmpeg don't fix their awful mp4 demuxer, and some subtle issues with demux_mkv.c wanting to seek back by small offsets (the latter was handled with small stream_peek() calls, which are unneeded now). In addition, this turns small forward seeks into reads (where data is simply skipped). Before this commit, only stream_skip() did this (which also mean that stream_skip() simply calls stream_seek() now). Replace all stream_peek() calls with something else (usually stream_read_peek()). The function was a problem, because it returned a pointer to the internal buffer, which is now a ring buffer with wrapping. The new function just copies the data into a buffer, and in some cases requires callers to dynamically allocate memory. (The most common case, demux_lavf.c, required a separate buffer allocation anyway due to FFmpeg "idiosyncrasies".) This is the bulk of the demuxer_* changes. I'm not happy with this. There still isn't a good reason why there should be a ring buffer, that is complex, and most of the time just wastes half of the available memory. Maybe another rewrite soon. It also contains bugs; you're an alpha tester now.
* common: add a helper to round up to next power of 2wm42019-11-062-0/+15
| | | | | | This is something relatively frequently needed, and there must be half a dozen ad-hoc implementations in mpv. The next commit uses this, the suspected duplicate implementations are hiding.
* demux: unconditionally reposition stream to start before openingwm42019-11-061-2/+3
| | | | | | | | | | | The old code made it depend on ->seekable. If it isn't seekable, and something discarded the data, then it'll just show an error message, which will at least be somewhat informative. If no data was discarded, the seek call is always a no-op. There's a weird "timeline" condition in the old code; this doesn't matter anymore, because timeline stuff does not pass streams down to nested demuxers anymore.
* manpage: update input protocolswm42019-11-041-55/+20
| | | | | | | | | tv:// and pvr:// are gone, DVD almost. The former didn't really have any uses left, except webcams. Provide a replacement example for that. We don't need a separate section for DVD. If you use DVD, you're on your own. There's still enough documentation left to puzzle things together even if you don't read the source code.
* manpage: opengl-cb -> libmpvwm42019-11-041-5/+5
| | | | | This was renamed ages ago. Fix the outdated usage. Except where opengl-cb was correct.
* manpage: fix global config file path in --hwdec descriptionwm42019-11-041-1/+1
|
* build: fix strict ABI optionwm42019-11-041-0/+1
| | | | Fixes: #7118
* manpage: shovel around --hwdec description (again)wm42019-11-041-25/+39
| | | | | | | Not like anyone reads it. Although putting all this text before listing the allowed option values sort of has the intention to discourage users from using the option at all. Advertise Ctrl+h, which is a decent way of enabling hardware decoding temporarily.
* DOCS/interface-changes.rst: improve entry about sws changeswm42019-11-031-2/+7
| | | | | This was pretty vague. Add some context, and explicitly mention how these options now affect screenshots.
* img_format: remove some unused format flagswm42019-11-033-26/+3
| | | | | | | | | | | | | | | | | They were used at some point, but then fell into disuse. In general, these old flags are all a bit fuzzy, so it's a good idea to remove them as much as possible. The comment about MP_IMGFLAG_PAL isn't true anymore. The old meaning was deprecated at some point, and the flag was removed from "pseudo paletted" formats. I think mpv at one point changed its own flag from AV_PIX_FMT_FLAG_PSEUDOPAL to AV_PIX_FMT_FLAG_PAL, when the former was deprecated, and it became unnecessary to allocate a palette for non-paletted formats. (The one who deprecated in FFmpeg was me, if you wonder.) MP_IMGFLAG_PLANAR was used in command.c, use a relatively similar flag as replacement.
* vo_x11: accept zimg formatswm42019-11-031-1/+2
| | | | | | | | | | | | This is slightly helpful for testing, and otherwise useless and without consequence. I'm not using the correct output format and using IMGFMT_RGB0 as placeholder. This doesn't matter currently, as both sws and zimg support this as output (and support any input for it). I'm doing this because it's surprisingly tricky to get the correct output format at this point, without digging deeper into x11 shit or refactoring parts of the VO. I don't care enough about this.
* sws_utils: remove some unnecessary sws bug work aroundwm42019-11-031-11/+0
| | | | | Seems like this was needed in 2012. The comment indicates the bug was fixed in ffmpeg git, so it's long gone.
* vd_lavc: don't keep packets for fallbacks if errors are toleratedwm42019-11-022-1/+8
| | | | | | | | | | | | | | The user can raise the number of tolerated hardware decoding errors. On the other hand, we have a static limit on packets that are "saved" for fallback handling (and that's a good idea to avoid unbounded memory usage). In this case, it could happen that the start of a file was fine after a fallback, but after that buffered amount of data, it would suddenly skip. It's more useful to skip buffering entirely if the number of tolerated decoding errors exceeds the fixed buffer. (And also, I'm sure nobody gives a shit about this feature.)
* vd_lavc: fix prepare_decoding() failure modeswm42019-11-021-9/+14
| | | | | | | | | | | | prepare_decoding() returned a bool that was supposed to tell whether decoding could work, or if something was fucked. After recent changes to the decoder loop, this did not work anymore, and caused an endless loop. Redo it, so it makes more sense. avctx being NULL (software fallback initialization failed) now signals EOF. hwdec_failed needs to be handled on send_packet() only, where it probably never happens anyway. (Who was the idiot who made libavcodec have two entrypoints for decoding? Oh right, it was me. PEBKAC.)
* vd_lavc: mention hw decoding if decoding fails in hwdec modewm42019-11-021-1/+2
| | | | Just so the user knows. Provides some context.
* vd_lavc: simplify fallback handling for full stream hw decoderwm42019-11-022-21/+19
| | | | | | | | | | | | Shovel the code around to make the data flow slightly simpler (?). At least there's only one send_packet function now. The old code had the problem that send_packet() could be called even if there were queued packets; due to sending the queued packets in the receive_frame function, this should not happen anymore (the code checking for this case in send_packet should normally never be called). Untested with actual full stream hw decoders (none available here); I created a test case by making hwaccel decoding fail.
* vd_lavc: signal packet consumed in drop-all casewm42019-11-021-1/+1
| | | | | This is just a very special code path. This probably got stuck, now that the previous commit returned the EAGAIN properly. Untested.
* vd_lavc: change incorrect bool return type to intwm42019-11-021-1/+1
| | | | | | | | Forgotten in commit 5d5fdb7. This failed to return the error code properly. In particular, if the decoder rejected the packet, this was not properly detected. Normally, this mattered only in specific cases. Fixes: #7115
* README.md: reduce focus on MPlayer, small improvementswm42019-11-021-9/+20
| | | | | | | | MPlayer isn't all too well-known anymore. It does not make sense to "advertise" with it (and it actually never did). The GPU comment needed clarification. I think originally, it was just to signal that you'll have a bad time with Intel. Make that broader.
* zimg: support subsampled chroma with non-aligned image sizeswm42019-11-021-2/+9
|
* zinmg: stop using GBRP for RGBwm42019-11-021-23/+28
| | | | | | | | | | | | | | | Instead, use a YUV planar format. It doesn't matter, since we use the format only internally and for "management" purposes. We're only interested in the physical layout, not what colorspace FFmpeg "forcibly" associates with it. Also get rid of using the old and slightly sketchy mp_imgfmt_find() function. Yep, the IMGFMT_RGB30 now "constructs" the planar format, instead of using a pixfmt constant. Slightly inconvenient, tricky, and fragile, but I like it, so bugger off. This whole thing gets rid of some of the strange plane permutations that were needed earlier.
* zimg: correct RGB30 order (probably)wm42019-11-021-1/+1
| | | | | | | | According to the definition of the GL format, and the definition in img_format.h, and the actual output by vo_gpu, the order of components was probably wrong. It's exceedingly likely that the vo_drm format (for which this was originally written) has the same layout, so this was probably a bug from when the zimg wrapper code was refactored.
* video: mess with the filte chain to enable zimg IMGFMT_RGB30 outputwm42019-11-024-8/+7
| | | | | | | | | | | This was too hardcoded to libswscale. In particular, IMGFMT_RGB30 output is only possible with the zimg wrapper, so the context needs to be taken into account (since this depends on the --sws-allow-zimg option dynamically). This is still slightly risky, because zimg currently will still fall back to swscale in some cases, such as when it refuses to initialize the particular color conversion that is requested. f_autoconvert.c could actually handle this better, but I'm tool fucking lazy right now, and nobody cares anyway, so go away, OK?
* vo_gpu: opengl: add support for IMGFMT_RGB30wm42019-11-021-0/+11
| | | | | | | | This integrates it as "special" format, with no alpha component, as the equivalent IMGFMT_RGB30 isn't meant to contain any. Nothing can produce this format in the video chain yet, so the next commits are needed to make this actually work.
* ass_mp: reset packer when allocation failsDan Elkouby2019-11-021-1/+3
| | | | | | | | | Sometimes the atlas can get so large that it exceeds the maximum allowed size for an mp_image. Since the atlas will never shrink naturally, this breaks subtitles entirely until mpv is restarted. Reset the packer so that subtitles can rendered properly once the atlas fits again. This is a partial workaround for #6286.
* manpage: update --framedrop optionwm42019-11-021-10/+26
| | | | | | | | | | | | | The statement about the display FPS is outdated by several years. "audio"-sync mode does not use the display FPS anymore, and that it's X11 only also isn't true anymore. These modes have separate implementations for audio and display video sync. modes, so the explanations are separate. Why the hell are users playing around with this anyway? The explanations are probably too special to make sense for anyone who doesn't know the code (and who knows the code doesn't need them anyway), but whatever.
* zimg: make --zimg-fast=yes defaultwm42019-11-023-2/+2
| | | | | | This is mostly just because of the odd RGB default gamma issue, which shouldn't have any real impact. This also sets allow_approximate_gamma, which I hope is fine for normal use cases.
* zimg: pass through Y plane when repacking nv12wm42019-11-021-31/+38
| | | | | | | | | | | | | | | Normally, the Y plane can just be passed directly to zimg, and only the chroma plane needs to be (de)interleaved. It still needs a copy if the Y pointer is not aligned, though. (Whether this is actually a problem depends on the CPU and probably zimg's compiler.) This requires deciding per plane whether the plane should go through the repack buffer or not. This logic is active in non-nv12 cases, because not doing so would require extra code (maybe 2 lines or so). repack_align is now always called, even if it's planar->planar with all input aligned, but it won't actually do anything in that case. The assumption is that zimg won't change behavior if you pass a callback that does nothing versus passing NULL as callback.
* zimg: add semi-planar repackerwm42019-11-021-1/+123
| | | | | | | | | | | | | | | | This is for formats like nv12 (including p010, nv24, etc.). Might be important for hardware decoding. Previously, this would have forced a libswscale fallback. The genericism makes this only slightly more complicated. The main complication is due to the fact that mixing planar and packed stuff is insane (thanks, Nvidia). P010 output will actually happily set any of the 6 bit "padding" LSB, that are normally supposed to be 0 (for unpadded data there is P016). Scaling happens with 16 bit precision. Not going to bother adding an extra packer which zeros them out, or with shifting them in packing/unpacking. Lets just hope nobody notices.
* img_format: add function to find image format by layoutwm42019-11-022-0/+36
| | | | | | This is similar to mp_imgfmt_find(), but probably a bit saner. Used by the next commit. The previous commit is required to map this unambiguously between all formats.
* img_format: add mp_regular_imgfmt.forced_csp fieldwm42019-11-022-0/+7
| | | | | | As the code comment says, this is needed to disambiguate FFmpeg formats. This struct only describes the "physical" layout of a format, while FFmpeg also attaches part of the colorspace information to the format.
* img_format: add more explanations to component_pad fieldwm42019-11-021-0/+5
| | | | | Weird shit. I thought this was a clever way to elegantly handle two cases at once, but maybe it's just confusing.
* zimg: fix out of bounds memory accesses due to broken zmaskwm42019-11-021-39/+37
| | | | | | | | | We've set all planes to the same zmask. But for subsampled chroma, the zmask obviously needs to be smaller. This could lead to out of bounds memory read and write accesses. Move the align repacker to a single function, since this is now more convenient.
* github: we want a -v -v log nowwm42019-11-011-1/+1
| | | | | --log-file uses debug log level by default. On command line, -v -v will use debug log level.
* f_decoder_wrapper: reduce uninit message log levelwm42019-11-011-1/+1
| | | | For vd/ad.
* client API: reduce log level of client exitingwm42019-11-011-1/+1
| | | | See previous commit message.
* demux: reduce log level for cache index resizingwm42019-11-011-2/+2
| | | | Now that I probably removed all bugs in this (?), this is uninteresting.
* lua: change config file loggingwm42019-11-011-2/+3
| | | | | | | | Make the existing "not found" messages debug only, and add a new verbose message if a config file was opened. The idea is that logging should make it apparent whether or not config files are loaded, and it's more common to use scripts without config files, leading to fewer log messages in verbose mode.
* x11: reduce log level for relatively uninteresting thingswm42019-11-011-9/+9
| | | | | Normally nobody cares about the WM detection stuff etc., so log this only at debug log levels.
* demux_mkv: reduce log level of mkvinfo part to debugwm42019-11-011-61/+58
| | | | | | demux_mkv has lots of logging that shows information about the file. It sort of reminds of mkvinfo output. While this is sometimes interesting, it's too much for verbose mode, and should be in debug log level.
* m_config: log applying profileswm42019-11-011-0/+1
|
* m_config: raise log level of setting options to verbosewm42019-11-011-2/+2
| | | | | | | | In 2017, we lowered this to debug level. But I think setting options is important enough that it should be logged even in verbose, at least compared to all the other dumb noise. This might be reduced again if verbose logging becomes much cleaner.
* zimg: add more packers/unpackerswm42019-10-311-59/+106
| | | | | | | | This probably covers all packed formats which have byte-aligned component, no alpha, and no subsampling. Everything else needs more imgfmt metadata, or something even more complicated. Alpha is primarily not supported, because zimg requires a second scaler instance for it, and handling packing/unpacking with it is an unacceptable mess.
* m_option: remove an unused functionwm42019-10-312-12/+0
| | | | I think the last real use of this went away in 2014 or so.
* options: make --show-profile without parameters list all profileswm42019-10-313-9/+17
|
* manpage: fix another typowm42019-10-311-1/+1
|
* manpage: update --zimg-scaler defaultwm42019-10-311-3/+3
| | | | Forgotten in previous commit.
* sws_utils, zimg: destroy vo_x11 and vo_drm performancewm42019-10-319-44/+133
| | | | | | | | | | | | | | | | | | | | | | | | | Raise swscale and zimg default parameters. This restores screenshot quality settings (maybe) unset in the commit before. Also expose some more libswscale and zimg options. Since these options are also used for VOs like x11 and drm, this will make x11/drm/etc. much slower. For compensation, provide a profile that sets the old option values: sw-fast. I'm also enabling zimg here, just as an experiment. The core problem is that we have a single set of command line options which control the settings used for most swscale/zimg uses. This was done in the previous commit. It cannot differentiate between the VOs, which need to be realtime and may accept/require lower quality options, and things like screenshots or vo_image, which can be slower, but should not sacrifice quality by default. Should this have two sets of options or something similar to do the right thing depending on the code which calls libswscale? Maybe. Or should I just ignore the problem, make it someone else's problem (users who want to use software conversion VOs), provide a sub-optimal solution, and call it a day? Definitely, sounds good, pushing to master, goodbye.
* screenshot, vo_image: use global swscale/zimg parameterswm42019-10-316-12/+35
| | | | | | | | | | Lots of dumb crap to do... something. Instead of adding yet another dumb helper, just use the main" sws_utils API in both callers. (Which, unfortunately, has been duplicated for glorious webp screenshots, despite the fact that webp is crap.) Good part: can enable zimg for screenshots (as far as needed). Bad part: uses "default" swscale parameters instead of HQ now.
* sws_utils: shuffle around some shitwm42019-10-3111-41/+72
| | | | | | | | | | | Purpose uncertain. I guess it's slightly better, maybe. The move of the sws/zimg options from VO opts (vo_opt_list) to the top-level option list is tricky. VO opts have some helper code in vo.c, that sends VOCTRL_SET_PANSCAN to the VO on every VO opts change. That's because updating certain VO options used to be this way (and not just the panscan option). This isn't needed anymore for sws/zimg options, so explicitly move them away.
* Use mp_log2() instead of av_log2()wm42019-10-313-11/+7
|
* common: add mp_log2()wm42019-10-312-0/+20
| | | | | | | | | | | To be used in the next commit. According to compiler explorer, __builtin_clz is very widely available, and it barely makes sense to provide a fallback. clang also eats this (and identifies at least as GCC 4). Actually, there's doubt that a fast log2 implementation is needed at all (I guess UTF-8 parsing needs it, but something UTF-8-specific would probably make it faster than using log2). So the fallback is just something naive.
* Replace uses of FFMIN/MAX with MPMIN/MAXwm42019-10-3116-78/+66
|