Dav1d: performance and completion of the first release (opens in new tab)

Hi! You have 2 options: 1) write pthread emulation for your target system. We wrote one for windows native threads, but others should be straightforward. 2) if you want thread-less, that's possible (single-threaded performance shows 1080p is easy, and on high-end systems even 4K single-threaded might be doable), which basically just involves putting the two functions in thread_task.c under #if HAVE_THREADS, along with any coded calling pthread_() functions or using pthread_ types from <pthreads.h>, and then enforcing that Dav1dSettings.n_{tile,frame}_threads is always 1 (that means it won't ever enter these codepaths). Then, you always get single-threaded and (p)thread-less decoding.

Feel free to come on IRC, happy to help you dive into this, it's not very difficult.

Right now, 10-bit decoding is horribly slow because the assembly optimizations only cover 8-bit, so it's probably 10-20x slower. We'll work on 10-bit next, and in the end, I'd expect it to be 30-50% slower than 8-bit.

You'll want to check out rav1e ( https://github.com/xiph/rav1e)

Here's a comment that gives a clue - https://news.ycombinator.com/item?id=17539791

dav1d is a decoder, not an encoder.

> Numbers for Ryzen 2400G would be nice. That's my main computer and they make a great HTPC.

No access to those machines, so I cannot guess...

Yes, it supports Windows natively. The tests were run on Windows.

Being a decoder, they probably place a high priority on having the widest possible platform support. C is still top dog in that respect.

It has to be C because so many embedded-system vendors are pathologically hostile to anything else. Most tolerate C only to try to win ports from other, typically end-of-lifed, targets, and resent it.

A few have begun to embrace LLVM, and so don't care about the front-end language -- they still only say they support C, but turn out to not notice if you feed in IR from something else. Then it becomes a question of how badly your code needs the language runtime support code, or how good you are at porting it, because they will not pick up maintaining any of that under any circumstance. GC? Ha.

Thanks, seemed like something like this might be the case, but good to hear it confirmed and the details. And thanks again for the work on dav1d!

The motivating observation here is that I know of a few GPU vendors offering hybrid decoding for HEVC and VP9, but no hybrid decoders put together by the open-source community. (Counterexamples are interesting!)

Reasons a GPU vendor might be better able to do this sort of thing than an outsider who can sling OpenGL include: 1) some hybrid decoders are described as leaning partly on special-purpose video decoding hardware, which tends to be a black box to us, and 2) more-detailed understanding of and access to the details of the hardware might let you efficiently express something that's inefficient or awkward in just GLSL--in other words, same kind of reason people care about Metal/Vulkan vs. OpenGL or asm vs. C.

(The further down in the weeds I get the less sure I am of precise technical correctness, but a couple concrete things that seem to make shaderizing decoding tricky are: 1) AV1 has a ton of control-flow-y elements--blocks can be split many different ways and be different sizes, and there are lots of prediction modes--and branchy code can be bad for shader efficiency, and 2) some things seem to block parallelism, e.g. for intra prediction you need the blocks you're predicting from before you can do predictions for the next block. And given the CPU-GPU transfer latency you can't ping-pong back and forth at will; you need large chunks that run well strictly on the GPU. Could be that pieces like the transforms and post-filtering that can be cleanly separated into GPU steps, though.)

An efficient open-source AV1 decoder based just on OpenGL/GLSL would be great! But since it wasn't mentioned as an ambition in the post, community-written hybrid decoders seem rare, and we had an expert about AV1 decoders in the thread, it did not seem unreasonable to me to ask how realistic it was.

Though if you manage to write an open-source OpenGL-accelerated AV1 decoder, that would definitely answer my question and leave everyone happy. :)

(jbk's recent reply answers this better than I could.)

> VideoLAN has numerous people not working on VLC.

Whoa, what? What else is going on? Oh, x264 & x265, I bet.