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>
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
- 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
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
There can be cases where there are multiple SEI payloads within a
single SEI NAL. In the particulkar case where the payload comprises
exclusiely of FGC data, the size of the NAL can exceed the size
of the 'dynamic bitstream buffer' which is used to pass the NALU
onto its appropriate parser.
This commit adds 'imvcd_bitstream_buf_realloc' which re-allocates
the 'dynamic bitstream buffer' such that any arbitrarily sized
NALU can be stored without a heap overflow.
Bug = ossfuzz:64286
Test: svc_enc_fuzzer
The cases where the value for log2MaxPocLsb was exceeding
'MAX_BITS_IN_POC_LSB' was not being handled correctly,
which was resulting in an integer overflow. This has been
fixed.
Test: mvc_dec_fuzzer
[x] For certain sequences of modification_of_pic_nums_idc,
OOB accessses of the aps_mod_dpb buffer within mvc_dpb_manager_t
struct could occur. This case has been now detected
and handled.
[x] Removed unused variables in 'imvcd_slice_functions.c'.
Test: mvc_dec_fuzzer
The worst case FGC SEI payload size in cojunction with the worst
case sizes of other NALU's can be significantly larger than the
default bitstream buffer size of 256000. It is now set to the sum
of 256000 and MAX_FGC_SEI_SIZE.
Bug: ossFuzz:58190
Test: mvc_dec_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
- 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
