- Sep 12, 2024
-
-
- Sep 04, 2024
-
-
- Dec 13, 2022
-
-
- Feb 02, 2022
-
-
- Jan 30, 2022
-
-
Martin Storsjö authored
-
- Oct 31, 2021
-
-
Niklas Haas authored
The signature of pl_allocate/release_dav1dpic takes a void *cookie, which the compiler warns about if we don't implicitly cast.
-
- Oct 06, 2021
-
-
Fixes segfaults on Windows.
-
- Sep 03, 2021
-
-
Victorien Le Couviour--Tuffet authored
Merges the 3 threading parameters into a single `--threads=` argument. Frame threading can still be controlled via the `--framedelay=` argument. Internally, the threading model is now a global thread/task pool design. Co-authored-by:
Ronald S. Bultje <rsbultje@gmail.com>
-
- Jun 20, 2021
-
-
- Feb 11, 2021
-
-
Emmanuel Gil Peyrot authored
Neither --buildtype=plain nor --buildtype=debug set -ffast-math, so llround() is kept as a function call and isn’t optimised out into cvttsd2siq (on amd64), thus requiring the math lib to be linked. Note that even with -ffast-math, it isn’t guaranteed that a call to llround() will always be omitted (I have reproduced this on PowerPC), so this fix is correct even if we ever decide to enable -ffast-math in other build types.
-
- Feb 06, 2021
-
-
The current playback loop triggers a repaint on any single event, including spammy events such as SDL_MOUSEMOTION. Fix this by only repainting on SDL_WINDOWEVENT_EXPOSED, which is defined as the event sent when the window was damaged and needs to be repainted, as well as on new frames. Fixes #356
-
Upstream libplacebo added support for dav1d integration directly, allowing us to vastly simplify all of this code. In order to take advantage of new optimizations, I had to allow update_frame to unref the Dav1dPicture. (This is fine, since double unref is a no-op) In addition, some of the functions we use were deprecated in recent libplacebo versions, so since we're taking a new dependency we might as well fix the deprecation warnings.
-
These functions are not thread-safe on GL, because they are not called from the thread holding the GL context. Work around this by simply disabling it. Not very optimal, but better than crashing.
-
- Feb 01, 2021
-
-
Victorien Le Couviour--Tuffet authored
-
- Jan 28, 2021
-
-
Victorien Le Couviour--Tuffet authored
-
- Jul 20, 2020
-
-
Marvin Scholz authored
-
- May 26, 2020
-
-
This one correctly sets the subsampling mode based on whether or not the plane is actually subsampled, and also infers PL_CHROMA_UNKNOWN as PL_CHROMA_TOP_LEFT in such cases.
-
- May 25, 2020
-
-
Niklas Haas authored
libplacebo v66 got helper functions that make preserving the aspect ratio in this case trivial. But we still need to make sure to clear the FBO to black if the image doesn't cover it fully.
-
- May 20, 2020
-
-
Niklas Haas authored
Returning out of this function when pl_render_image() fails is the wrong thing to do, since that leaves the swapchain frame acquired but never submitted. Instead, just clear the target FBO to blank red (to make it clear that something went wrong) and continue on with presentation.
-
- May 18, 2020
-
-
Niklas Haas authored
Annoying minor differences in this struct layout mean we can't just memcpy the entire thing. Oh well. Note: technically, PL_API_VER 33 added this API, but PL_API_VER 63 is the minimum version of libplacebo that doesn't have glaring bugs when generating chroma grain, so we require that as a minimum instead. (I tested this version on some 4:2:2 and 4:2:0, 8-bit and 10-bit grain samples I had lying around and made sure the output was identical up to differences in rounding / dithering.)
-
Niklas Haas authored
Generalize the code to set the right pl_image metadata based on the values signaled in the Dav1dPictureParameters / Dav1dSequenceHeader. Some values are not mapped, in which case stdout will be spammed. Whatever. Hopefully somebody sees that error spam and opens a bug report for libplacebo to implement it.
-
Niklas Haas authored
Having the pl_image generation live in upload_planes() rather than render() will make it easier to set the correct pl_image metadata based on the Dav1dPicture headers moving forwards. Rename the function to make more sense, semantically. Reduce some code duplication by turning per-plane fields into arrays wherever appropriate. As an aside, also apply the correct chroma location rather than hard-coding it as PL_CHROMA_LEFT.
-
Niklas Haas authored
This is turned into a const array in upstream libplacebo, which generates warnings due to the implicit cast. Rewrite the code to have the mutable array live inside a separate variable `extensions` and only set `iparams.extensions` to this, rather than directly manipulating it.
-
- May 16, 2020
-
-
Signed-off-by:
Marvin Scholz <epirat07@gmail.com>
-
- May 15, 2020
-
-
Marvin Scholz authored
This allows selecting at runtime if placebo should use OpenGL or Vulkan for rendering.
-
Marvin Scholz authored
-
Marvin Scholz authored
-
Marvin Scholz authored
-
Marvin Scholz authored
-
- May 14, 2020
-
-
Marvin Scholz authored
-
Marvin Scholz authored
-
Marvin Scholz authored
To un-clutter the main dav1dplay.c, move the fifo to its own file and header.
-
- Mar 06, 2020
-
-
Konstantin Pavlov authored
Now when -Denable_examples=true is requested, meson will fail as expected if there is no SDL available.
-
Jan Beich authored
../examples/dav1dplay.c:1030:5: warning: implicit declaration of function 'init_demuxers' is invalid in C99 [-Wimplicit-function-declaration] init_demuxers(); ^ /usr/bin/ld.bfd: examples/c590b3c@@dav1dplay@exe/dav1dplay.c.o: in function `decoder_thread_main': dav1dplay.c:(.text+0x1243): undefined reference to `init_demuxers' cc: error: linker command failed with exit code 1 (use -v to see invocation)
-
- Sep 27, 2019
-
-
Right now this just allocates a new buffer for every frame, uses it, then discards it immediately. This is not optimal, either dav1d should start reusing buffers internally or we need to pool them in dav1dplay. As it stands, this is not really a performance gain. I'll have to investigate why, but my suspicion is that seeing any gains might require reusing buffers somewhere. Note: Thrashing buffers is not as bad as it seems, initially. Not only does libplacebo pool and reuse GPU memory and buffer state objects internally, but this also absolves us from having to do any manual polling to figure out when the buffer is reusable again. Creating, using and immediately destroying buffers actually isn't as bad an approach as it might otherwise seem. It's entirely possible that this is only bad because of lock contention. As said, I'll have to investigate further...
-
Useful to test the effects of performance changes to the decoding/rendering loop as a whole.
-