The custom-allocator logic has been completely defunct since a while,
since nothing depends on those targets, they never get used.
This updates jemalloc to pkg-config, adds the fallback option for
potential arbitrary allocators, and finally actually adds the libraries
to LDFLAGS.
The implementation is flawed in that the frame opaque data is not in
fact correctly reordered along with the packets, but is being output in
packet input order, just like the dts are.
This reverts commit 3553809703.
This reverts commit 9a245bdf5d.
This commit basically broke all samples with fractional framerates,
rather than fixing them.
I at this point do not understand the original issue anymore, and I'm
not sure how this slipped my initial testing.
All my test samples must have happened to have a simple timebase.
The actual dts values pretty much always are just a simple chain of
1,2,3,4,5,... Or maybe slightly bigger steps. Each increase by one means
an advance in time by one unit of the timebase.
So a fractional framerate/timebase is already not an issue.
So with this patch applied, the calculation might end up substracting
huge values (1001 is a common one) from the dts, which would be an
offset of that many frames, not of that many fractions of a second.
This broke at least muxing into mp4, if the sample happened to have a
fractional framerate.
I do not thing the original issue this patch tried to fix existed in the
first place, so it can be reverted without further consequences.
dts != pts is actually a spec violation for AV1, given it has no
reordering in the classical sense.
We don't really need the whole timestamp queue in this case and can just
pass through the timestamp as is for both dts and pts.
The encoder seems to be trading blows with hevc_nvenc.
In terms of quality at low bitrate cbr settings, it seems to
outperform it even. It produces fewer artifacts and the ones it
does produce are less jarring to my perception.
At higher bitrates I had a hard time finding differences between
the two encoders in terms of subjective visual quality.
Using the 'slow' preset, av1_nvenc outperformed hevc_nvenc in terms
of encoding speed by 75% to 100% while performing above tests.
Needless to say, it always massively outperformed h264_nvenc in terms
of quality for a given bitrate, while also being slightly faster.
This is by no means perfect, since at least ddagrab will return scRGB
data with values outside of 0.0f to 1.0f for HDR values.
Its primary purpose is to be able to work with the format at all.
_Float16 support was available on arm/aarch64 for a while, and with gcc
12 was enabled on x86 as long as SSE2 is supported.
If the target arch supports f16c, gcc emits fairly efficient assembly,
taking advantage of it. This is the case on x86-64-v3 or higher.
Same goes on arm, which has native float16 support.
On x86, without f16c, it emulates it in software using sse2 instructions.
This has shown to perform rather poorly:
_Float16 full SSE2 emulation:
frame=50074 fps=848 q=-0.0 size=N/A time=00:33:22.96 bitrate=N/A speed=33.9x
_Float16 f16c accelerated (Zen2, --cpu=znver2):
frame=50636 fps=1965 q=-0.0 Lsize=N/A time=00:33:45.40 bitrate=N/A speed=78.6x
classic half2float full software implementation:
frame=49926 fps=1605 q=-0.0 Lsize=N/A time=00:33:17.00 bitrate=N/A speed=64.2x
Hence an additional check was introduced, that only enables use of
_Float16 on x86 if f16c is being utilized.
On aarch64, a similar uplift in performance is seen:
RPi4 half2float full software implementation:
frame= 6088 fps=126 q=-0.0 Lsize=N/A time=00:04:03.48 bitrate=N/A speed=5.06x
RPi4 _Float16:
frame= 6103 fps=158 q=-0.0 Lsize=N/A time=00:04:04.08 bitrate=N/A speed=6.32x
Since arm/aarch64 always natively support 16 bit floats, it can always
be considered fast there.
I'm not aware of any additional platforms that currently support
_Float16. And if there are, they should be considered non-fast until
proven fast.
IEEE-754 differentiates two different kind of NaNs.
Quiet and Signaling ones. They are differentiated by the MSB of the
mantissa.
For whatever reason, actual hardware conversion of half to single always
sets the signaling bit to 1 if the mantissa is != 0, and to 0 if it's 0.
So our code has to follow suite or fate-testing hardware float16 will be
impossible.
nvenc does not appear to use these values as inputs for its built in RGB
to YUV conversion, but instead sets them on the output as-is.
Testing indicates the input is expected to be sRGB, with the output
ending up as limited range bt.470.
This avoids an extra copy of potentially quite big video frames.
Instead of copying the entire frames data into a rawvideo packet it
packs the frame into a wrapped avframe packet and passes it through
as-is.
Unfortunately, wrapped avframes are set up to be video frames, so the
audio frames continue to be copied.
Additionally, this enabled passing through video frames that previously
were impossible to process, like hardware frames or other special
formats that couldn't be packed into a rawvideo packet.
- certs.h is gone. Only contains test data, and was not used at all.
- config.h is renamed. Was seemingly not used, so can be removed.
- MBEDTLS_ERR_SSL_NO_USABLE_CIPHERSUITE is gone, instead
MBEDTLS_ERR_SSL_HANDSHAKE_FAILURE will be thrown.
- mbedtls_pk_parse_keyfile now needs to be passed a properly seeded
RNG. Hence, move the call to after RNG seeding.
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
With these triggering a lot of crashes recently, an option to globally
disable all of them is added as a tool to work around those crashes in
case the SEI data is not needed by the user.
Also re-enables s12m for hevc_nvenc, since the issue is not specifically
with that, but it affects all SEI data.
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
Timo Rothenpieler