In particular, allows users to go all the way up to PL_LOG_TRACE if
desired. (While also avoiding some potentially unnecessary callbacks for
filtered messages, including e.g. the CPU cost of printing out shader
sources)
Response to runtime log level changes by updating it once per
filter_frame(), which should hopefully be often enough.
This filter conceptually maps the libplacebo `pl_renderer` API into
libavfilter, which is a high-level image rendering API designed to work
with an RGB pipeline internally. As such, there's no way to avoid e.g.
chroma interpolation with this filter, although new versions of
libplacebo support outputting back to subsampled YCbCr after processing
is done.
That being said, `pl_renderer` supports automatic integration of the
majority of libplacebo's shaders, ranging from debanding to tone
mapping, and also supports loading custom mpv-style user shaders, making
this API a natural candidate for getting a lot of functionality out of
relatively little code.
In the future, I may approach this problem either by rewriting this
filter to also support a non-renderer codepath, or by upgrading
libplacebo's renderer to support a full YCbCr pipeline.
This unfortunately requires a very new version of libplacebo (unreleased
at time of writing) for timeline semaphore support. But the amount of
boilerplate needed to hack in backwards compatibility would have been
very unreasonable.
Include windows.h to fix it. Normally, it'd be better to include it in
vulkan_functions.h, but I'm reasonably confident nothing else that uses
the Vulkan code will need to include Windows functions and not windows.h.
Finally, this is as close to usable as it gets for glslang.
Much faster to compile as well, and eliminates the need for a C++
compiler, which is great.
Also, changes to the resource limits won't break users, as we
can use designated initializers in C90.
This simplifies and makes queue family picking simpler and more robust.
The requirements on the device context are relaxed. They made no sense
in the first place.
The video encode/decode extension is still in beta, at least on paper,
but I really doubt they'd change needing a separate queue family.
Make get_int/set_int symetric. The int64_t to double to int64_t
conversion is unprecise for large value.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
x264.h: "the payloads of all output NALs are guaranteed to be
sequential in memory." Therefore we can omit the loop.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Always false since this encoder was switched to encode2 and
ff_alloc_packet() in 06484d0b8a
and f2b20b7a8b.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
In function vtenc_populate_extradata(), there is a manually created
pixel buffer that has not been released. So we should use CVPixelBufferRelease
to release this pixel buffer at the end, otherwise will cause a memory leak.
Signed-off-by: Rick Kern <kernrj@gmail.com>
