On 16/03/2026 14:55, Niklas Haas via ffmpeg-devel wrote:
On Mon, Mar 16, 2026, at 9:26 AM, Lynne via ffmpeg-devel wrote:
---
src/index | 34 ++++++++++++++++++++++++++++++++++
1 file changed, 34 insertions(+)
diff --git a/src/index b/src/index
index 5d5637d..9aa6f35 100644
--- a/src/index
+++ b/src/index
@@ -35,6 +35,40 @@
News
</h1>
+ <h3 id="pr8.1">March 16th, 2026, FFmpeg 8.1 <span title="Sir Charles
Antony Richard Hoare">"Hoare"</span></h3>
+ <p>
+ A new minor release, <a href="download.html#release_8.1">FFmpeg 8.1
<span title="Sir Charles Antony Richard Hoare">"Hoare"</span></a>,
+ is now available for download. Here are some of the highlights:
+ <ul>
+ <li>Decoders: xHE-AAC Mps212 (experimental) MPEG-H decoding via
libmpeghdec</li>
+ <li>EXIF Metadata Parsing</li>
+ <li>LC-EVC: support for parsing and forwarding metadata</li>
+ <li>Vulkan compute-based codecs: ProRes encoding and decoding, DPX
decoding</li>
+ <li>D3D12: D3D12 H.264/AV1 encoding, scale_d3d12, mestimate_d3d12,
deinterlace_d3d12 filters</li>
+ <li>Rockchip H.264/HEVC hardware encoding</li>
+ <li>IAMF: Projection mode Ambisonic Audio Elements muxing and
demuxing</li>
+ <li>Formats: hxvs demuxer</li>
+ <li>Filters: drawvg, vpp_amf</li>
+ </ul>
+ </p>
+
+ <p>
+ This release also features a lot of internal changes. swscale's
rewrite is continuing to progress, thanks to the STF, with numerous
+ optimizations, backend changes, and support for Vulkan scaling. The
Vulkan code is undergoing an initiative to remove the runtime
+ dependency on GLSL compilers, with all the compute-based codecs
already ported to compile-time GLSL, along with several filters.
+ </p>
This section is flat out wrong, since 8.1 doesn't actually add support for Vulkan scaling. I would
collapse this to just "with multiple internal optimizations and bug fixes". I would also
remove "thanks to the STF", because the majority of the STF-funded work is also not
actually included in 8.1.
I'll just remove everything about swscale and replace it with:
>> This release also features a lot of groundwork for the upcoming
>> swscale rewrite.
The section about removing dependence on glslang seems also like a rather
obscure implementation detail that is not of any interest to users, and barely
of significance to packagers. I would consider just omitting this section
altogether. Or should we start listing NEWS entries for every minor internal
refactor?
It's mostly orientated towards packagers, so I think it's important
enough to keep. We do talk about internal refactoring, such as the
threading changes within ffmpeg.c, so I think its fine.
+ <p>
+ A companion post about the Vulkan Compute-based codec
implementations has been published on the
+ <a href="https://www.khronos.org/blog/";>Khronos blog</a>. Written by
Khronos member and maintainer of the
+ FFmpeg Vulkan code, Lynne, it features the innovations made it
possible to widely deploy complete codecs running on GPUs,
+ and future plans for more codec implementations.
+ </p>
This entire paragraph seems a bit niche, partially redundant with the previous section,
and also not of interest to the vast majority of users. I would just omit it entirely, in
favor of just dropping a small link to the article on the "Vulkan-based compute
codecs" entry in the list above.
I'll shorten it to this and keep it as a separate paragraph:
>> A companion post about the Vulkan Compute-based codec
>> implementations has been published on the
>> <a href="https://www.khronos.org/blog/";>Khronos blog</a>, featuring
>> technical details on the implementations and future plans.
_______________________________________________
ffmpeg-devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
