Now that #Dolby has launched a #patent lawsuit over #AV1, unless I'm mistaken we're about to have a repeat of the #Unisys #GIF patent situation where all #browser⁠s must remove support for widely-used image and video formats, namely AV1, #AVIF, #WebP, #WebM, #VP8, and #VP9.

This is really bad. The only other widely supported video codec is #MPEG-4 (which is also patented) and the only other widely supported lossy image format is #JPEG (which is rather inefficient).

What do we do?

🧑‍⚖️ AV1’s open, royalty-free promise in question as Dolby sues Snapchat over codec

「 Dolby asserts that AV1 “reuses” concepts from HEVC, for which implementation is generally understood to come with licensing and royalty fees, and that the codecs “are ‘based on the same hybrid block-based video-coding flow’ and employ nearly the same approach to dividing images into coding units… and blocks,” 」

https://arstechnica.com/gadgets/2026/03/av1s-open-royalty-free-promise-in-question-as-dolby-sues-snapchat-over-codec/

#patents #av1 #codecs

AV1’s open, royalty-free promise in question as Dolby sues Snapchat over codec

Big Tech declaring AV1 royalty-free “doesn't mean that it is."

Ars Technica

#av1 in patent trouble?

https://arstechnica.com/gadgets/2026/03/av1s-open-royalty-free-promise-in-question-as-dolby-sues-snapchat-over-codec/

“Only because Big Tech says a codec should be royalty-free doesn’t mean that it is. … Given that all codecs use somewhat similar techniques, the risk of an infringement of patents belonging to parties who did not offer royalty-free licenses is substantial”

AV1’s open, royalty-free promise in question as Dolby sues Snapchat over codec

Big Tech declaring AV1 royalty-free “doesn't mean that it is."

Ars Technica
AV1’s open, royalty-free promise in question as Dolby sues Snapchat over codec https://arstechni.ca/UknZ #snapchat #lawsuit #Policy #dolby #Tech #av1
AV1’s open, royalty-free promise in question as Dolby sues Snapchat over codec

Big Tech declaring AV1 royalty-free “doesn't mean that it is."

Ars Technica

SVT-AV1 4.1.0 released

https://lemmy.ml/post/44925834

SVT-AV1 4.1.0 released - Lemmy

## [4.1] - 2026-03-23 Encoder - Refactor MD, EncDec, and Entropy Coding kernels (!2604) - Improve Still Image coding efficiency (!2612, !2614) - Change Wiener Filter level for chroma for presets M3 and below (!2620) - Optimize Screen Content coding for Still Image (!2630) Arm - Refactor Subpixel Variance kernels (!2608) - Optimize 16b SAD kernel (!2610) - Fixed Neoverse V2 unit test detection (!2622) - Update Arm build guide (!2625) Bug fixes and documentation - Fixed a hang caused by improper variable looping (#2338, !2600) - Add missing option 2 for --enable-dlf’s help output (!2601) - Depth Refinement algorithmic bug fix (!2602) - Add mutexes to fix hangs when running multiple instances of the encoder in one process (!2603, !2605, !2619) - Fix motion calculation for cyclic QP refresh (!2613) - Fixed a Debug vs Release mismatch (!2618) - Fixed some new warnings with newer GCC versions (!2621, !2636) - Changed Temporal Filtering distortion calculation to not include padding (!2623) - Cleanup some dead unit tests (!2626) - Benchmark framework improvements (!2627) - CI/CD improvements (!2628) - Fixed some niche crashes (!2629) - Readd missing PredStructure enum without SVT_AV1 prefix (!2635) - Rename svt_log to prevent conflict with SVT-JPEG-XS (!2634) - General code and doc cleanup (!2606, !2607, !2609, !2611, !2616, !2617, !2624, !2631, !2633, !2637)

A nice afternoon running some brutal encodes across the homelab. This is initial testing of the 5fist fork of the `svt-av1-psy` encoder with some pretty severe settings. Hoping that the results are worth the wait, but gotta wait until the first few results come out of the workers.

#sisyphus #av1 #svtAv1 #encoding

The madness continues. I'm working on getting Handbrake compiled with support for the SvtAv1 `psyex` fork, and after quite a few attempts and fixing a few patches I have it working. This will end up in the final `sisyphus-client:latest` container assuming the current tests pass. I have something similar I need to do with the `sisyphus-client:latest-essential` container with the `essential` SvtAv1 fork as well, but things are looking good.

#sisyphus #av1 #svtAv1Psyex #svtAv1Essential

Found out today that our national broadcaster #SVT is streaming their linear TV channels in 1080p50 (vs 720p50 on terrestrial and cable networks) and in #AV1!
#Sweden #Sverige #DigitalTV

@niccolove @niccolo_ve

Comment on this video (which us not shown on my Fedi instance, yay federation!)

https://tube.kockatoo.org/w/63cGWTvhzqu2bwMGsh3QcF

I cannot believe that that GPU is not usable for video work. That is what GPUs are made for!

Poorly, there are a few caveats:
- there are always more DEcoders supported than ENcoders. I guess not being able to play a video (it would play but be less efficiently decoded on the CPU) is worse than being bound to #h265 instead of #av1 for recording.
- thus it makes sense that GPUs generally work flawlessly for gaming, as that is just displaying videos (or rendering content, which is kinda different, no idea why video codecs are more difficult than rendering methods)
- for every video format out there exists an encoder. If you use software rendering (on the CPU), you can use ANYTHING. Like encode to modern (and free!) AV1 using #svtav1 on any old CPU.
- if you want to encode videos on a GPU, you need drivers, but also a different encoder. On #NVIDIA you use #NVENC (NVidia ENCoder), for example nvenc_x265 for h265/HEVC videos. On #IntelArc (and afaik AMD GPUs), you use the #QSV (quick sync video) library which builds on top of #VAAPI, which is open source. So you can encode to AV1 using qsv_av1 for example.

What encoders are supported depends on the GPU a lot. Intel Arc seems to have supported the free, efficient and future-proof AV1 codec the earliest, but also the older free codecs VP9 and VP8 (also used in webm), like in a GPU I recently bought used. My older NVIDIA GPU only supports H265, which is proprietary and often less efficient than AV1 (not always, video codecs are black magic).

As OBS can use your GPU for video capture (encoding), the issue is purely in software support.

I only have experience with #ffmpeg for re-encoding videos, but that is also in many video editing tools. Try if you can get them somehow.

For NVIDIA I needed the latest proprietary drivers (#NixOS makes this extremely easy, can recommend) and ffmpeg, nvenc worked out of the box.

For intel Arc I used the regular drivers included in the kernel, but after adding the QSV runtime to my "hardware.graphics.extraPackages" I needed to recompile the entire kernel. Using a #longterm kernel (currently 6.18) makes this more viable... longterm XD.

#MicrosoftSurface #KDENlive #Shotcut #VideoEditing

My Childhood Dream Laptop

PeerTube

@Misofist that is by design!

  • Because the people behind #ValueRemoving & #RentSeeking proprietary tech like #HEVC want to shaft consumers and manufacturers for #licensing money, because that's how their business ROI's itself!

  • I just wished #AV1 would have feature parity in that regard…