summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* vo_gpu: opengl: make sure to always clean up debug callbacksNiklas Haas2020-04-151-0/+4
| | | | | | | | | In theory this mostly happens automatically, especially after the 5 vsync limit disables this already. But if we uninit before 5 vsyncs are rendered, this can get left in a dangling 'enabled' state, which leaks a debug report callback. Always explicitly disable it just to be on the safe side.
* zimg: fix swapped chroma planes with packed YUV bullshitwm42020-04-141-4/+4
| | | | | | | | | I must have messed this up when I actually added the Y210 format (because that one is correct). So my comment in the commit adding this about the FFmpeg pixfmt doxygen being wrong was wrong. I'd like to use this opportunity to complain once more about the existence of these terrible pixel formats.
* zimg: fix build with older FFmpeg (troublesome Intel dude format)wm42020-04-141-0/+2
|
* zimg: add support for 1 bit per pixel formatswm42020-04-131-0/+52
| | | | | | | | | | | | | | Again worthless, slow, and only for libswscale parity. With this, we support all formats libswscale supports, except bayer input, and rgb4/bgr4 output. We even support some formats libswscale doesn't. It's possible that the zimg wrapper isn't always as fast as libswscale. But there is optimization potential: the inner repack loops are self-contained enough that they could be reasonably be implemented in assembler (probably), and doing everything slice-wise should reduce the overhead of the separate pack/unpack stages.
* zimg: add packed YUV bullshitwm42020-04-131-1/+111
| | | | | | | | | | | | | | | | | Just lazily tested. The comment on AV_PIX_FMT_Y210LE seems to be wrong. It claims it's "like YUYV422", bit it seems more like YVYU422, at last the way libswscale input treats it. Maybe Intel pays its developers too much? The repacker inner lop is probably rather inefficient. In theory we could optimize it by reading the packed pixels as words, doing the component reshuffling using compile time values etc., but I'd rather keep the code size small. It's already bad enough that we have to support 16 bit per component variants, just because this one Intel guy couldn't keep it in his pants. In general, I can't be bothered to spend time on optimizing it; I'm only doing this for fun (i.e. masochistic obligation).
* zimg: add support for some RGB fringe formatswm42020-04-131-0/+174
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This covers 8 and 16 bit packed RGB formats. It doesn't really help with any actual use-cases, other than giving the finger to libswscale. One problem is with different color depths. For example, rgb565 provides 1 bit more resolution to the green channel. zimg can only dither to a uniform depth. I tried dithering to the highest depth and shifting away 1 bit for the lower channels, but that looked ugly (or I messed up somewhere), so instead it dithers to the lowest depth, and adjusts the value range if needed. Testing with bgr4_byte (extreme case with 1/2/1 depths), it looks more "grainy" (ordered dithering artifacts) than libswscale, but it also looks cleaner and smoother. It doesn't have libswscale's weird red-shift. So I call it a success. Big endian formats need to be handled explicitly; the generic big endian swapper code assumes byte-aligned components. Unpacking is done with shifts and 3 LUTs. This is symmetric to the packer. Using a generated palette might be better, but I preferred to keep the symmetry, and not having to mess with a generated palette and the pal8 code. This uses FFmepg pixfmts constants directly. I would have preferred keeping zimg completely separate. But neither do I want to add an IMGFMT alias for every of these formats, nor do I want to extend our imgfmt code such that it can provide a complete description of each packed RGB format (similar to FFmpeg pixdesc). It also appears that FFmpeg pixdesc as well as the FFmpeg pixfmt doxygen have an error regarding RGB8: the R/B bit depths are swapped. libswscale appears to be handling them differently. Not completely sure, as this is the only packed format case with R/B havuing different depths (instead of G, the middle component, where things are symmetric).
* zimg: add support for big endian input and outputwm42020-04-133-50/+164
| | | | | | | | | | | | | | | | | | | | | | | | | | | | One of the extremely annoying dumb things in ffmpeg is that most pixel formats are available as little endian and big endian variants. (The sane way would be having native endian formats only.) Usually, most of the real codecs use native formats only, while non-native formats are used by fringe raw codecs only. But the PNG encoders and decoders unfortunately use big endian formats, and since PNG it such a popular format, this causes problems for us. In particular, the current zimg wrapper will refuse to work (and mpv will fall back to sws) when writing non-8 bit PNGs. So add non-native endian support to zimg. This is done in a fairly "generic" way (which means lots of potential for bugs). If input is a "regular" format (and just byte-swapped), the rest happens automatically, which happens to cover all interesting formats. Some things could be more efficient; for example, unpacking is done on the data before it's passed to the unpacker. You could make endian swapping part of the actual unpacking process, which might be slightly faster. You could avoid copying twice in some cases (such as when there's no actual repacker, or if alignment needs to be corrected). But I don't really care. It's reasonably fast for the normal case. Not entirely sure whether this is correct. Some (but not many) formats are covered by the tests, some I tested manually. Some I can't even test, because libswscale doesn't support them (like nv20*).
* vf_format: add gross mechanism for forcing scaler for testingwm42020-04-133-3/+37
| | | | | | | | | | | This sucks, but is helpful for testing. Obviously, it would be much nicer if there were a way to specify _all_ scaler options per filter (if the user wanted), instead of always using the global options. But this is "too hard" for now. For testing, it is extremely convenient to select the scaler backend, so add this option, but make clear that it could go away. We'd delete it once there is a better mechanism for this.
* vo_gpu: d3d11: also utilize config cache for d3d11-specific optionsJan Ekström2020-04-121-1/+9
| | | | | Update the cache whenever we utilize p->opts, as recommended by wm4.
* vo_gpu: d3d11: add support for exclusive fullscreenJames Ross-Gowan2020-04-121-1/+86
| | | | | Lets the application fully control the rendering onto the screen instead of the compositor.
* vo: further reduce redundant wakeupswm42020-04-101-1/+7
| | | | | | | | | | | | | | | In display-sync mode, the core doesn't need to woken up every vsync, but only every time a new actual video frame needs to be queued. So don't wake up if there are still frames to repeat. In audio-sync mode, the wakeup is simply redundant, since there's a separate timer (in->wakeup_pts) to control when to queue a new frame. I think. This finally brings the required playloop iterations down to almost the number of video frames. (As originally intended, really.) Also a fairly risky change.
* video: remove another redundant wakeupwm42020-04-102-19/+43
| | | | | | | | | | | | | | | The wakeup at the end of VO frame rendering seems redundant, because after rendering almost no state changes. The player core can queue a new frame once frame rendering begins, and there's a separate wakeup for this. The only thing that actually changes is in->rendering. The only thing that seems to depend on it and can trigger a wakeup is the vo_still_displaying() function. Change it so that it needs an explicit call to a new API function, so we can avoid wakeups in the common case. The vo_still_displaying() code is mostly just moved around due to locking and for avoiding forward declarations. Also a somewhat risky change (tasty new bugs).
* options: make imgfmt options always accept "no"wm42020-04-091-1/+1
| | | | | | | | This was optional, with the intention that normally such options require a valid format. But there is no reason for this (at least not anymore), and it's actually more logical to accept "no" in all situations this option type is used. This also gets rid of the weird min field special use.
* stats: some more performance graphswm42020-04-091-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add an infrastructure for collecting performance-related data, use it in some places. Add rendering of them to stats.lua. There were two main goals: minimal impact on the normal code and normal playback. So all these stats_* function calls either happen only during initialization, or return immediately if no stats collection is going on. That's why it does this lazily adding of stats entries etc. (a first iteration made each stats entry an API thing, instead of just a single stats_ctx, but I thought that was getting too intrusive in the "normal" code, even if everything gets worse inside of stats.c). You could get most of this information from various profilers (including the extremely primitive --dump-stats thing in mpv), but this makes it easier to see the most important information at once (at least in theory), partially because we know best about the context of various things. Not very happy with this. It's all pretty primitive and dumb. At this point I just wanted to get over with it, without necessarily having to revisit it later, but with having my stupid statistics. Somehow the code feels terrible. There are a lot of meh decisions in there that could be better or worse (but mostly could be better), and it just sucks but it's also trivial and uninteresting and does the job. I guess I hate programming. It's so tedious and the result is always shit. Anyway, enjoy.
* video: report negative subtitle/OSD margins if necessarywm42020-03-261-4/+4
| | | | | | | | | | | | | | Until now, it used only coordinates clipped to the screen for this, which meant no negative margins were ever reported to libass. This broke proper rendering of explicitly positioned ASS events (libass simply could not know the real video size in this case.) Fix this by reporting margins even if they're negative. This makes it apparently work correctly with vo_gpu at least. Note that I'm not really sure if anything in the rendering chain required non-negative margins. If so, and that code implicitly assumed it, I suppose crashes and such are possible.
* vd_lavc: make hwdec fallback message more consistentwm42020-03-241-4/+1
| | | | | | | | | | | The "rule" is that a fallback warning message should be shown only shown if software decoding was used before, or in other words when either hwdec was enabled before, but the stream suddenly falls back, or it was attempted to enable it at runtime, and it didn't work. The message wasn't printed the first time in the latter case, because hwdec_notified was not set in forced software decoding mode. Fix it with this commit. Fortunately, the logic becomes simpler.
* wayland: simplify mouse wheel direction calculationJan Ekström2020-03-191-3/+2
| | | | | Based on an idea by sfan5. Remove abs usage, and instead just check for negative value, and set variable to either +/-1.
* options: change option macros and all option declarationswm42020-03-1837-434/+440
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change all OPT_* macros such that they don't define the entire m_option initializer, and instead expand only to a part of it, which sets certain fields. This requires changing almost every option declaration, because they all use these macros. A declaration now always starts with {"name", ... followed by designated initializers only (possibly wrapped in macros). The OPT_* macros now initialize the .offset and .type fields only, sometimes also .priv and others. I think this change makes the option macros less tricky. The old code had to stuff everything into macro arguments (and attempted to allow setting arbitrary fields by letting the user pass designated initializers in the vararg parts). Some of this was made messy due to C99 and C11 not allowing 0-sized varargs with ',' removal. It's also possible that this change is pointless, other than cosmetic preferences. Not too happy about some things. For example, the OPT_CHOICE() indentation I applied looks a bit ugly. Much of this change was done with regex search&replace, but some places required manual editing. In particular, code in "obscure" areas (which I didn't include in compilation) might be broken now. In wayland_common.c the author of some option declarations confused the flags parameter with the default value (though the default value was also properly set below). I fixed this with this change.
* wayland: notify vo if an output changesDudemanguy2020-03-151-0/+2
| | | | | | | | Previously, the vo wasn't always informed if something about the output changed during playback. For instance, changing a display's refresh rate during playback would not update mpv's display fps. Fix this by simply using VO_EVENT_WIN_STATE in output_handle_done which executes whenever something about the output is changed.
* vo_gpu: warn if correct-downscaling is ignoredAvi Halachmi (:avih)2020-03-141-0/+11
| | | | And document that it's ignored with bilinear scaler.
* cocoa-cb: support maximize/minimize on startupder richter2020-03-141-1/+9
| | | | | | | Allow the --window-maximized and --window-minimized flags to actually work when the player is started. since macOS doesn't like using both at the same time the minimized state takes precedence over the maximized state.
* options: change how option range min/max is handledwm42020-03-133-4/+6
| | | | | | | | | | | | | | | | | Before this commit, option declarations used M_OPT_MIN/M_OPT_MAX (and some other identifiers based on these) to signal whether an option had min/max values. Remove these flags, and make it use a range implicitly on the condition if min<max is true. This requires care in all cases when only M_OPT_MIN or M_OPT_MAX were set (instead of both). Generally, the commit replaces all these instances with using DBL_MAX/DBL_MIN for the "unset" part of the range. This also happens to fix some cases where you could pass over-large values to integer options, which were silently truncated, but now cause an error. This commit has some higher potential for regressions.
* options: remove intpair option typewm42020-03-131-1/+2
| | | | | | | | | | | This was mostly unused, and has certain problems. Just get rid of it. It was still used in CDDA (--cdda-span) and a debug option for OpenGL (--opengl-check-pattern). Replace both of these with 2 options, where each sets the start/end values of the former span. Both were undocumented somehow (normally we require all options to be documented), so I'm not caring about compatibility, and not bothering to add it to the API changelog.
* video/out/android_common: use jni helpersAman Gupta2020-03-121-10/+11
| | | | Signed-off-by: Aman Gupta <aman@tmm1.net>
* vo_gpu: generally allow non-storable FBOsNiklas Haas2020-03-082-3/+12
| | | | | | | | | | | | | We have this cap now thanks to e2976e662, but we don't actually make sure our FBOs are storable before we blindly attempt using them with compute shaders. There's no more need to unconditionally set `storage_dst = true` as long as we make sure to include an extra condition on the `fbo_format` selection to prevent users from accidentally enabling compute-shader-only features with non-storable FBOs, alongside some other miscellaneous adjustments to eliminate instances of "assumed storability" from vo_gpu.
* vo_gpu: avoid error spam when ra_fbo fmt is non-storableNiklas Haas2020-03-081-0/+2
| | | | | | | | | | | This simply makes the "is the destination FBO format bad?" check a tiny bit less awful, by making sure we prefer storable FBO formats over non-storable FBO formats. I'd love to make this also conditional on whether or not we actually *need* a storable FBO format, but that logic is decided later, in `pass_draw_to_screen`, and I don't want to replicate the logic. Fixes #7017.
* wayland: always use the fs-screen id for fsDudemanguy2020-03-081-33/+31
| | | | | | | | | Previously if the --fs-screen option was set, it would only use the screen if mpv was launched with --fs and only on startup. During runtime, the toggle would ignore it. Rework the logic here so that mpv's fullscreen always uses --fs-screen if it is set. Additionally, cleanup some unneeded cruft in vo_wayland_reconfig and make find_output more useful.
* drm_prime: double free bugSven Kroeger2020-03-053-15/+93
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit fixes a bug where handle for a framebuffer gets double freed. It seems to happen that the same prime fd gets two framebuffers. As the prime fd is the same the resulting prime handle is also the same. This means one handle but 2 framebuffers and can lead to the following chain: 1. The first framebuffer gets deleted the handle gets also freed via the ioctl. 2. In startup phase not all 4 dumb buffers for overlay drawing are set up. It can happen that the last dumb buffer gets the handle we freed above. 3. The second framebuffer gets freed and the handle will be freed again resulting that the 4's dumb buffer handle is not backed by a buffer. 4. Drm prime continues to assign handles to its prime fds an will lead to have this handle which was just freed to reassign again but to an prime buffer. 5.Now the overlay should be drawn into dumb buffer 4 which still has the same handle but is backed by the wrong buffer. This leads to two different behaviors: - MPV crashes as the drm prime buffers size als calculated by the decoder output format. The overlay output format differs and it takes more space. SO the size check in kernel fails. - MPV is continuing play. This happens when the decoders allocates a bigger buffer than needed for the overlay. For example overlay is Full HD and decoder output is 4k. This leads to the behavior das the overlay wil be drawn into the wrong buffer as its a drm prime buffer and results in a flicker every fourth step.
* drm_prime: forward modifiers from FFMPEG to drm APISven Kroeger2020-03-031-2/+9
| | | | | | * Change drmModeAddFB2 to drmModeAddFB2WithModifiers * Set modifiers flag in API call * fetch and set modifiers according to kernel constraints
* OpenGL: Also detect softpipe as a software driverlinkmauve2020-02-251-0/+1
| | | Because it is.
* cocoa-cb: fix crash with some japanese charactersder richter2020-02-221-1/+2
| | | | | | | | | | | | the actual character that made mpv crash is IDEOGRAPHIC COMMA (U+3001, UTF-8: E3 80 81, 、) and that only in some specific circumstances that could be reliably reproduced on my end. using an NSString instead of the Swift String actually fixes that issues even though they should technically do the exact same thing. i tested all the other String initialisers, but they all had had the same issue. this is kinda only a workaround till i can find a different way of handling it.
* mac, cocoa: fix UI updates on none main queue threadsder richter2020-02-221-2/+4
| | | | | | injecting the Apple Main Thread Checker via DYLD_INSERT_LIBRARIES=libMainThreadChecker.dylib identified several problems that needed fixing.
* cocoa-cb: remove unnecessary semicolonsder richter2020-02-223-16/+16
|
* x11: switch back to StaticGravitywm42020-02-221-4/+1
| | | | | | | | | | | | | | | | | This was changed 6 years ago (444e583b6) and seemed to work fine. But it does seem to cause issues with IceWM sometimes, while with StaticGravity the problem is gone. Comparing both gravity values, reading the confused source code comment, and reading the referenced commit message, I can't determine what it even does, I just remove it. Reproduction: - start mpv in windowed mode, with 2 videos of different size - switch to second video - switch window with alt+tab - switch back to mpv with alt+tab - window moves to X=0 There's probably a better way to fix this. Please send a patch.
* video: drop NV24 aliaswm42020-02-182-4/+0
| | | | | | | Caused build failures with still supported FFmpeg versions. It's unreferenced, so it's not needed. Fixes: #7471
* Remove remains of Libav compatibilitywm42020-02-166-42/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* 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.
* 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.
* 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.
* sws_utils: use zimg by default if availablewm42020-02-121-0/+1
| | | | | 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.
* 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 componen