Closed
Conversation
It was possible for the buffer pointers for the last tile to go over the end of the unit buffer leading to a read overflow during decode of the macroblock layer. Check all tile component sizes to prevent this case and also catch related tile size mismatch errors earlier.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Ensure bitexact passthrough using the apv_metadata bsf. Signed-off-by: James Almer <jamrial@gmail.com>
Fix chroma_location being cleared by setrange and setfield filters. This was forgotten in 201f1cb. Signed-off-by: Tobias Rapp <t.rapp@noa-archive.com>
In the call to vkGetPhysicalDeviceImageFormatProperties2(), we were previously requesting the properties of the first fallback format (e.g. VK_FORMAT_R8_UNORM for VK_FORMAT_G8_B8R8_2PLANE_420_UNORM) instead of the actual format in use. We don’t do anything with it afterwards, but there is no reason to keep querying the wrong format.
…hantom CINE file format Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Libpostproc will be available as source plugin at https://github.com/michaelni/FFmpeg/tree/sourceplugin-libpostproc OR https://github.com/michaelni/libpostproc whatever turns out more convenient to maintain For the upcoming 8.0 release, libpostproc will be included, so as not to cause delays or inconveniences Sponsored-by: Sovereign Tech Fund Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
liboapv will seemingly encode correct 4:4:4 output, but report profile_idc 33, which is specifically the profile value for 4:2:2 10bit. Signed-off-by: James Almer <jamrial@gmail.com>
Some videos of "StarWars - Making Magic" have this subcompression type: data just consists of the 16 byte codec48 header; the DOS player and the c48 decoder in the "Mysteries of the Sith" game engine ignore it. Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Change the size detection a bit to recognize common video sizes, as the FOBJ codecs>=37 cannot always be trusted, since they can be embedded in a larger frame. Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Videos of "StarWars - Making Magic" consist of 640x480 codec3 frames which establish a background, and a 320x240 codec48 video put on top at random left/top offsets. To support this, a new default buffer "fbuf", which holds the final image to be presented, is added, since codec37/47/48 need their 2/3 buffers to be private to themselves. The decoded result is then copied to the fbuf, honoring the left/top offsets if required. Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Fixes: 391935573/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MMVIDEO_fuzzer-4655048979709952 Fixes: out of array access Reviewed-by: Peter Ross <pross@xvid.org> Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: division by 0 Fixes: 395163171/clusterfuzz-testcase-minimized-ffmpeg_dem_IFF_fuzzer-542604339373670 Reviewed-by: Peter Ross <pross@xvid.org> Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: out of array read in decode_cu_16x16() Fixes: 398049430/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RV60_fuzzer-5525836849807360 Reviewed-by: Peter Ross <pross@xvid.org> Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: shift exponent 49 is too large for 32-bit type 'int' Fixes: 398060145/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5023082406543360 Reviewed-by: James Almer <jamrial@gmail.com> Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Codec probing was primarily added to the wav demuxer to support DTS-in-wav files, but DTS probing functions return AVPROBE_SCORE_EXTENSION+1, so we can be a bit more strict with the required score. This fixes MP3 misdetections for some wav files. Fixes ticket #11581. Signed-off-by: Marton Balint <cus@passwd.hu>
Elapsed time is much less important than the actual progress, and I am guessing several ffmpeg CLI frontends use the existing status line for showing progress, so putting a new field in the beginning is less optimal anyway. Related to ticket #11582. Signed-off-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
…avoid misdetection of mp3 as VVC The current vvc_probe function checks for SPS, PPS, and IRAP NAL units but does not enforce their detection order. This can lead to false positives when PPS or IRAP appear before SPS, causing malformed or non-compliant bitstreams to be incorrectly identified as valid VVC streams. This commit modifies the logic to use boolean flags and enforces the correct detection sequence: SPS must be detected before PPS, and PPS before IRAP. This ensures more accurate probing and prevents invalid bitstreams from being misidentified. For streams with wrong ordering a lower score is returned This change addresses issues reported in: - https://trac.ffmpeg.org/ticket/11496 - https://trac.ffmpeg.org/ticket/11087 Signed-off-by: xiongweixiao <xiongweixiaoxxw@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This differs from libvorbis by stddev: 2.44 PSNR: 88.58 MAXDIFF: 41 bytes: 834304/ 834304 for the file from the ticket Fixes: Ticket11427 Regression since: dc89cf8 This is a similar solution to what james proposed earlier in [FFmpeg-devel] [PATCH] avcodec/vorbisdec: don't abort on EOD when decoding residuals Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When decoding a bitstream with weighted-bipred enabled, the results on ARM and x86 platforms may differ. The reason for the inconsistency is that the value of STRIDE_ALIGN differs between platforms. And STRIDE_ALIGN is set to the buffer stride of temporary buffers for U and V components in mc_part_weighted. If the buffer stride is 32 or 64 (as on x86 platforms), the U and V pixels can be interleaved row by row without overlapping, resulting in correct output. However, on ARM platforms where the stride is 16, the V component did overwrite part of the U component's pixels, leading to incorrect predicted pixels. The bug can be reproduced by the following bitstream. https://trac.ffmpeg.org/attachment/ticket/11357/inter_weighted_bipred2.264 Fixes: ticket 11357 Commit-msg-mostly-by: Bin Peng <pengbin@visionular.com> Reviewed-by: Bin Peng <pengbin@visionular.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: poc-iamf-2025-04 Found-by: 苏童 <220235212@seu.edu.cn> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Same setup as the 422-10 profile test, using the same content. FFmpeg decoder output is identical to the reference decoder output.
Caught by ubsan - would cause an invalid shift in constructing the run value.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Marvin Scholz <epirat07@gmail.com> Co-authored-by: Marvin Scholz <epirat07@gmail.com>
The issue is that there is an explicit lack of synchronization as only the very first invocation writes symbols and updates the state, which other invocations then store.
Signed-off-by: Marvin Scholz <epirat07@gmail.com>
Signed-off-by: Marvin Scholz <epirat07@gmail.com>
The SLIBOBJS variable was introduced in 5657278 but is no longer used. Another variable, SHLIBOBJS, was introduced after SLIBOBJS, in 20b0d24. The functionality from SLIBOBJS was effectively migrated to SHLIBOBJS in b77fff4. No code has used SLIBOBJS since. This commit removes all remaining references to SLIBOBJS from the build system.
…444p Currently, planarCopyWrapper() assumes that src[3] must be NULL when the source format has no alpha plane. This commit updates the condition for filling the alpha plane based on the number of components available in the source format as well.
… between 9-14 bits Currently, packed30togbra10() always sets the alpha value to 0xFFFF, without taking the bit depth into consideration. This commit restricts the alpha value to the bit depth.
… between 9-14 bits Currently, packed16togbra16() always sets the alpha value to 0xFFFF, without taking the bit depth into consideration. This causes a bug on x86, which can be reproduced with: ./libswscale/tests/swscale -unscaled 1 -src xyz12le -dst gbrap12be The problem arises in ff_hscale14to15_4_ssse3(), in the conversion from gbrap12be to yuva444p, which comes after the conversion from xyz12le to gbrap12be. It has something to do with pmaddwd not working on unsigned values. There is some code to deal with 0xFFFF if the input has a bit depth of 16, but not for bit depths < 16. We could fix ff_hscale14to15_4_ssse3() to also work correctly with 0xFFFF on bit depths < 16, or we could just not write 0xFFFF there in the first place, which is what this commit does.
…ts with bpc between 9-14 bits Currently, planarRgbToplanarRgbWrapper() always sets the alpha value to 255, without taking the bit depth into consideration. This commit restricts the alpha value to the bit depth.
The buffer references may not be writable at this point, as the decoder calls get_buffer2() with the AV_GET_BUFFER_FLAG_REF flag. Fixes races as reported by tsan, producing correct output regardless of threading choices. Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Exercising the lavfi filtergraph codepath to choose the best output layout. Signed-off-by: James Almer <jamrial@gmail.com>
io_open and io_close2 callbacks may use opaque pointer stored in the context. They are already inherited, so opaque should also be passed through. Fixes IMF playback in mpv. Signed-off-by: Kacper Michajłow <kasper93@gmail.com> Reviewed-by: Pierre-Anthony Lemieux <pal@sandflow.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: #11493 Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Flipping can already be accomplished by setting the crop_w/h expressions to their negative values, so together these options can implement any of the common frame orientations.
Useful to speed up shader compilation. May significantly lower startup times, in particular with large or complex shaders. Sponsored-by: nxtedition
Don't use a 7.1 EAC3 input file for which our decoder is not bitexact; instead just use the asynth-44100-8.wav file which (as a 7.1 file) exhibits the same issue fixed by 1b3f484. (Either the encoder or the resampler are still not completely bitexact, so we limit the number of frames output.) Also switch to a framecrc test so that the output channel layout is directly contained in the ref file. Reviewed-by: James Almer <jamrial@gmail.com> Reviewed-by: Martin Storsjö <martin@martin.st> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The issue is that state->cur[] is 8-bits, but a+b+1 can overflow before being clipped to 0xF in the following line, causing an incorrect state to be saved for the next symbol. This solves numerous bitstream desyncs, particularly when coefficients with magnitude greater than 127 are sent.
Fixes a crash triggered by a fuzzed clip: https://github.com/ffvvc/tests/tree/main/fuzz/passed/000256.bit Reproduce with: ffmpeg -i 000256.bit -f null -
In d5dbcc0, it was hoped that detection of subpicture overlaps could be performed at the tile level, so as to avoid introducing per-CTU checks. Unfortunately since that patch, fuzzing has indicated there are some structures involving pps_subpic_one_or_more_tiles_slice where tile-level checking is not sufficient. Performing the check at the CTU level should (touch wood) be the be-all and and-all of this, as CTUs are the lowest common denominator of the picture partitioning. Signed-off-by: Frank Plowman <post@frankplowman.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.