This makes output consistent with a similar warning just few
lines above where this flag is checked in the same way.
Signed-off-by: softworkz <softworkz@hotmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
When viewing logs, it's sometimes useful to be able to see whether
execution was ended via q command.
Signed-off-by: softworkz <softworkz@hotmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
Before:
overlay AVOptions:
x <string> ..FV....... set the x expression (default "0")
y <string> ..FV....... set the y expression (default "0")
eof_action <int> ..FV....... Action to take when encountering EOF from secondary input (from 0 to 2) (default repeat)
repeat 0 ..FV....... Repeat the previous frame.
endall 1 ..FV....... End both streams.
pass 2 ..FV....... Pass through the main input.
eval <int> ..FV....... specify when to evaluate expressions (from 0 to 1) (default frame)
After:
a
overlay AVOptions:
x <string> ..FV....... set the x expression (default "0")
y <string> ..FV....... set the y expression (default "0")
eof_action <int> ..FV....... Action to take when encountering EOF from secondary input (from 0 to 2) (default repeat)
repeat 0 ..FV....... Repeat the previous frame.
endall 1 ..FV....... End both streams.
pass 2 ..FV....... Pass through the main input.
eval <int> ..FV....... specify when to evaluate expressions (from 0 to 1) (default frame)
Signed-off-by: softworkz <softworkz@hotmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
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>