Feed of "FFmpeg" https://code.ffmpeg.org/FFmpeg 2026-02-03T10:13:12Z <p dir="auto">A complete, cross-platform solution to record, convert and stream audio and video.</p> ronag commented on pull request FFmpeg/FFmpeg#21600 2026-02-03T08:36:46Z 656685: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21600#issuecomment-24395 avformat: add shared concurrent block cache protocol <p dir="auto">BLOCK_NONE if we are remove BLOCK_FAILED</p> avformat: add shared concurrent block cache protocol <p dir="auto">BLOCK_NONE if we are remove BLOCK_FAILED</p> ronag [email protected] dkozinski commented on pull request FFmpeg/FFmpeg#21418 2026-02-03T05:50:37Z 656618: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21418#issuecomment-24391 avcodec/liboapvenc: Added support for mastering display color volume and content light level metadata <p dir="auto">Replaced custom serialize_metadata_cll() with the library&#39;s oapvm_write_cll()</p> avcodec/liboapvenc: Added support for mastering display color volume and content light level metadata <p dir="auto">Replaced custom serialize_metadata_cll() with the library&#39;s oapvm_write_cll()</p> dkozinski [email protected] dkozinski commented on pull request FFmpeg/FFmpeg#21418 2026-02-03T05:47:33Z 656551: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21418#issuecomment-24390 avcodec/liboapvenc: Added support for mastering display color volume and content light level metadata <p dir="auto">I&#39;ve replaced the custom metadata serialization with oapvm_write_mdcv.</p> avcodec/liboapvenc: Added support for mastering display color volume and content light level metadata <p dir="auto">I&#39;ve replaced the custom metadata serialization with oapvm_write_mdcv.</p> dkozinski [email protected] oliverchang created pull request FFmpeg/FFmpeg#21635 2026-02-03T05:42:59Z 656483: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21635 <p dir="auto">The <code>sub_packet</code> index in <code>QDM2Context</code> was not reset to 0 when<br/> <code>qdm2_decode_frame</code> started processing a new packet. If an error<br/> occurred during the decoding of a previous packet, <code>sub_packet</code> would<br/> retain a non-zero value.</p> <p dir="auto">In subsequent calls to <code>qdm2_decode_frame</code> with a new packet, this<br/> non-zero <code>sub_packet</code> value caused <code>qdm2_decode</code> to skip<br/> <code>qdm2_decode_super_block</code>. This function is responsible for initializing<br/> packet lists with pointers to the current packet&#39;s data. Skipping it led<br/> to the use of stale pointers from the previous (freed) packet, resulting<br/> in a heap-use-after-free vulnerability.</p> <p dir="auto">This patch explicitly resets <code>s-&gt;sub_packet = 0</code> at the beginning of<br/> <code>qdm2_decode_frame</code>, ensuring correct initialization for each new<br/> packet.</p> <p dir="auto">Fixes: OSS-Fuzz issue 476179569<br/> (<a href="https://issues.oss-fuzz.com/issues/476179569" rel="nofollow">https://issues.oss-fuzz.com/issues/476179569</a>).</p> 21635#avcodec/qdm2: fix heap-use-after-free in qdm2_decode_frame# oliverchang [email protected] dkozinski commented on pull request FFmpeg/FFmpeg#21418 2026-02-03T05:42:47Z 656416: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21418#issuecomment-24386 avcodec/liboapvenc: Added support for mastering display color volume and content light level metadata <p dir="auto">Done. I&#39;ve removed the separate struct</p> avcodec/liboapvenc: Added support for mastering display color volume and content light level metadata <p dir="auto">Done. I&#39;ve removed the separate struct</p> dkozinski [email protected] woerte197 opened issue FFmpeg/FFmpeg#21634 2026-02-03T05:05:26Z 656346: https://code.ffmpeg.org/FFmpeg/FFmpeg/issues/21634 <h2 id="user-content-issue-description" dir="auto">Issue Description</h2> <p dir="auto">When transcoding an HDR HEVC video (BT.2020 color space) to H.264 using the hardware encoder <code>h264_ohcodec</code> 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.</p> <h2 id="user-content-ffmpeg-version" dir="auto">FFmpeg Version</h2> <pre class="code-block"><code class="chroma language-text display">ffmpeg version 8.0 (commit 8134b803) built with OHOS (dev) clang version 15.0.4 (llvm-project 115b628d33dda4da4b17e14ed69dd8b74c058b48) </code></pre><h2 id="user-content-command-line-used" dir="auto">Command Line Used</h2> <pre class="code-block"><code class="chroma language-bash display">ffmpeg -y -i /data/storage/el2/base/haps/entry/cache/input_video.mp4 <span class="se">\ </span><span class="se"></span> -c:v h264_ohcodec <span class="se">\ </span><span class="se"></span> -an <span class="se">\ </span><span class="se"></span> /data/storage/el2/base/haps/entry/cache/out_hw.mp4 </code></pre><h2 id="user-content-complete-log" dir="auto">Complete Log</h2> <p dir="auto">The complete log file is available at: <a href="/FFmpeg/FFmpeg/ffmpeg_complete_log.txt" rel="nofollow">ffmpeg_complete_log.txt</a></p> <h2 id="user-content-key-log-entries" dir="auto">Key Log Entries</h2> <h3 id="user-content-1-configuration-mismatch-warning" dir="auto">1. Configuration Mismatch Warning</h3> <pre class="code-block"><code class="chroma language-text display">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/ ... </code></pre><h3 id="user-content-2-color-space-conversion-warnings" dir="auto">2. Color Space Conversion Warnings</h3> <pre class="code-block"><code class="chroma language-text display">[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 </code></pre><h3 id="user-content-3-yuv-color-matrix-conversion-warning" dir="auto">3. YUV Color Matrix Conversion Warning</h3> <pre class="code-block"><code class="chroma language-text display">[swscaler @ 0x5b27d45800] YUV color matrix differs for YUV-&gt;YUV, using intermediate RGB to convert </code></pre><h3 id="user-content-4-hdr-metadata-detected" dir="auto">4. HDR Metadata Detected</h3> <pre class="code-block"><code class="chroma language-text display">[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 </code></pre><h3 id="user-content-5-encoding-statistics" dir="auto">5. Encoding Statistics</h3> <pre class="code-block"><code class="chroma language-text display">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% </code></pre><h2 id="user-content-input-file-information" dir="auto">Input File Information</h2> <p dir="auto"><strong>Input Video:</strong></p> <ul dir="auto"> <li>Codec: HEVC (H.265) Main 10 Profile</li> <li>Resolution: 1920x1080</li> <li>Color Space: BT.2020 (HDR)</li> <li>Color Transfer: BT.2020</li> <li>Color Primaries: BT.2020</li> <li>Bit Depth: 10-bit (yuv420p10le)</li> <li>HDR Metadata: Present (Mastering Display and Content Light Level)</li> </ul> <p dir="auto"><strong>Input Video Stream Details:</strong></p> <pre class="code-block"><code class="chroma language-text display">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 </code></pre><h2 id="user-content-platform-information" dir="auto">Platform Information</h2> <ul dir="auto"> <li><strong>OS</strong>: OpenHarmony (HarmonyOS Next) API Level 6 (N6.1.2)</li> <li><strong>Architecture</strong>: ARM64 (aarch64)</li> <li><strong>FFmpeg Version</strong>: 8.0 (commit 8134b803)</li> <li><strong>Hardware Encoder</strong>: h264_ohcodec (OpenHarmony hardware codec)</li> <li><strong>Compiler</strong>: clang version 15.0.4</li> </ul> <h2 id="user-content-expected-behavior" dir="auto">Expected Behavior</h2> <p dir="auto">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.</p> <h2 id="user-content-actual-behavior" dir="auto">Actual Behavior</h2> <p dir="auto">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.</p> <h2 id="user-content-files-attached" dir="auto">Files Attached</h2> <ul dir="auto"> <li><strong>Complete Log</strong>: <code>ffmpeg_complete_log.txt</code> - Full FFmpeg log with all debug information</li> <li><strong>Input Video</strong>: HEVC video with HDR/BT.2020 metadata (can be provided upon request)</li> </ul> <h2 id="user-content-reproduction-steps" dir="auto">Reproduction Steps</h2> <ol dir="auto"> <li>Use FFmpeg 8.0 with hardware encoder <code>h264_ohcodec</code> on OpenHarmony platform</li> <li>Transcode an HDR HEVC video (BT.2020 color space) to H.264</li> <li>Use the command provided in &#34;Command Line Used&#34; section</li> <li>Observe that the output video is completely green</li> </ol> <h2 id="user-content-environment-details" dir="auto">Environment Details</h2> <ul dir="auto"> <li><strong>Operating System</strong>: OpenHarmony (HarmonyOS Next) API Level 6 (N6.1.2)</li> <li><strong>Device</strong>: ARM64 device</li> <li><strong>FFmpeg Build</strong>: Custom build with OpenHarmony hardware codec support</li> <li><strong>Hardware Encoder</strong>: h264_ohcodec (OpenHarmony hardware codec)</li> </ul> 21634#h264_ohcodec Hardware Encoder Produces Green Video Output# woerte197 [email protected] Valerii Zapodovnikov closed pull request FFmpeg/FFmpeg#20091 2026-02-03T03:05:39Z 656277: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20091#issuecomment-24383 h264_parser: avoid marking non-IDR I-frames as keyframes when DPB is not empty h264_parser: avoid marking non-IDR I-frames as keyframes when DPB is not empty Valerii Zapodovnikov [email protected] James Almer commented on pull request FFmpeg/FFmpeg#21628 2026-02-03T02:34:26Z 656206: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21628#issuecomment-24376 avformat/demux: don&#39;t overwrite already set packet durations with parser ones <p dir="auto">Ok, the codec allows for packets to have varying duration, so will try a different approach.</p> avformat/demux: don't overwrite already set packet durations with parser ones <p dir="auto">Ok, the codec allows for packets to have varying duration, so will try a different approach.</p> James Almer [email protected] Zhanheng.Yang commented on pull request FFmpeg/FFmpeg#21538 2026-02-03T02:16:25Z 656138: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21538#issuecomment-24375 libavcodec/riscv: add RVV optimized for qpel/epel in HEVC. <p dir="auto">Hi <a href="/Courmisch" class="mention" rel="nofollow">@Courmisch</a> , I&#39;ve incorporated your suggestions into the PR. Could you please take another look when convenient? Thanks</p> libavcodec/riscv: add RVV optimized for qpel/epel in HEVC. <p dir="auto">Hi <a href="/Courmisch" class="mention" rel="nofollow">@Courmisch</a> , I&#39;ve incorporated your suggestions into the PR. Could you please take another look when convenient? Thanks</p> Zhanheng.Yang [email protected] Jack Lau created pull request FFmpeg/FFmpeg#21633 2026-02-03T02:16:03Z 656071: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21633 <p dir="auto">The <code>localport</code> already deprecated in 3a29702cb6b8f9dcb1aa66bb65d04b392f9de98d</p> <p dir="auto">Signed-off-by: Jack Lau <a href="mailto:[email protected]" rel="nofollow">[email protected]</a></p> 21633#avformat/rtsp: replace the deprecated `localport` with `localrtpport`# Jack Lau [email protected] stevenliu approved FFmpeg/FFmpeg#21599 2026-02-03T02:08:07Z 656002: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21599#issuecomment-24370 avformat/hlsenc: fix format string vulnerability in parse_playlist (alternative fix) avformat/hlsenc: fix format string vulnerability in parse_playlist (alternative fix) stevenliu [email protected] Valerii Zapodovnikov commented on pull request FFmpeg/FFmpeg#21632 2026-02-03T01:28:44Z 655934: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21632#issuecomment-24369 avcodec/hevc/hevcdec: take into account YUV400 in block length <p dir="auto">Yay</p> avcodec/hevc/hevcdec: take into account YUV400 in block length <p dir="auto">Yay</p> Valerii Zapodovnikov [email protected] James Almer commented on pull request FFmpeg/FFmpeg#21628 2026-02-02T23:43:59Z 655866: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21628#issuecomment-24366 avformat/demux: don&#39;t overwrite already set packet durations with parser ones <p dir="auto">It should, afaik. libopusenc sets it, for example.</p> avformat/demux: don't overwrite already set packet durations with parser ones <p dir="auto">It should, afaik. libopusenc sets it, for example.</p> James Almer [email protected] James Almer pushed to master at FFmpeg/FFmpeg 2026-02-02T23:21:22Z 655798: https://code.ffmpeg.org/FFmpeg/FFmpeg/commit/836d34e3bab29cf7e962a1e9360329d9e52f7a4b <a href="https://code.ffmpeg.org/FFmpeg/FFmpeg/commit/836d34e3bab29cf7e962a1e9360329d9e52f7a4b" rel="nofollow">836d34e3bab29cf7e962a1e9360329d9e52f7a4b</a> avformat/tests/movenc: Make objects static <a href="https://code.ffmpeg.org/FFmpeg/FFmpeg/commit/836d34e3bab29cf7e962a1e9360329d9e52f7a4b">836d34e3bab29cf7e962a1e9360329d9e52f7a4b</a> avformat/tests/movenc: Make objects static James Almer [email protected] James Almer merged pull request FFmpeg/FFmpeg#21631 2026-02-02T23:21:21Z 655731: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21631 avformat/tests/movenc: Make objects static avformat/tests/movenc: Make objects static James Almer [email protected] Valerii Zapodovnikov commented on pull request FFmpeg/FFmpeg#21630 2026-02-02T23:11:37Z 655663: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21630#issuecomment-24361 avcodec/hevc/hevcdec: take into account YUV400 in block length <p dir="auto">Accidently closed it, see <a href="https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21632" class="ref-issue" rel="nofollow">#21632</a></p> avcodec/hevc/hevcdec: take into account YUV400 in block length <p dir="auto">Accidently closed it, see <a href="https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21632" class="ref-issue" rel="nofollow">#21632</a></p> Valerii Zapodovnikov [email protected] Valerii Zapodovnikov created pull request FFmpeg/FFmpeg#21632 2026-02-02T23:11:07Z 655595: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21632 <p dir="auto">Signed-off-by: Valerii Zapodovnikov <a href="mailto:[email protected]" rel="nofollow">[email protected]</a></p> <p dir="auto">See issue <a href="/FFmpeg/FFmpeg/issues/11551" class="ref-issue" rel="nofollow">#11551</a>.</p> 21632#avcodec/hevc/hevcdec: take into account YUV400 in block length# Valerii Zapodovnikov [email protected] James Almer merged pull request FFmpeg/FFmpeg#21630 2026-02-02T23:06:56Z 655527: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21630 avcodec/hevc/hevcdec: take into account YUV400 in block length avcodec/hevc/hevcdec: take into account YUV400 in block length James Almer [email protected] James Almer commented on pull request FFmpeg/FFmpeg#21630 2026-02-02T22:45:31Z 655458: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21630#issuecomment-24354 avcodec/hevc/hevcdec: take into account YUV400 in block length avcodec/hevc/hevcdec: take into account YUV400 in block length James Almer [email protected] James Almer approved FFmpeg/FFmpeg#21631 2026-02-02T22:31:55Z 655390: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21631#issuecomment-24350 avformat/tests/movenc: Make objects static avformat/tests/movenc: Make objects static James Almer [email protected] James Almer commented on pull request FFmpeg/FFmpeg#21630 2026-02-02T22:31:42Z 655323: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21630#issuecomment-24348 avcodec/hevc/hevcdec: take into account YUV400 in block length <p dir="auto">The sample starts printing several errors about cu_qp_delta being out of valid range, so that&#39;s doubtful.</p> avcodec/hevc/hevcdec: take into account YUV400 in block length <p dir="auto">The sample starts printing several errors about cu_qp_delta being out of valid range, so that&#39;s doubtful.</p> James Almer [email protected] Valerii Zapodovnikov commented on pull request FFmpeg/FFmpeg#21630 2026-02-02T22:22:23Z 655255: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21630#issuecomment-24347 avcodec/hevc/hevcdec: take into account YUV400 in block length <p dir="auto">Sigh, it breaks fate-hevc-conformance-DELTAQP_A_BRCM_4. Or fixes it likely.</p> avcodec/hevc/hevcdec: take into account YUV400 in block length <p dir="auto">Sigh, it breaks fate-hevc-conformance-DELTAQP_A_BRCM_4. Or fixes it likely.</p> Valerii Zapodovnikov [email protected] frankplow commented on pull request FFmpeg/FFmpeg#21630 2026-02-02T22:14:01Z 655187: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21630#issuecomment-24345 avcodec/hevc/hevcdec: take into account YUV400 in block length <p dir="auto">Nit: could you keep the indentation the same as it was before where possible, in order to make the diff easier to read.</p> avcodec/hevc/hevcdec: take into account YUV400 in block length <p dir="auto">Nit: could you keep the indentation the same as it was before where possible, in order to make the diff easier to read.</p> frankplow [email protected] mkver created pull request FFmpeg/FFmpeg#21631 2026-02-02T22:09:55Z 655119: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21631 <p dir="auto">(This also fixes a symbol name collision with libssh,<br/> which has a nonstatic function called md5.)</p> 21631#avformat/tests/movenc: Make objects static# mkver [email protected] mkver commented on pull request FFmpeg/FFmpeg#21628 2026-02-02T21:58:21Z 655047: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21628#issuecomment-24339 avformat/demux: don&#39;t overwrite already set packet durations with parser ones <p dir="auto">The documentation for frame_size says that the number of samples per frame is constant. How do you know that it is constant?</p> avformat/demux: don't overwrite already set packet durations with parser ones <p dir="auto">The documentation for frame_size says that the number of samples per frame is constant. How do you know that it is constant?</p> mkver [email protected] James Almer commented on pull request FFmpeg/FFmpeg#21630 2026-02-02T21:51:49Z 654980: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21630#issuecomment-24337 avcodec/hevc/hevcdec: take into account YUV400 in block length <p dir="auto">Should be <code>sps-&gt;pcm.bit_depth_chroma) : 0;</code></p> avcodec/hevc/hevcdec: take into account YUV400 in block length <p dir="auto">Should be <code>sps-&gt;pcm.bit_depth_chroma) : 0;</code></p> James Almer [email protected] Valerii Zapodovnikov created pull request FFmpeg/FFmpeg#21630 2026-02-02T21:46:09Z 654912: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21630 <p dir="auto">Signed-off-by: Valerii Zapodovnikov <a href="mailto:[email protected]" rel="nofollow">[email protected]</a></p> <p dir="auto">See issue <a href="/FFmpeg/FFmpeg/issues/11551" class="ref-issue" rel="nofollow">#11551</a>.</p> 21630#avcodec/hevc/hevcdec: take into account YUV400 in block length# Valerii Zapodovnikov [email protected] ronag commented on pull request FFmpeg/FFmpeg#21600 2026-02-02T21:31:20Z 654842: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21600#issuecomment-24333 avformat: add shared concurrent block cache protocol <p dir="auto">I think I can run it on a few thousand jobs this week and then we merge. I think you might have a few more adjustments? i.e. remove caching of failures etc?</p> avformat: add shared concurrent block cache protocol <p dir="auto">I think I can run it on a few thousand jobs this week and then we merge. I think you might have a few more adjustments? i.e. remove caching of failures etc?</p> ronag [email protected] Niklas Haas commented on pull request FFmpeg/FFmpeg#21600 2026-02-02T20:59:19Z 654774: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21600#issuecomment-24332 avformat: add shared concurrent block cache protocol <p dir="auto"><a href="/ronag" class="mention" rel="nofollow">@ronag</a> Do you think we should continue testing deployment of this for the rest of the week to catch any unforeseen bugs before merge?</p> avformat: add shared concurrent block cache protocol <p dir="auto"><a href="/ronag" class="mention" rel="nofollow">@ronag</a> Do you think we should continue testing deployment of this for the rest of the week to catch any unforeseen bugs before merge?</p> Niklas Haas [email protected] Niklas Haas commented on pull request FFmpeg/FFmpeg#21600 2026-02-02T20:58:15Z 654706: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21600#issuecomment-24331 avformat: add shared concurrent block cache protocol <p dir="auto">I&#39;ve decided that caching failure is probably a bad idea by default. I&#39;ll guard it behind an option for now.</p> avformat: add shared concurrent block cache protocol <p dir="auto">I&#39;ve decided that caching failure is probably a bad idea by default. I&#39;ll guard it behind an option for now.</p> Niklas Haas [email protected]