Trigger IVD_RES_CHANGED when bit depth or chroma format changes in SPS,
forcing reallocation of picture buffers.
To prevent corrupting the codec state on invalid SPS parses, the updates to
global codec parameters (like i4_pixel_size_y and i4_bit_depth_luma) are
deferred to the end of ihevcd_parse_sps, after all validation checks have
passed. The resolution change check now compares the old active values in
ps_codec against the newly parsed values in the temporary ps_sps structure.
TAG=agy
CONV=2aef6402-f7fc-4ff8-ba56-d78e01754035
- Update ihevcd_parse_sps to parse profile dynamically from clip SPS (profile_idc, chroma format, bit depth, intra and still constraint flags).
- Add support for Main, Main 10, Main 10 Still, Main 422 10, Main 444, Main 444 10, Main Intra, Main 10 Intra, Main 422 10 Intra, Main 444 Intra, Main 444 10 Intra, and Main 444 Still Picture profiles.
- Allow profile_idc == 4 (RExt) in SPS profile validation checks.
- Update pixel size determination in ihevcd_api.c for 8-bit vs 10-bit profiles.
- Add CLI argument parsing for new profiles in main.c.
This is the initial version and doesn't enable SIMD functions yet.
Has not been tested extensively yet.
This is not ready to be merged into main branch yet.
Previously, when 422 or 444 chroma formats were encountered, all
function pointers were overridden to generic C implementations due to
lack of support in optimized assemblies/intrinsics for certain
components.
This change introduces `ihevcd_init_function_ptr_rext` which:
- First initializes all function pointers with architecture-optimized
versions.
- Explicitly overrides only the components not yet optimized for 422/444 formats (intra prediction, SAO, deblocking and chroma padding) to point
back to their C implementations.
This allows other fully-compatible modules (e.g: inter prediction modes, transform/reconstruction, format conversion) to benefit from SIMD
optimizations on 422/444 formats without degrading YUV 420 decoding.
Test: ./hevcdec
Change-Id: I013e44e024258f2f84690fdc0109200129042145
- disable_boundary_filter flag was not reset within the TU loop. This
caused the flag to remain sticky at 1 for all subsequent TUs in the
CTB once set by any TU.
- Transform-skip blocks larger than 4x4, the scaling/dequantization
matrix is bypassed and the scaling factor is set to a constant of 16
as per HEVC specification section 8.6.3.
- Bypassing the inverse transform for transform-skip blocks requires
applying a scaling of tsShift (Rec. ITU-T H.265 Section 8.6.2
Eq 8-296: tsShift = 5 + log2_trans_size) and descaling of bdShift
(Eq 8-295: bdShift = 20 - bit_depth).
Net shift: shift_ts = bdShift - tsShift
(20 - bit_depth) - (5 + log2_trans_size)
15 - bit_depth - log2_trans_size.
Test: ./hevcdec
Change-Id: I40411c04ab00d7e23842eb1d033c4543e4ec75e9
For clips with chroma format idc 444/422 and output format selected to
420, after decoding during chroma sampling conversion from 444/422 to
420, neighbor filtering is done currently. This is updated to area.
Test: ./hevcdec
Change-Id: I024886655084051093858c5c40a94c0373c64813
According to the ITU Specs (9.3.3.11) the statCoeff for
persistent rice adaptation must only be updated when the
parsing of coeff_abs_level_remaining is actually triggered.
Earlier, the i1_update_stats was incorrectly placed outside,
resulting stateCoeff getting incorrectly updated for the
first coefficient of every sub-block, and corrupting it.
Test: ./hevcdec
Change-Id: I7535ced74c18f55a7aff31d1c6d6d68f4a28f2cd
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: ./hevcdec
Change-Id: Id9faf0919ecedfd1833d40a7fbf6ddac454628b4
For 16x16 CTB sizes in chroma processing, au4_idx_tl[5] and
au4_idx_tl[6] can be set to -1 at picture boundaries. Added guards to
check that the index is valid (> idx_tl) before dereferencing the slice
header list.
Bug: 516422427
Test: ./hevc_dec_fuzzer
Change-Id: I40411c04ab00d7e23843eb1d033c6953e3ec76e9
Corrected the static SAO buffer size calculation to match the
partitioned buffer bounds. Luma requires 4x and Chroma requires 8x
MAX_CTB_SIZE * MAX_CTB_SIZE, which is now correctly summed to allocate
12x MAX_CTB_SIZE * MAX_CTB_SIZE bytes per process thread.
Bug: 484436016
Test: ./hevc_dec_fuzzer
Change-Id: I40411c04ab00d7e23843eb1d033d4943e3ec76a9
- reduce unused memory allocations
- revert unrequired alignments done to widths and height in format
conversion leaf functions
- pass correct strides and base address to leaf functions
fixes oss-fuzz-520748344
Change-Id: I8b783d1dae8c53b68a6d3a32dbc3ffb16376851e
Reverted some of the unnecessary changes from commit: f6ef16b0f9
- Restored the format conversion structure prior to f6ef16b0f9
- No need to handle odd stride for 420 and 422 output.
- Dimensions for output format 444 and 400 format can be odd
Tested with few YUV444 and YUV400 odd dimension clips
To generate:
$ ffmpeg -f lavfi -i testsrc=s=511x511 -c:v libx265 -pix_fmt yuv444p -t 1 -tag:v hvc1 y444_511x511.hevc
$ ffmpeg -f lavfi -i testsrc=s=511x511 -c:v libx265 -pix_fmt gray -t 1 -tag:v hvc1 y400_511x511.hevc
To decode using hevcdec for YUV420 output format
$ hevcdec -i y444_511x511.hevc -o y444_511x511.yuv --save_output 1 --num_frames -1 --chroma_format YUV_420P --enable_yuv_format 31
$ hevcdec -i y400_511x511.hevc -o y400_511x511.yuv --save_output 1 --num_frames -1 --chroma_format YUV_420P --enable_yuv_format 31
To decode using hevcdec for YUV444 output format
$ hevcdec -i y444_511x511.hevc -o y444_511x511.yuv --save_output 1 --num_frames -1 --chroma_format YUV_444P --enable_yuv_format 31
To decode using hevcdec for YUV400 output format
$ hevcdec -i y400_511x511.hevc -o y400_511x511.yuv --save_output 1 --num_frames -1 --chroma_format GRAY --enable_yuv_format 31
Display resulting output using ffplay by passing `-f rawvideo -pixel_format yuv420p -video_size 511x511`
Change pixel_format to yuv420p/yuv444p/gray based on decoder chroma_format argument
Decoding streams with odd resolutions previously caused integer truncation
during right-shift or division operations, leading to incorrect buffer size
and stride calculations.
This is fixed by applying the ALIGN2 macro to width and height across buffer
metrics, dimension queries, and outargs to safely pad boundaries.
Test: ./hevcdec
Change-Id: I5c432aa63b0975b76baa5e59a816278087b65215
Apply 0xAAAAAAAA mask for vertical chroma deblocking on YUV422 and YUV444.
Apply 0xAAAAAAAA mask for horizontal chroma deblocking on YUV444.
Add array indexing shifts for YUV422/YUV444 when log2_ctb_size != 6.
Test: ./hevcdec
Change-Id: I40411c04ab00d7e23843eb1d033c5943e3ec75e9
- Deleted ihevcd_sao_ctb implementation and declaration.
- Removed code under #else of SAO_PROCESS_SHIFT_CTB in ihevcd_process_slice.c.
- Removed code under #if FRAME_ILF_PAD and simplified checks assuming FRAME_ILF_PAD is 0.
- Deleted ihevcd_ilf_padding.c and removed it from Android.bp and libhevcdec.cmake.
- Removed SAO_PROCESS_SHIFT_CTB definition in ihevcd_defs.h.
- Removed FRAME_ILF_PAD definition in ihevcd_defs.h.
TAG=agy
CONV=ceba65ba-1766-4f4d-84f0-f7c3804a90fe
The function was processing all rows of chroma, while 420p only requires half the rows.
This caused an OOB write when writing to the destination buffer.
Fixed by skipping every other row of source chroma.
TAG=agy
Bug: ossfuzz:515832483
CONV=731dcda4-96d6-4402-b14c-f727e9983c85
- updated parser for 422 specific syntax elements
- updated iqitrecon module to handle 422 subtu's. Verified functionality
for intra only slices
- add support 422 i/o
- restrict combinations of output chroma format and internal chroma
format allowed. That is, for a given chroma format idc not all output
color formats are supported. The output format can now be either same
as internal color format or 420p.
Test: ./hevcdec
Change-Id: I9dbf5c141aceb8ffcbe063aa35856eeed11e3d4f
while computing chroma residue, the same buffer is used for both cb and
cr. So remove allocation made for cr. Further guard the memory
allocation for rext toolsets under the macro ENABLE_MAIN_REXT_PROFILE
Test: ./hevcdec
Change-Id: I773c9413d262a4b84bcc7ec71ac11ceaadfd839d