This fix does look reasonable. (Although a plain echo "$2" also should work instead of printf '%s' "$2" here I think?)
avio_write and ffio_reset_dyn_buf call into the if statements; it could stay below in the place of the original avio_write and av_free.
]]>-retry_errors option, defaulting to 1. Rather than not marking failed blocks, this option instead makes the reading code interpret the FAILED state as identical to the NONE state.
I think that's overall more useful than vice versa, since it allows users to opt back out of this behavior later on.
]]>sub_packet index in QDM2Context was not reset to 0 whenqdm2_decode_frame started processing a new packet. If an errorsub_packet wouldIn subsequent calls to qdm2_decode_frame with a new packet, this
non-zero sub_packet value caused qdm2_decode to skip
qdm2_decode_super_block. This function is responsible for initializing
packet lists with pointers to the current packet's data. Skipping it led
to the use of stale pointers from the previous (freed) packet, resulting
in a heap-use-after-free vulnerability.
This patch explicitly resets s->sub_packet = 0 at the beginning of
qdm2_decode_frame, ensuring correct initialization for each new
packet.
Fixes: OSS-Fuzz issue 476179569
(https://issues.oss-fuzz.com/issues/476179569).
When transcoding an HDR HEVC video (BT.2020 color space) to H.264 using the hardware encoder h264_ohcodec on OpenHarmony platform, the output video is completely green. All color information appears to be lost during the transcoding process. The video structure and playback are normal, but the visual content is entirely green.
ffmpeg version 8.0 (commit 8134b803)
built with OHOS (dev) clang version 15.0.4 (llvm-project 115b628d33dda4da4b17e14ed69dd8b74c058b48)
ffmpeg -y -i /data/storage/el2/base/haps/entry/cache/input_video.mp4 \
-c:v h264_ohcodec \
-an \
/data/storage/el2/base/haps/entry/cache/out_hw.mp4
The complete log file is available at: ffmpeg_complete_log.txt
WARNING: library configuration mismatch
ffmpeg configuration: --prefix=/Users/wanyang/Documents/DmMp4parser/tpc_c_cplusplus/lycium/usr/FFmpeg_n6.1.2/arm64-v8a ...
avutil configuration: --prefix=/Users/wanyang/Documents/tpc_c_cplusplus/lycium/usr/FFmpeg-ff8.0/arm64-v8a/ ...
[graph 0 input from stream 0:1 @ 0x5b27be33c0] Changing video frame properties on the fly is not supported by all filters.
[graph 0 input from stream 0:1 @ 0x5b27be33c0] filter context - w: 1920 h: 1080 fmt: 62 csp: gbr range: unknown, incoming frame - w: 1920 h: 1080 fmt: 62 csp: bt2020nc range: tv pts_time: 2.632833
[swscaler @ 0x5b27d45800] YUV color matrix differs for YUV->YUV, using intermediate RGB to convert
[hevc @ 0x5b27dc6d00] Mastering Display Metadata:
[hevc @ 0x5b27dc6d00] r(0.2650,0.6900) g(0.1500,0.0600) b(0.6800 0.3200) wp(0.3127, 0.3290)
[hevc @ 0x5b27dc6d00] min_luminance=0.005000, max_luminance=1000.000000
[hevc @ 0x5b27dc6d00] Content Light Level Metadata:
[hevc @ 0x5b27dc6d00] MaxCLL=1000, MaxFALL=0
frame= 82 fps= 34 q=-0.0 Lsize= 247kB time=-577014:32:22.77 bitrate=N/A speed=N/A
video:245kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.544112%
Input Video:
Input Video Stream Details:
Stream #0:1 [0x2]: Video: hevc (Main 10), 1 reference frame (hvc1 / 0x31637668), yuv420p10le(tv, bt2020nc/bt2020/arib-std-b67, left), 1920x1080, 0/1, 21932 kb/s, 30.01 fps, 30 tbr, 90k tbn
The output video should maintain proper color information when transcoding from HEVC (HDR, BT.2020) to H.264 (SDR, BT.709) using the hardware encoder. The color space conversion should be handled correctly without producing green-only output.
The output video is completely green. All color information appears to be lost during the transcoding process. The video structure and playback are normal, but the visual content is entirely green.
ffmpeg_complete_log.txt - Full FFmpeg log with all debug informationh264_ohcodec on OpenHarmony platform