We currently write invalid sBIT entries for indexed PNGs, which by PNG
specification[1] must be 3-bytes long. The values also are capped at 8
for indexed-color PNGs, not the palette depth. This patch fixes both of
these issues previously fixed in the decoder, but not the encoder.
[1]: https://www.w3.org/TR/png-3/#11sBIT
Regression since: c125860892.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Reported-by: Ramiro Polla: <ramiro.polla@gmail.com>
The PNG specification[1] says that sBIT entries must be at most the bit
depth specified in IHDR, unless the PNG is indexed-color, in which case
sBIT must be between 1 and 8. We should not reject valid sBITs on PNGs
with indexed color.
[1]: https://www.w3.org/TR/png-3/#11sBIT
Regression since 84b454935f.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Reported-by: Ramiro Polla <ramiro.polla@gmail.com>
The description advertises fast as "Default fast search", but
this has not been the default for a long time (current default
is twoloop).
Signed-off-by: Marth64 <marth64@proxyid.net>
In the 8-bit case, we can actually read/write 8 aligned pixel values per
load/store, which unsurprisingly tends to be faster on 64-bit systems (and
makes no differences on 32-bit systems). This requires ifdef'ing though.
Unlike x86, fmin/fmax are single instructions, not function calls. They
are much much faster than doing a comparison, then branching based on its
results. With this, audiodsp.vector_clipf gets almost twice as fast, and
a properly unrollled version of it gets 4-5x faster, on SiFive-U74.
This is only the low-hanging fruit: FFMIN and FFMAX are presumably
affected as well.
This likely applies to other instruction sets with native IEEE floats,
especially those lacking a conditional select instruction.
It is d3d12va's requirement that the FrameStartOffset must be aligned as
per hardware limitation. However, we could trim this alignment at output
to reduce coded size. A aligned_header_size is added to
D3D12VAEncodePicture.
Signed-off-by: Tong Wu <wutong1208@outlook.com>
ff_dovi_rpu_parse() and ff_dovi_rpu_generate() are a bit inconsistent in
that they expect different levels of encapsulation, due to the nature of
how this is handled in the context of different APIs. Clarify the status
quo. (And fix an incorrect reference to the RPU payload bytes as 'RBSP')
Zero is auto mode. From the doc of videotoolbox:
The default bit rate is zero, which indicates that the video
encoder should determine the size of compressed data.
Before the patch, the default bitrate is 200000 setting by
avcodec/options_table, which doesn't work for most of cases.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Commit 4ef5e7d472 add qmin/qmax support to videotoolbox encoder.
The default value of (qmin, qmax) is (2, 31), which makes bitrate
control doesn't work as users' expectations.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
This instruction, if aligned on a 4-byte boundary, defines a valid target
("landing pad") for an indirect call or jump. Since this instruction is a
HINT, it is safe to assemble even if not included in the target
instruction set architecture.
The necessary alignment is already provided by the `func` macro. However
this still lacks the ELF attribute to indicate that the zicfilp is supported
in simple mode. This is left for future work as the ELF specification is not
ratified as of yet.
This will also nonobviously require the assembler to support zicfilp,
insofar as the `tail` pseudo-instruction shall clobber T2 (instead of T1) as
its temporary register.
Currently the start of the byte range for each function is aligned to
4 bytes. But this can lead to situations whence the function is preceded
by a 2-byte C.NOP at the aligned 4-byte boundary. Then the first actual
instruction and the function symbol are only aligned on 2 bytes.
This forcefully disables compression for the alignment and the symbol,
thus ensuring that there is no padding before the function.
The B extension was finally ratified in May 2024, encompassing:
- Zba (addresses),
- Zbb (basics) and
- Zbs (single bits).
It does not include Zbc (base-2 polynomials).
configure checks that the assembler supports the B extension (or rather
its constituents) anyway. These macros were dodging sanity checks for
unsupported instructions and nothing else.
