- 02 Apr, 2024 29 commits
-
-
Stefano Sabatini authored
-
Stefano Sabatini authored
Apply misc typo fixes, consistency fixes, and reformat the layout to provide more overall internal and global consistency.
-
James Almer authored
Signed-off-by:
James Almer <jamrial@gmail.com>
-
James Almer authored
Signed-off-by:
James Almer <jamrial@gmail.com>
-
James Almer authored
Signed-off-by:
James Almer <jamrial@gmail.com>
-
James Almer authored
Both samples rely on a feature our decoder doesn't currently support. Should fix fate failures on some systems where not even the one single frame could be generated. Signed-off-by:
James Almer <jamrial@gmail.com>
-
James Almer authored
The FATE suite has two already. Signed-off-by:
James Almer <jamrial@gmail.com>
-
Nuo Mi authored
passed files: LMCS_B_Dolby_2.bit CodingToolsSets_E_Tencent_1.bit SUBPIC_A_HUAWEI_3.bit SUBPIC_B_HUAWEI_3.bit SUBPIC_C_ERICSSON_1.bit SUBPIC_D_ERICSSON_1.bit SUBPIC_E_MediaTek_1.bit passed dvb conformance files (https://dvb.org/specifications/verification-validation/vvc-test-content): VVC_HDR_UHDTV1_OpenGOP_3840x2160_50fps_HLG10_mosaic.bit VVC_HDR_UHDTV1_OpenGOP_3840x2160_50fps_HLG10_PiP.bit
-
Nuo Mi authored
-
Nuo Mi authored
-
Nuo Mi authored
-
Nuo Mi authored
-
Nuo Mi authored
This change also make the lc->sc assigned for run_sao
-
Nuo Mi authored
-
Nuo Mi authored
-
Nuo Mi authored
-
Nuo Mi authored
-
Nuo Mi authored
-
Frank Plowman authored
Co-authored-by:
Nuo Mi <nuomi2021@gmail.com>
-
Frank Plowman authored
see "6.5.1 CTB raster scanning, tile scanning, and subpicture scanning processes" Co-authored-by:
Nuo Mi <nuomi2021@gmail.com>
-
Nuo Mi authored
-
Nuo Mi authored
we have to infer sh_collocated_from_l0_flag and sh_collocated_ref_idx from picture head if pps_rpl_info_in_ph_flag is true
-
Nuo Mi authored
see "8.3.6 Decoding process for collocated picture and no backward prediction"
-
James Almer authored
Suggested-by:
Andreas Rheinhardt <andreas.rheinhardt@outlook.com> Signed-off-by:
James Almer <jamrial@gmail.com>
-
James Almer authored
We only support mdta as type, yet we were not skipping other types, but rather reading key_size worth of bytes twice per entry. Signed-off-by:
James Almer <jamrial@gmail.com>
-
James Almer authored
Signed-off-by:
James Almer <jamrial@gmail.com>
-
Eugene Zemtsov authored
Stop reading keys and return AVERROR_INVALIDDATA if key_size is larger than the amount of space left in the atom. Bug: https://crbug.com/41496983Signed-off-by:
Eugene Zemtsov <eugene@chromium.org> Signed-off-by:
James Almer <jamrial@gmail.com>
-
Andreas Rheinhardt authored
Fixes: memleak Fixes: 67714/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-5671570999476224 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegReviewed-by:
Michael Niedermayer <michael@niedermayer.cc> Signed-off-by:
Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
James Almer authored
Fixes: null pointer dereference Fixes: 67494/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-6528714521247744 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegTested-by:
Michael Niedermayer <michael@niedermayer.cc> Signed-off-by:
James Almer <jamrial@gmail.com>
-
- 01 Apr, 2024 11 commits
-
-
Andreas Rheinhardt authored
It is more natural and simplifies writing these arrays. Signed-off-by:
Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
VLC_MULTI_ELEM contains an uint8_t array that is supposed to be treated as an array of uint16_t when the used symbols have a size of two; otherwise it should be treated as just an array of uint8_t, but it was not always treated that way: vlc_multi_gen() initialized the first entry of the array by writing the symbol via AV_WN16; on big endian systems, the intended value was instead written into the second entry of the array (where it would likely be overwritten lateron during initialization). read_vlc_multi() also treated this case incorrectly: In case the code is so long that it needs a classical multi-stage lookup, the symbol has been written to the destination as if via AV_WN16. On little endian systems, this sets the correct first symbol and clobbers (zeroes) the next one, but the next one will be overwritten lateron anyway, so it won't be recognized. But on big-endian systems, the first symbol will be set to zero and the actually read symbol will be put into the slot for the next one (where it will be overwritten lateron). This commit fixes this; this fixes the magicyuv and utvideo FATE-tests on big endian arches. Signed-off-by:
Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
The fits decoder decodes to native pixel formats; so the fitsdec-gbrap16be fate test failed on BE despite its name because the reference file is LE. This patch fixes this by forcing a pixel format; the forced pixel format is BE, causing a change in the reference file. The fitsdec-gbrp16be test was not affected, because its source file (lena-rgb48.png from tne FATE suite) is actually biendian (as if someone had multiplied 8bit content by 257...). Signed-off-by:
Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
The format and the first scale filter ensures that the filter processing actually happens in high bit depth; the second scale filter is only necessary for big endian arches. Signed-off-by:
Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Fixes filter-metadata-signalstats-yuv420p10 on BE arches. Signed-off-by:
Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Precludes the usage of the altivec IDCT which fixes the avid-meridian FATE test on ppc64be here. Signed-off-by:
Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Affected many ffvhuff FATE tests. Signed-off-by:
Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Affected the vf-spp FATE-test (on x86 only when MMX is disabled). Signed-off-by:
Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Affected the lscr fate-test (only visible on x86 if the SSE2 is disabled). Signed-off-by:
Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
It is UB and affected e.g. the vp5 and vp61 FATE tests: https://fate.ffmpeg.org/report.cgi?time=20240327083327&slot=ppc-linux-gcc-13.2-ubsan-altivec-qemuSigned-off-by:
Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
David Rosca authored
-