Slide 21, part 1: All Vulkan codecs are confirmed and monitored to match the software implementations.
Slide 21, part 2: ProRes implementations are unofficial <apple_ffmpeg.png>. They were reverse engineered. There are no specifications, even if you speak Chinese. Their output is monitored and maintained to match the official implementations.
Slide 21, part 3: I trust them myself, because I wrote them, and because the binary is so thouroughly reverse engineered, there are no secrets.
Slide 21, part 4: (Also, they're literally simpler than JPEG. I can design and write a better codec in 1 hour, entirely in GNU nano, with zero AI.) <- small letters, don't translate

Slide 22, part 1: Obviously, the ProRes situation is quite monopolistic. The IETF agreed. And so did Samsung. And Google. Enter. APV. An IETF standardized mezzanine codec. Like ProRes, but better.
Slide 22, part 2: Real-time sub-frame streaming
Slide 22, part 3: RAW/Bayer support
Slide 23: APV, same prores-style graph, its very similar to prores.
Slide 24: APV benchmarks. 1000fps encode and decode on a 6900XT with the smallest slice size for 1920x1080 422p10.

Slide 25: DPX. An SMTPE-standardized raw container. The archival community called back. Issue: DPX files produced by film scanners are MASSIVE.
Slide 26, part 1: DPX file syntax graph: 2 versions: packed, and unpacked data, 32-bit granularity, padding enabled or disabled.
Slide 26, part 2: DPX file Scanity/other vendor hacks, overlayed on the graph. Vendors themselves don't produce standardized files!

Slide 27, part 1: JPEG2000. What all cinemas worldwide use. SLOWEST ENTROPY DECODER EVER DESIGNED, HOSTILE TO CPUS!
Slide 27, part 2: Conceinved as an internet-first, progressively codec standard. The internet never caught on - worse efficiency than JPEG <Comparison_between_JPEG,_JPEG_2000,_JPEG_XR_and_HEIF.png>.
Slide 28: JPEG2000 graph: precincts, planes, bitplanes, codeblocks, wavelets, etc., etc.
Slide 29: Parallel MQC decoder. The key to fast JPEG2000 decoding. Graph.

Slide 30: The original JPEG. Cameras these days produce 48 megapixel JPEGs, 50Mb each, or more. It would be nice to be able to quickly preview them.
Slide 30, part 2: Hardware JPEG decoders in consumer products are awful. Often 420/422-only, and slow.
Slide 31: At a first glance, JPEG decoding is hopelessly serial <graph>
Slide 31, part 2: But Huffman codes have an interesting property: they resynchronize.
Slide 32: <4-part parallelized JPEG decoding pipeline>

Slide 33: State: FFv1 encoder and decoder merged (find out the dates for each). DPX decoder merged. APV encoder and decoder merged. ProRes encoder and decoder merged. ProRes RAW decoder merged.
Slide 33, part 2: JPEG2000 - seeking funding to merge
Slide 33, part 3: JPEG decoder and encoder - seeking funding to merge
Slide 33, part 4: DNxHD decoder and encoder - seeking funding to finish
Slide 33, part 5: for contact, dev@lynne.ee
Slide 33, part 6: (filmmaking isn't cheap) <- small words

Slide 34: The point of all of this work is to enable everyone to work with high quality video using consumer GPUs, on any platform, freely.
All Vulkan codecs are implemented using the native FFmpeg hardware accelerator framework. All can instantly switch between GPU and CPU decoding. API users only need a single line to enable them.
The mpv player (show mpv logo, its in ~/projects/mpv/ somewhere, and copy it here too) already supports all codecs automatically.
The NLE Shortcut (verify it was the right editor) supports using FFmpeg GPU decoding and encoding.
PR support which adds support for the Vulkan codecs inside Blender.