Live data from Hacker News

All the giant companies used ffmpeg (2020)

twitter.com

31–40 of 202 posts

Re: All the giant companies used ffmpeg (2020)

#31
post #5

The creator of ffmpeg, Fabrice Bellard, has an impressively long list of projects. Very talented developer! https://bellard.org/

Some speculate that Fabrice Bellard is actually as many as ten different people.

Or that he is a time traveller from an advanced (human or not) species sowing the seeds for humanity’s leap forward into into extra-terrestrial society.

Re: All the giant companies used ffmpeg (2020)

#32

Considering how ubiquitous it is, it's a mystery how and why there's so little documentation about how to use the library versions libavcodec and libavformat.

I think you're supposed to read the header files? I have no idea how people write ffmpeg stuff. The only good tutorial I've seen is: https://github.com/leandromoreira/ffmpeg-libav-tutorial

The headers are actually pretty good.

I learned to use libav by trial and error over years, and now I'm at the point where I can just look at the headers for a refresher whenever I use it.

At a very broad level:

- Encoding and decoding are both pipelines

- Codecs and formats are both part of a pipeline

- An instance of a codec or a format is called a _context_

- The two basic operations for any context are "put data in" and "pull data out"

Putting this all together, a lot of tutorials present this as a case of "Just push the input data in, then pull the output data out!" In my experience this is backwards. This leads to "pipeline buckling" where, e.g., you pull a compressed packet from the demuxer and try to push it into the decoder, and the decoder says "hey, slow down, my buffers are full". You have to just awkwardly stick that packet in your pocket until the decoder's buffers are dry again.

I have always had better luck pulling data. e.g. If you're decoding, first try to pull a decompressed YUV frame from the decoder. If that fails, then try to get a new packet from the demuxer. Only if that fails (and you're not using the default file I/O), then feed the demuxer another buffer. This way it never buckles. It results in a few redundant "Can you give me anything?" checks when warming up the pipeline, but you never have buffers awkwardly outliving a loop iteration. If a buffer enters your control, it's always because you already found an empty spot in the next stage to immediately dump it into.

Re: All the giant companies used ffmpeg (2020)

#33

Earlier quoted context omitted.

One obvious one is the audio quality of Twitter videos, or lack thereof. That one immediately told me they were using ffmpeg's AAC encoder (it's fairly obvious on piano music). Some of ffmpeg's built in codecs are great and some aren't; AAC is in the latter category. I've done some ABX tests with it and some transcoding tests and it's just not great; even at 320kbps two or three transcode cycles result in clearly aud…

> if you're on macOS, use aac_at instead. Those are much better encoders and ffmpeg can use them as external libraries. Hey, do you happen to know if aac_at is encoding at the slowest speed? (Most compression efficiency but longest encoding time). I can't figure out for sure, so I keep bouncing audio through afconvert since it lets me set `-q 127`, and it's a pain, I'd rather do one step.

There are two quality parameters and I'm not sure which one is `-q` in afconvert. One of them is the VBR quality, `kAudioCodecPropertySoundQualityForVBR`.

ffmpeg maps it like this:

q = 127 - q * 9;

So `-q:a 0` should do the same thing as passing 127 to AT.

There is another property though; an actual control of codec effort (`kAudioConverterCodecQuality`). That one should be accessible as `aac_at_quality` and maps 0 to 96, so there's no way to go up to the max of 127... But Apple defines "High" as 96, so I get the feeling there won't be a big difference between that and max, especially for an audio codec.

Re: All the giant companies used ffmpeg (2020)

#34

Earlier quoted context omitted.

I think you're supposed to read the header files? I have no idea how people write ffmpeg stuff. The only good tutorial I've seen is: https://github.com/leandromoreira/ffmpeg-libav-tutorial

The headers are actually pretty good. I learned to use libav by trial and error over years, and now I'm at the point where I can just look at the headers for a refresher whenever I use it. At a very broad level: - Encoding and decoding are both pipelines - Codecs and formats are both part of a pipeline - An instance of a codec or a format is called a _context_ - The two basic operations for any context are "put data…

In my experience, the problem with this is you're still going to run into issues with A/V sync if the input is muxed weird. You can end up having to buffer a ton of A or V before you get the packet for the timestamp in the present. I have an old project using fixed size packet buffers between the demuxer and decoders, and for some inputs it just deadlocks as one side gets full.

My workaround to avoid having to buffer a potentially infinite amount of data was to instantiate the demuxer twice, once for A and once for V. Then they can run out of sync with each other in terms of the muxing, and you can keep them in sync in terms of presentation timestamps.

Re: All the giant companies used ffmpeg (2020)

#35
post #11

Earlier quoted context omitted.

Completely idle curiosity: What kind of artifacts? I don’t spend much time on AV stuff, but I always find the details fascinating.

One obvious one is the audio quality of Twitter videos, or lack thereof. That one immediately told me they were using ffmpeg's AAC encoder (it's fairly obvious on piano music). Some of ffmpeg's built in codecs are great and some aren't; AAC is in the latter category. I've done some ABX tests with it and some transcoding tests and it's just not great; even at 320kbps two or three transcode cycles result in clearly aud…

For a few years, the default aac coder has been fast. But the twoloop coder is better but slower, and was made default in May 2021. Add `-aac_coder twoloop` (in older builds) and recheck.

Re: All the giant companies used ffmpeg (2020)

#36
About 14 years ago, at my first job, I worked with a colleague[1] who introduced me to the wonderful world of open source: the culture, the philosophy, how to submit patches to open source projects, etc. He also introduced me to Debian GNU/Linux which I use actively to this day.

One day, he began working on certain audio/video encoding problems that needed to be solved for our project. He chose FFmpeg as the primary tool around which he began building his solution. After having spent several days with FFmpeg, figuring out and documenting various ways of using FFmpeg to solve all our audio/video encoding problems, one day, when we went out for lunch, he declared to the team,

"FFmpeg is awesome! If you give me a shoe, I will turn it into a video file!"

[1] https://news.ycombinator.com/user?id=topa

Re: All the giant companies used ffmpeg (2020)

#37
post #14

Earlier quoted context omitted.

>FLOSS made the internet possible. FTFA! In all seriousness though; there isn't an aspect of computing that hasn't been improved by F(L)OSS. (What's the L stand for?)

Libre. Usually used to denote that we mean freedom not zero-cost when saying “free”

I use Libre to indicate “freedom” based software, while FOSS for “free” software.

I rarely use FLOSS as, floss is a known word for flossing teeth and for the dance move. Libre just sounds cool compared to floss.

Re: All the giant companies used ffmpeg (2020)

#38
post #5

The creator of ffmpeg, Fabrice Bellard, has an impressively long list of projects. Very talented developer! https://bellard.org/

Some speculate that Fabrice Bellard is actually as many as ten different people.

This comment brings me a lot of sadness and pain.

I know and respect Fabrice from in person interactions. He is exactly who he claims to be. Maybe an interesting question, instead of this current line of discussion, is to find out what led to his successes?

Could it be replicated?

Post reply on HN