During bitstream overflow errors, it is possible that update post
enc gets skipped as last row might never have to be entropy coded
as we have already consumed the buffer. This can be fatal for
encoding further frames. Move this update to a location where it
is guaranteed to be updated
Bug: oss-fuzz-62378
Test: ./avc_enc_fuzzer
Change-Id: I279deb1f30c15c057c0b6e909834313a1df4fdac
As bitstream overflow errors are not marked as fatal errors and
these recons are being used for reference, its best to return
the partial encoded buffers for application
Change-Id: I30a8e9907cf42d3bc883ee78b28cbae723bad7ac
During entropy error, even though the bitstream buffer is not written
with additional bytes, the bitstream context state is getting updated.
As the number of bits left in current word is updated, the get_num_bits
used for computing header and texture bits can become negative causing
overflow errors
Change-Id: I2f990071a9935b2ee328dbd3915dfbefccbab4c5
At the end of encoding of a frame, the entropy thread communicates
the encoded bit stream size to rc module for update. After this
update, if rc decides to skip the frame due to vbv overflow, the
bitstream context is reset and frame is marked for skip.
Due to an oversight, if entropy encoding sees an error, then this
update is happening at the end of each row. Now rc has decided to
skip the frame and the context is reset. As the bitstream context is
reset, other threads are unaware of this problem and continue encoding.
This is causing issues.
Restrict the rc update to the thread that entropy code the last row.
Bug: oss-fuzz:59543
Bug: 285891354
Test: avc_enc_fuzzer
Change-Id: If45a5f34abb59ece812733af8f54f72ae5474d03
A 'consumption ratio' is computed fr every MB when
in-frame RC is enabled. This computation can result in
divide-by-zeros in certain circumstances. Such cases
are now appropriately handled.
Bug: ossFuzz:60828
Test: svc_enc_fuzzer
During encoding, if encoder encounters an error, the library returns the
same. If the application ignores it and feeds further input, library
while processing the new input is facing a null dereference.
1. Added a error check in encode API call before processing input
2. Made entropy bitstream buffer overflow errors non-fatal.
Bug: 187499509
Test: POC in bug descriptions
atest VtsHalMediaC2V1_0TargetVideoEncTest
atest -c CtsMediaV2TestCases:CodecEncoderTest
In some cases, s_inp_buf and s_out_buf on stack in ih264e_encode()
can be accessed unininitialized. This is fixed by initializing these
two structures.
Bug: oss-fuzz:57333
Bug: 274906999
Test: avc_enc_fuzzer
The ILP MV struct pointer will be set to NULL for I slices and
for spatial layer ID 0. A NULL check ought to be used in all places
that access this pointer. This was missing in 2 places and has been
added.
Test: svc_enc_fuzzer
RC uses int32_t for storing multiple quantities related to
bits in a given period.
'isvce_svc_frame_params_validate' has been added, which queries
RC API for the relevant quantities and returns with and error
if computations involving those quantities exceed INT32_MAX.
Bug: 274221347
Bug: 274265498
Test: svc_enc_fuzzer
Using incorrect stride during copy from source buffer to intermediate buffer. This is corrected
Bug: 242379731
Bug: 242386193
Test: avcenc -c enc.cfg
Change-Id: I307525906ee6f6df5d8e114ebbafa40d6442662d
(cherry picked from commit 0a87a34fccffe15c2cc80670cf1058e7a3313c6a)
Merged-In: I307525906ee6f6df5d8e114ebbafa40d6442662d
If 'u4_strm_buf_offset < 4' when 'isvce_cabac_flush' is called,
then EPB could not have been inserted into the stream buffer.
BUG = ossfuzz:56816
Test: svc_enc_fuzzer
- Only libavcdec is marked as available to apex modules instead
of marking all decoder libraries to be available to apex modules.
- some formatting changes for consistency with neighboring lines.
Test: Builds
If 'u4_strm_buf_offset == 0' when 'isvce_cabac_flush' is called,
then 'carry' is implicitly 0.
'u4_strm_buf_offset == 0' implies stream buffer is empty.
Invocation of 'isvce_cabac_flush' implies all MB's in a slice
have been encoded.
BUG = ossfuzz:56137
Test: svc_enc_fuzzer
- Add SII flag and SII parameters for the encoder and decoder.
- Encoder: Added support for SII SEI
- Decoder: Added support for SII SEI parsing and exporting
For certain configurations of the fuzzer input, the minimum
output buffer size is insufficient.
The minimum value has been doubled in this commit.
BUG=oss-fuzz:55797
Test: svc_enc_fuzzer
Added support for encoding 'Scalable Baseline' profile, corresponding to
profile_idc of 83 in 'Rec. ITU-T H.264 (11/2007)'.
Bug: 248891908
Test: svcenc -c enc.cfg
Change-Id: Ib12ca4c4a8c0e674738ae2af01558a08cefe0929
Use generic function pointers on riscv.
Test: built for aosp_riscv64
Signed-off-by: Mao Han <han_mao@linux.alibaba.com>
Change-Id: I424d15396d7e9711d23a6118f92aee0fc7924c28
Last recon frame wasn't being saved in some cases, it is now fixed.
Bug: 242104774
Test: avcenc -c enc.cfg
Change-Id: I50fcd6709988b7126a36cc88d8abdb75e871a37a
This CL adds support to report PSNR between incoming and resulting
encoded frames. Eventually be reported upstream as part of a feedback
mechanism.
Test: avcenc -c enc.cfg
Bug: b/235899898
Change-Id: Id520913ca5964965b5a86bc520240ccd1b28176c
For YUV 420 semi-planar input, second plane's width was
wrongly being checked to be equal to half of first plane's width.
Corrected this condition now to check that both these widths are
same.
Bug: 242103647
Test: avcenc -c enc.cfg
Change-Id: I3c06f6e40823ddbf00df0435bfbd1cd314c982e3
When u1_video_signal_type_present_flag and
u1_colour_description_present_flag were set, we did write all
fields relating to video signal and color description into
the VUI, even if all those fields were uninitialized (left
at the default cleared zero, which for most fields are
invalid/reserved value zero).
Instead have these flags default to zero, making it clear
that the VUI doesn't (yet) contain correctly set values
for those fields.
Bug: 240470605
Change-Id: I86628cff190c8a40e9c6fd12d3fc8e06419ece7c
The ih264e_vui_ip_t struct doesn't contain any input timestamps,
and the IVE_CMD_CTL_SET_VUI_PARAMS command didn't set these fields
at all (leaving them at their default initialized state 0,0).
At the start of ih264e_encode, pending configurations are
applied if their timestamp matches the timestamp of the frame
to be encoded, or applied unconditionally if the timestamps are
equal to -1.
Thus, the parameters set with IVE_CMD_CTL_SET_VUI_PARAMS
previously only got applied if encoding a frame with the specific
timestamp 0, but now they get applied unconditionally on the
next encoded frame.
Bug: 240466320
Change-Id: I12c50251d8485e3f171ac5c87132ddfbc80377d6
INSERT_EPB doesn't insert emulation prevention byte and instead
is used to check if an emulation prevention byte is to be inserted.
Renaming INSERT_EPB to SHOULD_INSERT_EPB.
Bug: 180962392
Test: build library
Change-Id: I9ac8d8ca6b2d29d5bccab68404f02883acf5d361
Cmake scripts are now modular. Separate scripts now handle
build specifications for each target and dependency.
Toolchain files have been added for armv7, armv8 builds.
Bug: 213579857
Test: Builds using cmake
Test: Builds in OSS-fuzz
Change-Id: Iac62b443c0a0de09a2ce6553a660db2c3d5dc846
few SIMD modules read few more bytes from the input buffer
at the end of frame. To avoid OOB read, intermediate buffer
is used while processing last MB row.
Bug: 180505809
Test: poc in bug
Test: atest CtsMediaTestCases:VideoEncoderTest
Test: atest CtsMediaV2TestCases:CodecEncoderTest
Test: atest VtsHalMediaC2V1_0TargetVideoEncTest
Change-Id: I11ca65937c7dfaf623f3535c02158ceec0dcc6ee
Return current input buffer as buffer to be freed in case
of errors that are seen before picking up the input buffer
to be from the input queue.
Once a buffer is picked up from the queue, that is returned
as the buffer to be freed.
There is no need to return a buffer from ps_proc context
Bug: 180643802
Test: poc in the bug description
Test: atest CtsMediaV2TestCases:CodecEncoderTest
Test: atest VtsHalMediaC2V1_0TargetVideoEncTest
Change-Id: I1671ca1e82f522004d1f070df89b256b856f75b8
Do not set the picture type as NA for the last frame in encoding
order.
Bug: 180219345
Test: POC in bug descriptions
Test: atest CtsMediaV2TestCases:CodecEncoderTest
Test: atest VtsHalMediaC2V1_0TargetVideoEncTest
Change-Id: I57ee7db9e2e55fba2666a6aaa4002ef31276e4b9
Input dimensions are checked for supported range in set_dimensions
control call. Encoder returns an error for unsupported values in
this control call. But if the caller ignores this error and proceeds
to call process(), encoder wasn't checking the dimensions again.
Unsupported dimensions are now checked in process() call as well.
Note: This is relanding previously reverted commit
06c30b33c4
Bug: 172908358
Test: Poc in bug
Test: atest android.mediav2.cts
Test: atest android.media.cts
Change-Id: Icf3f296ab24432c680427a82da3505491acca3bd
For every IDR generated after the first one, one recon buffer was not
released from the buffer manager, when recon was enabled. This resulted
in encoder returning with an error after couple of IDRs when recon was
enabled.
This is fixed by calling recon buffer release based on pic_cnt instead
of frm_num. frm_num is reset to 0 for every IDR where as pic_cnt is not.
Bug: 173150684
Test: avcenc -i qcif.yuv -w 176 -h 144 -o out.h264 \
--bframes 2 --idr_interval 4 --recon_enable 1 \
--recon recon.yuv
Change-Id: I8b72e5aedc6a460292388e4e46f56c07486db4a6
