The recon and deblocking worker threads abort when ps_dec->i4_error_code
is non-zero, a check added to fix a worker thread hang. The following
cases could cause them to abort early:
- ps_dec->i4_error_code was not cleared at the start of
ih264d_video_decode(), so an error set during a previous decode call
persisted across subsequent frames.
- ih264d_process_intra_mb() sets ERROR_INTRAPRED when an intra
prediction mode needs unavailable neighbors, although the mode is
already replaced with mode 0 (vertical). Before that check, this error
code was not read during decoding.
Reset ps_dec->i4_error_code to 0 at the start of ih264d_video_decode()
alongside ps_dec_op->u4_error_code, and stop setting ERROR_INTRAPRED.
Bug: 548241521
Bug: 565823098
Flag: EXEMPT BUGFIX
Test: atest CtsMediaV2TestCases:android.mediav2.cts.EncodeDecodeAccuracyTest#testEncodeDecodeAccuracyRGB
atest MctsMediaV2TestCases
atest MctsMediaDecoderTestCases
atest MctsMediaCodecTestCases
atest VtsHalMediaC2V1_0TargetVideoDecTest
Change-Id: I191ea7a6f6bd027fd3719db6581703c790eb40f2
(cherry picked from commit cfc33cb8eb9394274d1ca7a1c3193800d9356faa)
The worker threads could hang waiting for macroblock maps if
an error was encountered and worker thread exits early.
Added check for the error and thread break flags in the wait loops,
allowing the worker threads to abort cleanly.
Bug: 472596363
Test: atest MctsMediaV2TestCases
atest MctsMediaDecoderTestCases
atest MctsMediaCodecTestCases
atest VtsHalMediaC2V1_0TargetVideoDecTest
Change-Id: I9265e17ae7501164501a3fd66c30b6b67b68104b
(cherry picked from commit 70e21545b3bb5cfdc83ec1d7d60d30549b216011)
In order do this, moved freeing of dynamic bitstream buffer outside free_dynamic_bufs() call.
This allocation is not done inside allocate_dynamic_bufs() and hence shouldn't be freed in free_dynamic_bufs().
This will ensure that any memory that is allocated before and not yet freed, will be freed.
This is done as a precaution to ensure there are no leaks.
Bypass wrappers functions for memcpy and memset, calling standard
C library functions directly. This allows _FORTIFY_SOURCE to
perform compile-time safety checks.
Bug: 514722372
Test: ./avcdec
Change-Id: Ice5048bdebc74e15c10e16aed3353251773659c7
Reason for revert: This re-lands ag/38985801 with the following change:
- Added the missing macro in common/armv8/ih264_resi_trans_quant_av8.s to fix the issues seen in c2.android.avc.encoder.
Bug: 485868924
Test: readelf -nW libavcdec.a
Test: readelf -nW libavcenc.a
Test: atest MctsMediaV2TestCases
atest MctsMediaDecoderTestCases
atest MctsMediaEncoderTestCases
atest MctsMediaCodecTestCases
Test: avc_dec_fuzzer
avc_enc_fuzzer
Change-Id: I27e94895d93dea32e8c68ba23f497aa3028e11dd
This reverts commit 766ba532a950aac730660f7d30600a211c215c97.
Reason for revert: Droidmonitor created revert due to b/499361746. ACA verified the culprit http://go/aca-get/65ca2c5c-4a45-4857-84de-2e3ffdd5135a
Fix: 499361746
Change-Id: Ia95cff5294fa65bbe6fc6f9ba844b163c4146938
The assembler in this project needs updating, but we want to enable the
bti-report=error flag globally.
Change-Id: Ia67dd7bfc9adce5a434f45a783ffbc109dfb4dd4
C++23 removed transitive includes so you need to add C++23 headers
directly to use its classes and functions. svc_enc_fuzzer needs the
algorithm header to use std::fill. I tested it in Android by building `m
svc_enc_fuzzer`.
Error:
external/libavc/fuzzer/svc_enc_fuzzer.cpp:347:5: error: no member named
'fill' in namespace 'std'; did you mean 'kill'?
347 | std::fill(mMemRecBufs.begin(), mMemRecBufs.end(), nullptr);
external/libavc/fuzzer/svc_enc_fuzzer.cpp:379:5: error: no member named
'fill' in namespace 'std'; did you mean 'kill'?
379 | std::fill(mMemRecBufs.begin(), mMemRecBufs.end(), nullptr);
external/libavc/fuzzer/svc_enc_fuzzer.cpp:1203:13: error: no member
named 'fill' in namespace 'std'; did you mean 'kill'?
1203 | std::fill(std::next(mEncBufs.mInputBuf.begin(),
bytesLeft), mEncBufs.mInputBuf.end(),
This patch includes handwritten avx2 intrinsics to optimize the libavc sw decoder
by reducing CPU-cycles overhead on module : libcodec2_soft_avcdec.
Playing 1024 resolution video playback on the Galley App with HW decoder disabled:
cpu-cycles overhead(%) reduced by ~15%.
Loading of video thumbnails on Gallery/Photos App is faster (we have pushed approx
more than 30 videos as a part of the usecase): cpu-cycles overhead(%) have reduced by ~10%.This patch is related to s/w video decoding.
Signed-off-by: Priyanka Bose <priyanka.bose@intel.corp-partner.google.com>
This change redefines the `cc_test` modules within the examples
directory as `cc_binary` modules.
Previously, these `cc_test` modules were effectively acting as wrappers
around executable binaries, solely for the purpose of generating test
executables. This approach did not allow for the direct installation of
these executables on devices.
Changing these modules to `cc_binary` allows the resulting executables
are produced as standalone binaries, enabling their deployment and
execution on test devices.
Bug: 414657128
Change-Id: I9caef8a5cf29c7d77b8bcd535f047a640c52285c
Currently avc encoder creates desired number of threads at
the start of every frame and joins after frame is processed.
This change modifies the thread creation part. Now the threads
are created at the start of the sequence. Kept alive through
out the sequence and joined at the end of the sequence. This
helps in reduction of thread creation and deletion overhead.
This change does not effect the encoded bitstream. That is,
encoded output with this change is same as encoded output
without this change.
Bug: 288998933
Test: avcenc -c enc.cfg
Change-Id: I98784169052a5f05c109aaf1de97a5e46d7a773d
In some erroneous fuzzer bistreams, the slice data requires more
parsing than what was implied by the distance between successive
start codes. The primary culprit is the NEXTBITS macro which requires
reading 4 additional bytes of the bitstream buffer. To alleviate
this, 16 bytes per 4x4 TU have been additionally allocated to the
bitstream buffer. Also, chroma bytes are added for 4:2:0/4:2:2.
This is in reference to commit-72315c1, where additional bytes were added to fix similar issue.
Bug = ossfuzz:42538616
Test: mvc_dec_fuzzer
In avc MaxFrameNum can be 65536 which is of 17 bits due to which
interger overflow was happening for i2_max_frm_num and
ui_max_frame_num. This has been fixed.
Bug: 369676522
Test: poc in bug description
Change-Id: I858eea6bf8eea1e2cee6d4a7c28a84705eb51792
- Added .vscode directory with tasks.json, settings.json, c_cpp_properties.json, and launch.json.
- Configures the Build button to build the project.
- Configures Run and Debug panel to run avcdec and avcenc test benches.
Test: Build
Change-Id: Ifee9130f0041f77907a1a668227bc049270898e1
- Changed hardcoded index [0] to loop variable [i] in ithread_mutex_init call
- Ensures correct initialization of both mutexes in the loop
Test: ./avcdec
Change-Id: I95ccd1eec5f18b5391befbcedf3546a119681b54
In some erroneous fuzzer bistreams, the slice data requires more
parsing than what was implied by the distance between successive
start codes. The primary culprit is the NEXTBITS macro which requires
reading 4 additional bytes of the bitstream buffer. To alleviate
this, 4 bytes per 4x4 TU have been additionally allocated to the
bitstream buffer.
Bug = ossfuzz:66989
Test: mvc_dec_fuzzer
After some time of running these in postsubmit, these will be changed
to presubmit.
- Added AvcEncTest to device-tests test suite
- Also run bpfmt on test/Android.bp
Bug: 304383609
Test: atest AvcEncTest
Change-Id: Ic18b25d8ed27313b6e3a984259af1215ae240c9e
Although the fag end of both the NALU and the bitstream buffer
is being parsed, not all FGC SEI symbols would have been
decoded semantically. This commit detects and returns an error
in this situation.
Bug = ossfuzz:65418
Test: mvc_dec_fuzzer
'isvce_svc_rc_params_validate' was not being invoked prior to
call to 'isvce_rc_init'. This resulted in an erroneous state
within RC's context wherein the instantaneous estimate for the
texture bits for the frame being processed exceeded INT_MAX.
'isvce_svc_rc_params_validate' has code that detects such a
state and is now being correctly invoked where apprpriate.
Bug = ossfuzz:63175
Test: svc_enc_fuzzer
