5 ms·

Win32 definitely has some stinkers. But, video encoding APIs definitely take the cake for me. I've only tried a couple of FFmpeg's APIs and AV1's API, but my Go

by _gabe_ 3y ago

Win32 definitely has some stinkers. But, video encoding APIs definitely take the cake for me. I've only tried a couple of FFmpeg's APIs and AV1's API, but my God, these are the worst API's I've ever had to deal with. Just as an example, all I wanted was an API like this[0] for FFmpeg. In order to implement that API (which in my opinion is reasonable), I had to write this monstrosity[1]. It took me a solid week to find an example of how to do this, then another few days of fiddling until I finally just barely got something working. Then I threw in the towel even though the performance was horrible. I tried again a year later and spent another month wrestling with AV1 :/ The amount of leakage going on in these APIs is absolutely insane. I shouldn't have to know the intimate details of how video encoding works to use your library. If I do, then I may as well write my own encoder at that point. [0]: https://github.com/ambrosiogabe/MathAnimation/blob/18c004bca0167dd18c027139897635de0030be7f/Animations/include/renderer/VideoWriter.h#L5 https://github.com/ambrosiogabe/MathAnimation/blob/18c004bca... [1]: https://github.com/ambrosiogabe/MathAnimation/blob/18c004bca0167dd18c027139897635de0030be7f/Animations/src/renderer/VideoWriter.cpp https://github.com/ambrosiogabe/MathAnimation/blob/18c004bca...

bob1029 3y ago
> If I do, then I may as well write my own encoder at that point. I've actually done this with jpeg & mpeg1. I spent maybe a hundred hours trying to get existing libraries to play by my rules. When you completely own the implementation everything gets out of the way. I don't like that I had to do this, but it was the only way to wrap my head around the problem and bend it to my will.
coldpie 3y ago
Haha, yeah. In ffmpeg's sort-of defense, the libav* APIs are supposed to be semi-private, which is how they try to get away with them being terrible & unstable. But in practice they're public, and everyone uses them, because the only alternative is gstreamer and oh boy do you ever not want to dive into that mess. FWIW if you just want to en/decode AV1 and don't care about anything else like container formats, you can just use the codec directly. Dav1d is the current gold standard, I believe. Even some container APIs aren't too hard to deal with, if you do need that.
jcalabro 3y ago
Completely agreed, and the version changes between v5 and previous versions are severe, and poorly documented. Extremely frustrating to work with!

by _gabe_ 3y ago

bob1029 3y ago

> If I do, then I may as well write my own encoder at that point. I've actually done this with jpeg & mpeg1. I spent maybe a hundred hours trying to get existing libraries to play by my rules. When you completely own the implementation everything gets out of the way. I don't like that I had to do this, but it was the only way to wrap my head around the problem and bend it to my will.

coldpie 3y ago

Haha, yeah. In ffmpeg's sort-of defense, the libav* APIs are supposed to be semi-private, which is how they try to get away with them being terrible & unstable. But in practice they're public, and everyone uses them, because the only alternative is gstreamer and oh boy do you ever not want to dive into that mess. FWIW if you just want to en/decode AV1 and don't care about anything else like container formats, you can just use the codec directly. Dav1d is the current gold standard, I believe. Even some container APIs aren't too hard to deal with, if you do need that.

jcalabro 3y ago

Completely agreed, and the version changes between v5 and previous versions are severe, and poorly documented. Extremely frustrating to work with!