pandaforce

6 ms·

1.
by pandaforce 3mo ago
Bellard hasn't been involved in FFmpeg for *over 20 years* at this point, and more like 23. His code was not great and reeked of sphagetti due to FFmpeg back then lacking any framework for code sharing between components and codecs. Th
2.
APV video decoder written in Vulkan compute shaders(github.com)
2 points by pandaforce 4mo ago|0 comments
3.
by pandaforce 6mo ago
Yes. I get 300fps decoding 8k ProRes on a 4090 and barely 50fps on a Zen 3 with all 16 cores running. The CPU doesn't touch anything, actually. We map the packet memory and let the GPU read it out directly via DMA. The data may be in a
4.
by pandaforce 6mo ago
Most vision models are trained on images or conventional video codecs. There's a good reason why H200's have 7 JPEG + 7 nvdec ASICS.
5.
by pandaforce 6mo ago
That's basically what VC-2 is, as well as JPEG2000-HT. Wavelets are nice in that they have no need for deblocking since each slice complements one another, and they're simple to calculate. But this localization means they're
6.
by pandaforce 6mo ago
Proxy files have issues when doing coloring, greenscreens, effects shots. The bit depth, chroma resolution, primaries/transfer/colorspace gets changed. Basically only really usable when editing. With this, you don't need prox
7.
by pandaforce 6mo ago
FFv1's range coder has higher complexity than CABAC. The issue is serialization. Mainstream codecs require that the a block depends on previously decoded blocks. Tiles exist, but they're so much larger, and so rarely used, that th
8.
by pandaforce 6mo ago
> A crash mid video write out can corrupt a lengthy render. With image sequences you only lose the current frame. You wouldn't contain FFv1 in MP4, the only format incompetent enough for such corruption. Apple has an interest agains
9.
by pandaforce 6mo ago
6k ProRes streams that consumer cameras record in are still too heavy for modern CPUs to decode in realtime. Not to mention 12k ProRes that professional cameras output.
10.
by pandaforce 6mo ago
The main target for this are NLEs like Blender. Performance is a large part of the issue. Most users still just create TIFF files per frame before importing them into a "real editor" like Resolve. Apple may have ASICs for ProRes d
11.
by pandaforce 6mo ago
Yes, but no. No, in that these days, GPUs are entirely scalar from the point of view of invocations. Using vectors in shaders is pointless - it will be as fast as scalar variables (double instruction dispatch on AMD GPUs is an exception). B
12.
by pandaforce 6mo ago
Yeah, Vulkan is shedding most of the abstractions off. Buffers are no longer needed - just device addresses. Shaders don't need to be baked into a pipeline - you can use shader objects. Even images rarely provide any speedup advantages
13.
by pandaforce 6mo ago
The article explicitly mentions that mainstream codecs like H264 are not the target. This is for very high bitrate high resolution professional codecs.
14.
by pandaforce 6mo ago
These are all gripes you might have with Vulkan Video. Unlike with Vulkan Video, in Compute, bounds checking is the norm. Overreading a regular buffer will not result in a GPU hang or crash. If you use pointers, it will, but if you use poin
15.
by pandaforce 6mo ago
Khronos published a post on the Vulkan compute codecs in FFmpeg: https://www.khronos.org/blog/video-encoding-and-decoding-wit...
16.
Video Encoding and Decoding with Vulkan Compute Shaders in FFmpeg 8.1(khronos.org)
16 points by pandaforce 6mo ago|0 comments
17.
by pandaforce 6mo ago
Cheaters are always 2 steps ahead, all that developers can do is to trim the less willing ones.