summaryrefslogtreecommitdiffstats
path: root/video/out/gpu/video.c
Commit message (Collapse)AuthorAgeFilesLines
* vo_gpu: fix crash if dither texture fails to allocatewm42020-01-081-0/+3
| | | | | | | Theoretically possible (and quite unlikely due to the small texture size). The code was originally written with the assumption that texture allocations can't fail, and it was never updated out of laziness. Untested.
* vo_gpu: hwdec_vdpau: remove direct_modePhilip Langdale2019-12-281-45/+0
| | | | | | | | | | | | | | | | | | | | | | | | As we are less and less interested in vpdpau, with nvdec and vaapi being better choices in general on nvidia and AMD respectively, we might consider removing direct_mode, where we bypass the vdpau mixer and work directly with yuv textures. Normally, working with yuv textures would be great, but vdpau built in an assumption that all frames are delivered as separate fields, causing us to have to re-interleave them. nvidia then introduces a new OpenGL extension that can return the yuv frames as frames, but we can't just unconditionally switch to that as we'd want to keep supporting older hardware where the drivers are no longer getting new features. The end result is that we wouldn't be able to get rid of the old code paths. Removing direct_mode means we always use the mixer, and work with rgba frame textures. There are some theoretical limitations to this, but in practice they probably don't matter much - unsupported colourspaces don't matter because without 10bit decoding support, we can't use them anyway, and apparently we're not doing separate chroma scaling these days, so scaling the rbga doesn't really lose anything (and the vdpau hq scaling option remains available).
* vf_gpu: render subtitleswm42019-11-301-7/+11
| | | | | | | Pretty annoying affair. The vo_gpu code could of course not trigger rendering from filters yet, so it needed to be extended. Also, this uses some icky stuff made for vf_sub (and this was the reason I marked vf_sub as deprecated), so everything is terrible.
* vo_gpu: fix infinite scaler reinit spamNiklas Haas2019-11-231-8/+9
| | | | | | | | | Handling the window with this function makes no sense, since windows and kernels are not the same thing and don't share the same option list. The only reason it's done is to make sure the char* points at the static string rather than the dynamically allocated one, which we can do manually in this function. Rewrite a bit for clarity/quality.
* video/out/gpu: Remove stray top-level ';'Michael Forney2019-11-181-1/+1
|
* vo_gpu: sync duplicated condition on peak computationwm42019-11-161-0/+2
| | | | | | | | | | | | | | | | | | | | pass_color_map() (in video_shaders.c) and pass_colormanage() (video.c) both duplicate the condition on whether to do peak computation. Peak computation requires a compute shader, so if the duplicated conditions don't match, video_shaders.c will generate a compute shader, but video.c will try to run it as fragment shader. This leads to a "blue screen". This can be reproduced by playing a HDTV video with --target-peak=99. It's not clear how to fix this. Should pass_tone_map() be only invoked if mp_trc_is_hdr() == true (what pass_colormanage() uses to decide whether to enable peak computation), or should pass_colormanage() just tell pass_color_map() to skip peak computation? Decide for the latter, as it's more robust. Even if not correct, at least it gets rid of the blue shit. Fixes: #7149
* vo_gpu: yuv alpha is always full rangewm42019-11-091-8/+6
| | | | | | | | | | | | | | Probably. It's not like these pixel formats are formally specified - FFmpeg added them because _some_ file format or decoder supports it, and while that format/codec may define it precisely, the pixel format is sort of disconnected and just a FFmpeg thing. In any case, the yuva sample I had at hand uses the full range the component data type can provide. The old code used the same "shifted" range as for Y/U/V components, which must have been wrong. This will not work correctly for packed YUVA formats, but fortunately they matter even less.
* 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
* vo_gpu: add and utilize color space information from ra_fboJan Ekström2019-10-301-8/+35
| | | | | | | | This lets us set primaries, transfer function and the target peak based on what the presenting layer would want us to have. Now that this mechanism is available, warn if the user has overridden values such as primaries or transfer function.
* vo_gpu: attempt to fix 0bgr formatwm42019-10-261-2/+21
| | | | | | | | | | | | | | | | | | | | | | | | Using e.g. --vf=format=0bgr showed obviously wrong colors with --vo=gpu. The reason is that leading padding wasn't handled correctly. Try to hack fix it. While the code in copy_image() is somewhat reasonable, I can't tell what the fuck is going on with that HOOKED shit. For some reason this HOOKED shit doesn't use copy_image() (???), or uses it incorrectly. It affects debanding. --deband=no works correctly. If it's enabled, the crap in hook_prelude() is needed. I bet there are many more bugs with this. For example, the deband shader will try to deband the alpha channel if the format abgr is used (because the correct component order is only established later). This can be tested by inserting a "color.x = 0;" at the end of the deband shader, and using --vf=format=rgba vs. abgr. I cannot comprehend why it doesn't just store explicitly which components a texture contains, and why it doesn't just read the components always in an uniform way. There's a big chance this fix works only by coincidence. This shouldn't have been so hard either. Time for a complete rewrite?
* vo_gpu, options: don't return NaN through APIwm42019-10-251-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | Internally, vo_gpu uses NaN for some options to indicate a default value that is different depending on the context (e.g. different scalers). There are 2 problems with this: 1. you couldn't reset the options to their defaults 2. NaN is a damn mess and shouldn't be part of the API The option parser already rejected NaN explicitly, which is why 1. didn't work. Regarding 2., JSON might be a good example, and actually caused a bug report. Fix this by mapping NaN to the special value "default". I think I'd prefer other mechanisms (maybe just having every scaler expose separate options?), but for now this will do. See you in a future commit, which painfully deprecates this and replaces it with something else. I refrained from using "no" (my favorite magic value for "unset" etc.) because then I'd have e.g. make --no-scale-param1 work, which in addition to a lot of effort looks dumb and nobody will use it. Here's also an apology for the shitty added test script. Fixes: #6691
* options: add M_OPT_FILE to some more options that take filesPhilip Sequeira2019-09-271-2/+2
|
* vo_gpu: correctly normalize src.sig_peakNiklas Haas2019-09-151-1/+4
| | | | | | | | | | | | | In some cases, src.sig_peak remains undefined as 0, which was definitely the case when using the OSD, since it never got passed through the usual color space normalization process. Most robust work-around is to simply force the normalization at the site where it's needed. This ensures this value is always valid and defined, to make the peak-dependent logic in these two functions always work. Fixes 4b25ec3a9d Fixes #6917 Fixes #6918
* vo_gpu: fix taking screenshots of rotated videoswnoun2019-08-141-2/+6
|
* vo_gpu: fix use of existing textures in error diffusionBin Jin2019-06-161-6/+8
| | | | | | | error diffusion requires two texture rendering pass. The existing code reuses `screen_tex` and creates another for such purpose. This works generally well for opengl, but could potentially be problematic for vulkan, due to its async natural.
* vo_gpu: implement error diffusion for ditheringBin Jin2019-06-161-0/+85
| | | | | | | | | | | | | | | | | This is a straightforward parallel implementation of error diffusion algorithms in compute shader. Basically we use single work group with maximal possible size to process the whole image. After a shift mapping we are able to process all pixels column by column. A large ring buffer are allocated in shared memory to speed things up. However the size of required shared memory depends linearly on the height of video window (or screen height in fullscreen mode). In case there is no enough shared memory, it will fallback to `--dither=fruit`. The maximal allowed work group size is hardcoded as 1024. Ideally we could query `GL_MAX_COMPUTE_WORK_GROUP_INVOCATIONS`. But for whatever reason, it seems most high end card from nvidia and amd support only the minimal required value, so I guess we can stick to it for now.
* vo_gpu: fix --scaler-resizes-only for fractional ratio scalingBin Jin2019-06-061-3/+6
| | | | | | | | The calculation of scale factor involves 32-bit float, and a strict equality test will effectively ignore `--scaler-resizes-only` option for some non-integer scale factor. Fix this by using non-strict equality check.
* vo_gpu: expose texture_off to user shaderBin Jin2019-06-061-0/+1
| | | | | It will provide low level access to coordinate mapping other than texmap().
* vo_gpu: allow user shader to fix texture offsetBin Jin2019-06-061-3/+32
| | | | | This commit essentially makes user shader able to fix offset (produced by other prescaler, for example) like builtin `--scale`.
* vo_gpu: increase user shader size limitBin Jin2019-03-131-1/+1
| | | | | | | | | | | | | The old size limit was chosen before LUT texture was supported in user shader. At that time, the whole user shader will be compiled and run on GPU, which makes large user shader impractical to be used. With the introduction of LUT texture, the old size limit doesn't make any sense. For example, a 1024x1024 rgba16f LUT will cost 32MB shader size. Fix this by increasing the size limit to a value that's unlikely be reached.
* Merge branch 'master' into pr6360Jan Ekström2019-03-111-56/+74
|\ | | | | | | | | | | Manual changes done: * Merged the interface-changes under the already master'd changes. * Moved the hwdec-related option changes to video/decode/vd_lavc.c.
| * vo_gpu: make texture offset available to CHROMA hooksBin Jin2019-03-091-16/+25
| | | | | | | | | | | | | | | | | | | | Before this commit, texture offset is set after all source textures are finalized. Which means CHROMA hooks won't be able to align with luma planes. This could be problematic for chroma prescalers utilizing information from luma plane. Fix this by find the reference texture early, and set global texture offset early.
| * vo_gpu: fix initial seeding of the peak detect ssboNiklas Haas2019-02-181-3/+1
| | | | | | | | | | | | | | This solves some edge cases when using files with very weird metadata (e.g. MaxCLL 10k and so forth). Instead of just blindly seeding it with the tagged metadata, forcibly set the initial state from the detected values.
| * vo_gpu: use dB units for scene change detectionNiklas Haas2019-02-181-6/+6
| | | | | | | | | | | | | | Rather than the linear cd/m^2 units, these (relative) logarithmic units lend themselves much better to actually detecting scene changes, especially since the scene averaging was changed to also work logarithmically.
| * vo_gpu: clamp sigmoid functionNiklas Haas2019-02-181-0/+2
| | | | | | | | Can explode on some clips otherwise
| * vo_gpu: allow color management in dumb modeNiklas Haas2019-02-181-5/+6
| | | | | | | | | | There's no point to disallow target-trc/prim in dumb mode, since they still work fine.
| * vo_gpu: improve accuracy of HDR brightness estimationNiklas Haas2019-02-181-2/+2
| | | | | | | | | | | | | | This change switches to a logarithmic mean to estimate the average signal brightness. This handles dark scenes with isolated highlights much more faithfully than the linear mean did, since the log of the signal roughly corresponds to the perceptual brightness.
| * vo_gpu: allow boosting dark scenes when tone mappingNiklas Haas2019-02-181-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | In theory our "eye adaptation" algorithm works in both ways, both darkening bright scenes and brightening dark scenes. But I've always just prevented the latter with a hard clamp, since I wanted to avoid blowing up dark scenes into looking funny (and full of noise). But allowing a tiny bit of over-exposure might be a good thing. I won't change the default just yet (better let users test), but a moderate value of 1.2 might be better than the current 1.0 limit. Needs testing especially on dark scenes.
| * vo_gpu: redesign peak detection algorithmNiklas Haas2019-02-181-16/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The previous approach of using an FIR with tunable hard threshold for scene changes had several problems: - the FIR involved annoying hard-coded buffer sizes, high VRAM usage, and the FIR sum was prone to numerical overflow which limited the number of frames we could average over. We also totally redesign the scene change detection. - the hard scene change detection was prone to both false positives and false negatives, each with their own (annoying) issues. Scrap this entirely and switch to a dual approach of using a simple single-pole IIR low pass filter to smooth out noise, while using a softer scene change curve (with tunable low and high thresholds), based on `smoothstep`. The IIR filter is extremely simple in its implementation and has an arbitrarily user-tunable cutoff frequency, while the smoothstep-based scene change curve provides a good, tunable tradeoff between adaptation speed and stability - without exhibiting either of the traditional issues associated with the hard cutoff. Another way to think about the new options is that the "low threshold" provides a margin of error within which we don't care about small fluctuations in the scene (which will therefore be smoothed out by the IIR filter).
| * vo_gpu: improve tone mapping desaturationNiklas Haas2019-02-181-20/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | Instead of desaturating towards luma, we desaturate towards the per-channel tone mapped version. This essentially proves a smooth roll-off towards the "hollywood"-style (non-chromatic) tone mapping algorithm, which works better for bright content, while continuing to use the "linear" style (chromatic) tone mapping algorithm for primarily in-gamut content. We also split up the desaturation algorithm into strength and exponent, which allows users to use less aggressive desaturation settings without affecting the overall curve.
| * vo_gpu: allow resetting target-peak to the trc defaultKotori Itsuka2019-01-231-1/+2
| | | | | | | | | | | | | | | | | | Add "auto" the possible values of target-peak. The default value for target_peak is to calculate the target using mp_trc_nom_peak. Unfortunately, this default was outside the acceptable range of 10-10000 nits, which prevented its later reassignment. So add an "auto" choice to target-peak which lets clients and scripts go back to using the trc default after assigning a value.
* | Merge commit '559a400ac36e75a8d73ba263fd7fa6736df1c2da' into ↵Anton Kindestam2018-12-051-1/+3
|\ \ | |/ |/| | | | | | | wm4-commits--merge-edition This bumps libmpv version to 1.103
| * player: get rid of mpv_global.optswm42018-05-241-1/+3
| | | | | | | | | | | | | | | | This was always a legacy thing. Remove it by applying an orgy of mp_get_config_group() calls, and sometimes m_config_cache_alloc() or mp_read_option_raw(). win32 changes untested.
* | vo_gpu: split --linear-scaling into two separate optionsNiklas Haas2018-10-191-12/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since linear downscaling makes sense to handle independently from linear/sigmoid upscaling, we split this option up. Now, linear-downscaling is its own option that only controls linearization when downscaling and nothing more. Likewise, linear-upscaling / sigmoid-upscaling are two mutually exclusive options (the latter overriding the former) that apply only to upscaling and no longer implicitly enable linear light downscaling as well. The old behavior was very confusing, as evidenced by issues such as #6213. The current behavior should make much more sense, and only minimally breaks backwards compatibility (since using linear-scaling directly was very uncommon - most users got this for free as part of gpu-hq and relied only on that). Closes #6213.
* | vo_gpu: avoid overwriting compute shader block sizesNiklas Haas2018-08-261-4/+10
| | | | | | | | | | | | | | | | | | | | When using multiple compute shaders as part of the same pass, there can be a conflict in the block sizes. In the problematic case, the HDR detection shader can collide with the polar sampling shader. In this case, the solution is clear - the passes that can handle any size should "give in" and not overwrite the block sizes. Fixes #6083.
* | gpu: prefer 16bit floating point FBO formats to 16bit integer onesJan Ekström2018-07-081-1/+1
|/ | | | | | According to earlier discussions, this can improve visual quality. This only changes the preferred order of the formats, not the formats themselves.
* vo_gpu/video: disable compute shaders if an FBO format was not availableJan Ekström2018-05-011-0/+5
| | | | | This is actually more generic and better than just lazily plastering peak calculation together with dumb mode.
* vo_gpu/video: add improved logging when a user-specified FBO failsJan Ekström2018-05-011-2/+13
| | | | | I don't know if we can just return from this function, so for now just adding this piece of logging.
* gpu/video: make HDR peak computing work without work group countNiklas Haas2018-04-291-4/+5
| | | | | | | | | | Define a hard-coded value for gl_NumWorkGroups if it is not available. This adds an additional requirement of needing a shader recompile for all window size changes. This was considered a worthwhile compromise as currently f.ex. d3d11 completely lacked any peak computation - this is a major quality of life upgrade.
* gpu/video: improve HDR peak computation feature check loggingJan Ekström2018-04-291-1/+4
| | | | | Now that the feature depends on multiple features, log all of their states in the message.
* video: remove internal stereo_out flagwm42018-04-291-2/+2
| | | | | | Also rename stereo3d to stereo_in. The only real change is that the vo_gpu OSD code now uses the actual stereo 3D mode, instead of the --video-steroe-mode value. (Why does this vo_gpu code even exist?)
* vo_gpu: move some extra code for screenshot to video.cwm42018-04-201-5/+14
| | | | | This also happens to fix some UB on the error path (target being declared after the first "goto done;").
* vo_gpu: fix anamorphic video screenshots (second try)wm42018-03-161-3/+4
| | | | | | | | | | | | | | This passed the display size as source size to the renderer, which is of course nonsense. I don't know what I was doing in 569383bc54. Yet another fix for those damn anamorphic videos. As a somewhat redundant/cosmetic change, use image_params instead of real_image_params in the code above. They should have the same, dimensions (but possibly different formats when doing hw decdoing), and mixing them is confusing. p->image_params wins because it's shorter. Actually fixes #5619.
* vo_gpu: fix anamorphic screenshotswm42018-03-151-2/+2
| | | | | | | | | | | We took the storage size instead of the display size for "unscaled" screenshots. Even if it's called "unscaled", it's still supposed to scale to compensate for aspect ratio. (How many commits fixing anamorphic screenshots in various situations are there?) Fixes #5619.
* vo_gpu: error out if there were rendering errors when taking screenshotwm42018-03-031-1/+5
|
* vo_gpu: fix taking screenshots of rotated videoswm42018-03-031-0/+3
| | | | Good old 90° rotation logic messing everything up.
* vo_gpu: introduce --target-peakNiklas Haas2018-02-201-4/+7
| | | | | |