Skip to content
Snippets Groups Projects
  1. Apr 13, 2023
    • Niklas Haas's avatar
      gamut_mapping: add new gamut mapping API · 64099247
      Niklas Haas authored
      So, this is a big mathdump with little in the way of history, but I
      arrived at these algorithms after extensive testing, feedback and
      research.
      
      The basic approach is to construct a 3DLUT in IPTQc4 space. Inside the
      3DLUT, we use a simplified, peak-dependent power-law relationship
      between intensity and chromaticity in order to clip into the gamut hull,
      with a brute force (bisection method) search.
      
      Every attempt was made to provide approximately analogous equivalents to
      the old PL_GAMUT_* modes, though the nature of this new infrastructure
      means all results will be subtly different from before. In particular,
      most of the colorimetric clipping modes (except "desaturate") will
      prefer to slightly darken/brighten colors rather than desaturating them
      towards white.
      
      I could go on in more depth describing the new algorithms, but the code
      should hopefully somewhat speak for itself.
      64099247
  2. Mar 13, 2023
  3. Feb 19, 2023
  4. Dec 21, 2022
  5. Oct 14, 2022
    • Niklas Haas's avatar
      vulkan/utils_gen: switch from mako to jinja2 · 8ae448f9
      Niklas Haas authored
      Since jinja2 is a necessary dependency of glad2, which we depend on for
      OpenGL, it makes sense to re-use that to avoid pulling in *two* string
      templaters.
      
      Also, I think, vastly more likely to be pre-installed on the system in
      some fashion or another.
      8ae448f9
  6. Oct 10, 2022
  7. Sep 19, 2022
  8. Sep 08, 2022
    • Niklas Haas's avatar
      shaders/deinterlacing: add deinterlacing GPU shaders · a9fb0af6
      Niklas Haas authored
      Alongside the basic/trivial deinterlacing modes, this contains an
      implementation of the raw yadif deinterlacing kernel, based on
      vf_yadif_cuda.cu by @philipl. Currently only supports fragment shaders,
      with no compute shader speedup (although such a thing is conceptually
      possible, to share duplicate sampling work between adjacent pixels).
      
      Design the API in such a way that it permits field-merging (PAFF) should
      the need should arise in the future. Also adds a few related helpers.
      
      Closes: videolan/libplacebo#20
      a9fb0af6
  9. Jul 23, 2022
  10. Dec 29, 2021
    • Niklas Haas's avatar
      tone_mapping: add new tone mapping API · 32f02cea
      Niklas Haas authored
      I was very unsatisfied with the old tone-mapping approach for a number
      of reasons:
      
      1. The requirement for all tone-mapping functions to be pure GLSL was
         very restrictive and made it so we had to start worrying about
         GPU performance.
      
      2. For the more complicated functions, using a LUT is vastly better.
         Using a LUT also opens us up to using more complicated functions
         overall, like piecewise splines, including exact inverses of other
         tone mapping functions, or functions based on dynamic metadata.
      
      3. Having this be an open-ended API in theory allows users to define
         custom tone mapping functions (e.g. perhaps one based on extra frame
         metadata).
      
      4. Extensible enough to support e.g. inverse tone mapping as well.
      
      I will probably still include GLSL fast paths for tone-mapping functions
      that are faster to implement in pure GLSL, but for now I plan on
      switching entirely to a LUT-based approach.
      
      The major downside of this approach is that it doesn't afford us the
      ability to combine this style of tone-mapping with full peak detection,
      but I'm unsatisfied with the complexity of peak detection overall so I'm
      not sure this is a huge loss in practice.
      
      One way we can salvage the situation is by always using the detected
      peak merely to (linearly) adjust the output of the LUT, e.g. something
      like `sdr = lut(hdr) / lut(peak)`.
      
      Closes videolan/libplacebo#154
      32f02cea
  11. Sep 07, 2021
    • Niklas Haas's avatar
      shaders/film_grain: add H.274 synthesis · 027c7e60
      Niklas Haas authored
      This is not entirely spec-compliant with SMPTE RDD 5-2006. Notably, I
      swapped out their recommended PRNG in favor of a significantly better
      one that's also more friendly for GPU usage.
      
      In exchange for this, we don't currently perform any deblocking of
      vertical block edges. This is because proper deblocking would be
      prohibitively expensive in a single-pass environment due to the 8x8
      averaging required to determine the correct intensity interval.
      
      It's possible that, in theory, we could get around this by just assuming
      that the intensity interval is the same for adjacent blocks. (In
      practice, this is basically true anyway). Or simply attenuating edge
      blocks.
      
      But visually, I simply don't think this is actually that necessary, at
      least for real-time playback. I'll probably re-evaluate this in the
      future. For the time being, this solves the problem well enough to my
      estimation.
      
      Closes videolan/libplacebo#148
      027c7e60
    • Niklas Haas's avatar
      shaders/film_grain: generalize film grain API · f1195225
      Niklas Haas authored
      Refactor the whole API to support other types of film grain through a
      common interface, to cut down on the amount of code duplication that
      would otherwise be required for new film grain synthesis shaders.
      
      Rather annoyingly, I can't really easily make this backwards compatible.
      Fortunately, this API has no external users that I could find in the
      wild - ever since dav1dplay switched to using the dav1d.h helpers.
      f1195225
  12. Sep 04, 2021
  13. Jul 02, 2021
    • James Ross-Gowan's avatar
      d3d11: add initial implementation · be32ca68
      James Ross-Gowan authored
      Add a pl_gpu implementation that uses Direct3D 11. This uses SPIRV-Cross
      to translate shaders from GLSL to HLSL. In its current state, plplay
      works and the test suite passes with feature level 10_0 and up. (9_x is
      unlikely to ever pass due to runtime-enforced shader complexity limits.)
      
      Missing features include emulated texture formats, cached_program,
      `pl_gpu_limits.thread_safe`, and HDR/high bit depth support in
      pl_swapchain, though these shouldn't be too hard to implement.
      
      This also updates the GLFW demos to be able to use Direct3D 11 through
      GLFW_NO_API.
      
      Closes #18
      be32ca68
  14. Apr 21, 2021
    • Niklas Haas's avatar
      log: rename from pl_context · 2459200a
      Niklas Haas authored and Niklas Haas's avatar Niklas Haas committed
      Over the past few years, the use case of `pl_context` has increasingly
      shrinked, finally dwindling to "nothing other than logging" with the
      introduction of thread safety (and thus the loss of the "thread safety
      guard") As such, this being called `pl_context` is really unnecessarily
      confusing. It's just a glorified logging subsystem.
      
      Rename it, and make it optional in the process. Also introduce a typedef
      to make the new name shorter, as part of a new convention that I will be
      switching to moving forwards.
      
      This technically breaks the auto-cleanup behaviour of `pl_shader` and
      `pl_filter` but I really don't think those were all that useful or
      justified, and I don't think anybody relied on it.
      2459200a
  15. Mar 26, 2021
    • Niklas Haas's avatar
      README: add screenshot of plplay · 0b9f1eca
      Niklas Haas authored
      It would be cool if I could figure out more screenshots to add, maybe
      some sort of comparison between bilinear and jinc scaling or w/e.
      0b9f1eca
    • Niklas Haas's avatar
      utils/frame_queue: add new interpolation helper · 0e594407
      Niklas Haas authored
      The API for `pl_frame_mix` is currently a bit abstract and high-level.
      Most clients will probably not care to reimplement the massive amounts
      of logic that go into constructing a proper frame queue.
      
      Enter `pl_queue`, the solution for all your frame queuing needs! This
      will interface with the decoder via your choice of a push or pull API,
      and translate all decoded frames into an abstract internal timeline,
      `pl_frame_mix` slices of which can be probed for arbitrary timestamps.
      
      As an extra bonus, this also contains code for things like FPS
      estimation and VPS (vsyncs per second) estimation, somewhat mirroring
      the logic in e.g. mpv's interpolation/display-sync code.
      
      It's worth pointing out that this is a rather severe API break for
      `pl_frame_mix`, but I'm pretty sure this API has absolutely zero users,
      given the massive amount of effort required to use it before this
      commit. So I didn't bother with backwards compatibility, aside from an
      API bump as usualy.
      0e594407
  16. Feb 19, 2021
    • Niklas Haas's avatar
      shaders/colorspace: refactor icc/3dlut API · 558cfcb1
      Niklas Haas authored
      Renamed from 3DLUT to ICC across the board, and moved to its own
      conditionally installed header Also, merged with the internal lcms code,
      since it was a bit redundant now.
      
      Mostly to make room for more LUT formats I will be adding, and since
      colorspace.h was a bit cluttered.
      558cfcb1
  17. Jan 27, 2021
  18. Dec 05, 2020
  19. Jun 02, 2020
  20. May 29, 2020
  21. May 25, 2020
    • Niklas Haas's avatar
      README: document optional dependencies a bit better · 739d650c
      Niklas Haas authored
      Now that `python3-mako` represents the first nontrivial dependency of a
      main feature (e.g. `vulkan`), document this list properly.
      
      Formatting could be bikeshed, but whatever. I just wanted to have a
      list out there.
      739d650c
  22. Apr 06, 2020
    • Niklas Haas's avatar
      opengl: add initial implementation · 3e94b695
      Niklas Haas authored
      This is missing support for texel buffers (which are considered optional
      anyway by the API), and also for some swapchain-related features (which
      I'm not sure in what way we even want to represent in our code).
      
      This is mainly here so we can get support for OpenGL-related GPU backend
      features in the context of e.g. shader generation.
      
      We also update the GLFW demo program to support using OpenGL. This is
      all still very primitive and rather untested.
      
      Closes #17.
      3e94b695
  23. Apr 02, 2020
  24. Jan 04, 2020
  25. Oct 19, 2019
  26. Feb 14, 2019
  27. Feb 06, 2019
  28. Dec 05, 2018
  29. Dec 04, 2018
  30. Nov 07, 2018
  31. Nov 06, 2018
Loading