FFmpeg: The Incredible Technology Behind Video on the Internet | Lex Fridman Podcast #496
Watch on YouTubeVideo summary
FFmpeg and VLC stand as pillars of modern internet infrastructure, serving as the essential backbone for major platforms like YouTube, Netflix, Chrome, and Discord while prioritizing code quality over corporate profit motives. Developed by a global community of volunteers rather than large corporations, these projects manage an immense amount of low-level software craftsmanship, with FFmpeg alone handling approximately 100,000 lines of assembly specifically for codecs to support billions of devices worldwide. The technical process they enable is incredibly complex, involving the retrieval of data streams via protocols like HTTP or DVD, demultiplexing various tracks from containers such as MP4 and MKV, and decoding video using sophisticated algorithms that reverse entropy coding and optimize human perception by converting colors efficiently. This robust architecture allows for error resilience against broken files and unreliable network conditions, ensuring high-quality multimedia consumption across diverse hardware without the need for expensive proprietary equipment.
The evolution of these projects is deeply rooted in a volunteer-driven culture where contributors are motivated by a passion for technology rather than financial gain, creating an environment that functions like an exceptional school for programming. This community operates under open-source licenses primarily GPL or LGPL, which act as social contracts to democratize complex multimedia tools and ensure they remain accessible globally; however, transitioning between these licenses requires the difficult consensus of thousands of contributors who view current terms as part of their agreement with past and future developers. The relationship between FFmpeg and VLC is described not as competitive but as a binary star system where each supports the other's growth, relying on rigorous testing environments that validate functionality across countless combinations of operating systems, compilers, and legacy architectures to prevent users from needing constant hardware upgrades.
To meet the increasing demands of video processing, developers have resorted to extreme optimization strategies that often involve abandoning standard conventions in favor of handwritten assembly code tailored for specific CPU instructions like AVX-512 or SVE. This approach is necessary because hardware constraints are becoming primary bottlenecks compared to software limitations alone, and while high-level languages offer safety, they cannot match the raw speed required for mission-critical tasks on billions of devices without sacrificing performance or compatibility. The community continues to innovate with new codecs like AV1 and its successor AV2, which aim to reduce bandwidth usage significantly while navigating royalty issues associated with older standards, all while expanding into emerging fields such as haptics, volumetric 3D data, and eventually brain-computer interface streams driven by a philosophy that tools must remain open and free from proprietary restrictions.
Despite facing challenges like aggressive security reporting practices that prioritize hype over utility or conflicts between corporate expectations for immediate support and the realities of volunteer maintenance, these projects have successfully maintained their core mission through rigorous standards and community resilience. The history includes significant moments such as resolving governance issues after forks merged back together and developing lossless formats to preserve multimedia heritage for centuries against data degradation. Ultimately, FFmpeg and VLC exemplify how a decentralized network of engineers can democratize technology, enabling the YouTube revolution and giving voice to individuals across borders while ensuring that critical infrastructure remains secure from government surveillance and accessible to everyone regardless of their background or age.
Read the full video transcript
The important is is your code good? We
care about excellent code. We don't care
who you are. Like maybe you're a dog. I
don't care, right? I don't care where
you come from. I need to look at your
code. Oh yeah, but I'm engineer at this
very large company in in in Italy, in
Germany, in the US. We don't care. We
care about the quality of your code
because this is what defines our
community. And which means that we have
a lot of people who contribute who are
some very different backgrounds and and
and very introverts. Sure, but that's
okay, right? FFmpeg is probably one of
the biggest CPU users in the world.
Everything we've just said in the past
couple of minutes,
every sentence is someone's lifetime's
work. There are books about every
sentence. So the level of complexity
in many cases is inordinate. FFmpeg has
100,000 lines of assembly for all the
codecs.
>> All codecs. And just this one has
240,000.
Every cycle matters. We are talking
about probably 3 billion devices which
are going to decode video nonstop
because for example, 30% of the video
from Netflix are now in AV1, 50% of
YouTube. This is what peak video codec
should look like.
79.9% assembly, 90.6% C, and uh 0.5%
other. And what's incredible is with
those tweets, which is factual, people
get
crazy. For the last 2 years they go
crazy. No, intrinsics is fine. The
compiler
>> You can optimize your compiler auto
vectorization. It's your fault. You
don't understand. And we've tried that
forever, right?
>> For 2 years and 2 years later showing
hundreds of examples of of handwritten
assembly. No, no, no, you're doing it
wrong. The compiler can do this. The
intelligence agencies tried to like say,
"Can you put a backdoor in VLC?"
>> Yes, two of them.
What what do you say?
No. No. I [laughter] was a lot less
polite. Basically saying hell no. Like
if we had to compromise our software, we
would shut it down. This is clear. Any
tweets
uh carrying your regret?
No tweets regret.
Or is it like that Well, how's the
French song go? Regret nothing. Don't
regret anything. No, it's because
regrets are attacked on your mind.
The following is a conversation all
about FFmpeg and VLC with Jean-Baptiste
Kempf and Kieran Kunhya.
FFmpeg is an open-source software system
that is the invisible backbone behind
YouTube, Netflix, Chrome, VLC, Discord,
and basically every platform that
touches video or audio on the internet.
It can decode, encode, transcode,
stream, and play almost any video or
audio format ever created. To me, it is
one of the most incredible software
systems ever developed. And it's all
done by volunteers.
VLC is also a legendary piece of
software. It is an open-source media
player that plays basically anything you
throw at it, any format, any platform,
no ads, no tracking. It has been
downloaded over 6 billion times. And
again, for me, it has been one of my
favorite pieces of software ever with
the most legendary logo, which I, of
course, had to honor in this
conversation by wearing the
VLC traffic cone hat the whole time.
So again, above all else, thank you to
the incredible volunteer engineers who
put their heart and soul into this code
that has been used and loved by billions
of people.
Thank you.
And about the two great engineers and
human beings I'm talking to in this
episode,
Jean-Baptiste is the president of
VideoLAN and is a key figure behind VLC
and FFmpeg. Kieran is a long-time codec
engineer, FFmpeg contributor, and the
man behind the now infamous FFmpeg
account on Twitter X
that I recommend everybody follow for
the memes and for the unapologetic
celebration of open source and great
low-level software engineering.
Let me also say that it's inspiring and
humbling that so much of modern
civilization rests on software built by
people who are not chasing fame or
money, but are obsessed with the craft
of engineering.
We live in a world where billions of
people consume video every day without
ever thinking about the invisible
machinery underneath it.
But that machinery matters.
Open-source infrastructure matters.
It is one of the great examples of human
beings quietly collaborating
cross-borders to build something useful,
durable, and elegant for the rest of us.
And so, this conversation is not just
about codecs and media pipelines. It is
also about the deeper spirit of
engineering and generosity that makes
projects like FFmpeg possible.
Again, I can never say it enough.
Thank you.
This is the Lex Fridman podcast. To
support it, please check out our
sponsors in the description, where you
can also find links to contact me, ask
questions, give feedback, and so on.
And now, dear friends,
here's Jean-Baptiste Kempf
and Kieran Kunya.
So, the legend goes VLC can open
everything. What's the weirdest thing
that you know that it can open? You know
that there is a ton of people who are
using VLC to record VHS videos, right?
Like, it's like you plug it with a
capture card and you can basically
record VHS video.
>> Well, how does that work? Basically,
it's you know those type of capture card
where you can put a peritel in
or VGA and you put that and actually VLC
can play those type of cards and there
is a module which allows to control
directly some those VCR camcorders.
We support DVD audios lately, right? We
spent the the summer working on DVD
audio support. And like there is no one
who's making any DVD audio support.
There is a custom encryption schemes.
What about Lucas film?
>> Oh, yeah. And there is of course all the
weird codecs support game codec
supported by by FFmpeg. The one Star
Wars video game, the first 10-second
opening sequence, someone has gone and
implemented that and make sure that's
bit exact on one disc that existed at
one time of one little sequence in the
game. And then funnily, there was a at
one VideoLAN conference, we made a
competition to make make the weirdest
and most horrible file ever and see if
VLC could play it.
What did it end up being? What was the
file? It was an MKV file made by Derek
which each of the frame was changing
resolution, aspect ratio, rotation and
then and it was like Did it work? Yes.
And there was another one where
the whole video was actually animated
subtitles, right? SSA, right? So Yeah, I
remember that.
>> [laughter]
>> So each each frame was a black frame,
but on top of that there was a a
subtitle So that was animated for each
frame. There was a file that's a valid
zip and a valid MP3 at the same time or
something like that, so So yeah, we had
made a competition of stupid files.
And it worked. It opened all of the
stupid files. Yes.
>> By the way,
uh for people who are not familiar, I am
wearing a hat. Would it be fair to say
this is the best worst logo of all time,
the cone?
Yeah, by far, right? The logo of VLC is
so iconic, right? Like we are a team
with a small of people and and the icon
is known everywhere. I go to middle of
nowhere in India or in China, people
know the cone, right? And and 25% of the
website traffic that comes to our main
website is cone player, right? So, so
many people don't know VLC, right? They
know the cone player. That's the thing
they Google for is cone player. Yeah, if
they go on Google and they put cone
player and they download VLC, right? So,
that's iconic. And once we tried to
change it as a joke, right? We said it
was going to be a a type of
caterpillar
construction and we said that during
April 1st
we had around 10,000 emails saying, "No,
don't change the logo." and so on,
right? So,
it's so iconic, right? It's so
distinctive, right? If you want to do a
video player, you're going to put a play
button on a TV, right? And that's a
YouTube YouTube logo, right? It's
unoriginal. This one is orange, right?
Very bright and and it's weird and
ridiculous and it's absurd and it's
hilarious. It becomes a meme and meme
becomes culture. And you keep it and you
know about it and you know that in 20
years like you still have going to have
the cones and remember, "Oh yeah, that
was a video player." Yeah, and we'll
talk about, you know, the the mission of
of FFmpeg being a kind of the archival
aspect of it. So, you could think about
1,000 years from now we'll have all
these videos that only VLC can open.
Humans human civilization has already
destroyed itself multiple times and the
only thing that will remain is this
like, you know, the the cockroaches be
crawling around and it'll be the VLC
logo with our some of the archival
footage that VLC can open. And the
aliens will show up and they'll press
play and they'll get to see We really
hope so, right? But there is also so
many memes where people say, "Well, I'm
sure I can put a pancake inside my DVD
drive and VLC will play it."
>> Can they? No, we tried it doesn't.
But we actually have a video of us
trying that. Didn't work. A core act for
physical reality. I don't know what that
would even look like.
>> There was a guy who did that, right? He
He He He printed a small cone, right?
Like the the ones we we distribute as
goodies, and inside he put an RFID chip,
um which was his way of playing a movie,
right? And so he put this on RFID
player, and when he put that, it was
playing like the last Star Wars and so
on. So instead of having like DVD boxes,
he had like VLC cones all around, and he
plugged that and there was like physical
objects.
So, the thing that we're talking about
is everything around video codecs, video
encoding, video decoding, video
streaming, video player client that
[clears throat] I'm wearing on my head.
The entire ecosystem enabling free
media.
We'll talk about FFmpeg, we'll talk
about VideoLAN, VLC, and all the other
incredible video technology
that is used probably by billions of
people. So, JB,
you're the lead developer behind the
legendary VLC player. Kieran, amongst
many other things, you're lead developer
behind the legendary FFmpeg handle on
Twitter.
And both of you have spicy opinions, I
would say.
So today we want to talk about FFmpeg
and VLC.
Uh
for context for people who are not
aware, and I'm sure
basically everybody listening to this
have used these two
technologies, probably regularly without
knowing it. So FFmpeg underlies
basically most video on the internet,
including YouTube, Netflix, Chrome,
Firefox, of course VLC, and countless
other video platforms. It is estimated
that over 90% of video processing
workflows online and offline involve
FFmpeg.
VLC has been downloaded at least 6.5
billion times.
But likely that number, cuz it's
impossible to really count the number,
uh is much higher than that. Virtually
any operating system supports virtually
any media format.
The limitation being it can't open
pancakes. So,
uh can we just lay out some of the
basics so to help people understand
what's involved in all of this? So, when
we press play
on a video player like VLC, what
happens? What How does it go from the
the file or the stream to the pixels on
the screen and the sound on the speaker?
What are the big stages to be aware of?
So, there are several stages, right? The
first stage is to get from an address,
right? Which is the type of URL to give
you a bite of streams, right? So, this
would be, for example, HTTP, file, DVD,
right? You give the path to the media
and give you a stream of data. The
stream needs to be cut up by what's
known as the container, the
demultiplexer or demux. Um we'll try and
keep the jargon light throughout this,
but um it needs to go and start
demarcating video and audio frames. So,
it just gets data from the operating
system blocks at a time and needs to
start cutting these frames up into
compressed data.
It then needs to start doing simple
parsing of the video frames, mainly to
figure out whether that codec is GPU
decodable or needs to fall back to
software.
We're very sort of used to assuming the
GPU will play all of these things,
there'll be hardware acceleration. I
think it's up to 45% of files are not
GPU decodable. So, these need to be
probed, they need to be detected. There
can be variants of a given codec, some
of which are decodable on the GPU.
Different vendors of GPU might have
different capabilities. So, those need
to be detected. So, if if it's
GPU-capable, you pass it through to the
GPU black box.
So, now if there's a software fallback,
that means in the beginning is is the
first do de-entropy coding, so removing
the mathematical coding of the
bitstream. So, this uses
capabilities such as Huffman coding or
arithmetic coding to actually decompress
the mathematical layer of the bitstream.
We then need to start reading the syntax
elements for intra prediction. So, intra
prediction are like still images of the
video, so your I-frames.
So, this works and operates in the
spatial domain. So, you do your intra
prediction spatial domain. You You have
a residual because your prediction isn't
quite matching that of reality. So,
you've made a prediction,
but then there's a little bit left and
that's what's known as the residual.
This is stored in the frequency domain
and these are quantized to decompand
their space.
We then need to do the inverse transform
to bring them back to the spatial domain
and apply these residuals. So, a lot of
the process of the decoding
is this thing is compressed. Yes.
>> Yes. And you have to predict the highest
quality thing that's supposed to go
there. I-frame is the best
representation you have spatially. Yes.
And then you
And then there's a lot of temporal
compression that can happen depending on
the codec. And then you're predicting.
You're predicting what the reality that
was captured in this rawest form. Yeah,
because what people don't realize is
that the compression on video and audio
is
one in the times, right? Like people
don't realize how compressed we we do,
right? For audio, you move you compress
by when you go from normal audio to MP3,
you compress by 10 times, right? When
you move to video, you need one in the
time, 200 times, right? So, you need to
remove all the details but that you
don't care about because all the
compressions that we do and that's very
important, people forget about that, is
to be viewed by humans, right? So,
all the codecs, either for audio, mimic
basically how your ear works, right? And
and a lot of things about like the the
the response on the ear and same for for
your eyes, right? And and so, for
example, on video, we don't work on RGB,
right? Everyone expects to work in RGB.
We don't, right? We we to YUV, which is
basically one is luminance, brightness,
and the other are colors. And this
matches your eyes, where inside your
eyes you have the cones and the buttons,
right? Where some of them look on
brightness and more on on the other on
colors, right? So,
we need to compress a lot, and so we
need to degrade. But in order to
degrade, we need to match the human
perception. And this is why it's so
difficult. And then we need to use the
maximum power, mathematical power, very
complex technologies. We move to the
frequency domain, as Ken said. We do a
ton of dequantizing and in order to get
the best compression, but it still looks
good. You're trying to compress in order
to maximize the highest quality thing
for human perception. That is correct.
That is correct. And this is very
important, right? Compression is not
like a zip, right? A zip you have data
in, you get data out, right? And you try
with all the the zip compression to
arrive with
the limit. Here, we are degrading the
signal, right? And so we need to degrade
both the audio and the video signal in
the best way possible. And we can do
that, but it involves first a lot of
theoretical knowledge about how it
works, how the eye works, but a lot of
mathematical change, a lot of
mathematical tricks, right? For example,
when you move to RGB and you you go to
YUV, for example, what we do very often
is that
we scale down the resolution of the
color compared to the brightness. And
most of the time and just this without
compression, it divides the size by two.
But
most people don't see it, right? Um
and so on and so on, right? And then you
go to very complex mathematical change,
so of course
Fourier transform, which de facto are
not Fourier transform, they are like
discrete cosine transform, but that's
the same idea, so frequency domain.
We split the video by blocks, right? So,
that's why when it's wrongly decoded,
you see those blocks and badly encoded,
you see those blocks
and so on to arrive to compression
states that are
insanely high, right? And each
generation of the codec is like 30%
less. Mhm. For the same quality, right?
And this requires amount of power
of computational power that are huge.
No, that be you should you should
elaborate. It's 30% better, but an order
of magnitude perhaps perhaps even two
orders of magnitude more compression
power. That that's the big difference.
>> What do you mean by compression power?
Sorry, CPU power to achieve that level
of compression. Oh, yeah. So, and you
have to be able to leverage the CPU and
sometimes GPU like you mentioned.
And then we should mention that a lot of
this programming
uh is done at the lowest possible stack.
Whether it's C and of course as as the
legendary Twitter handle
um re-emphasizes over and over a lot of
assembly. So, what happens is globally
is that you have an address, right?
Which gives you uh with the operating
system a stream of bytes, a stream of
data, right? And this is the first step.
And the second step arise with de-maxing
where you're going to separate audio,
video, subtitle in type of different
tracks. And then on each of those
tracks, you're going to decompress and
decode them either audio with an audio
codec, video to video codec, and
subtitle to subtitle codec. Um and once
you've decompress those type of things,
you have raw images, raw and then you're
going to talk to your graphic card in
your screen and display that. And same
for the audio, you're going to talk to
your audio card, which then is going to
go
um in analog to to your audio speakers.
And everything we've just said in the
past couple of minutes,
every sentence is someone's lifetime's
work. There are books about every
sentence. So, the level of complexity
in many cases is inordinate. You know,
it's it's it's Every sentence has
thousands of people working on this in
in industry as a whole.
Books written about it. So, there's a
lot of detail. there's a lot of
subtleties, there's a lot of both
academic and practical realities, and
both of which matter.
Uh we're mentioning codex, but I don't
think you mentioned uh containers. So,
what what's the actual containers
for some of the stuff we're talking
about? So, people are familiar with
MP4,
uh MOV, MKV. So, anyway, what what are
containers versus uh
the thing that goes inside? So, the
container is what we call also the
muxer, right? When I say demuxing, it
means decontainerizing, right? So,
actually, if you look
mux mean multiplexer and demultiplexer,
right? Mux and demux are those. And then
a codec is actually coder-decoder,
right? Um and um so, containers are
these collection of multiple tracks,
right? So, it's a what normal people
call the file format, but it's a bit
more um
subtle than that. But, the most known
one, of course, is MP4, but uh when I
started, it was AVI, right? AVI was the
the video format from from uh Microsoft.
And um move, MOV, which became MP4, was
a format from Apple. Um in the
open-source community, uh one of the
person that is still active on VideoLAN
is called uh Steve Law, and he s-
started uh this Matroska format, which
is like a bit more complex and and and
more feature uh proof. Um and um there
are so many others. So, I mean, there's
a it's a pretty common thing, and maybe
it'll even happen in this conversation
that people confuse container
and the codec, right? So, they confuse
MP4 and H.264, for example. Is that a
horrible violation?
>> No, it's not, because technically, the
name of H.264 is MPEG-4 part 10, because
MPEG-4 is actually a meta specification,
which has several things in it, right?
There is the part two. Uh so, there is
like audio codecs, right? AAC is the
factor with MP4 audio something. There
is actually several video codecs, right?
Inside the MP4 specification. One of
them is MP4 part 10 called also AVC
called also H.264, right? So,
it's completely the fault of the
industry to to to to make things
difficult to understand. So, that's very
difficult so that people
then don't understand why sometimes you
talk about MP4 part 10 where you mean
H.264 and why it's not MP4. So, you can
technically shove in all kinds of
different codecs inside containers and
horribly so. But broadly speaking
though, MP4 is understood to generally
be
H.264 plus AAC audio. 99% of the time
that's that and that.
The the rest are de minimis, the small
effects, you know, edge effects really
compared to that. So, it's not the end
of the world that there are people
who do get annoyed by that. But also in
reality, something like VLC, just to
point out,
the file may say .mp4, but it may be
something completely different. And
that's one of the challenges both FFmpeg
and VLC have is
the real world is a completely different
place to a three-letter file format. And
this is very important to say, right?
Like, for example, in VLC and FFmpeg, we
discard the file format, right? We we
look into the file to understand what's
in it because so many people, like, they
say, "Oh, it's a video, it must be MP4."
But technically, it's an MOV or maybe
it's a MKV, right? So, we analyze in
real time everything that we have and we
don't trust
the the the format. So, what information
does the fact that it's .mp4 give you?
It helps, right? It gives you a hint,
right? Just like, "Oh, it it's finished
by .mp4. I will start first by opening
probing it with the MP4 container
demuxer to see, well, it should be that.
But I don't trust it and if I'm lost, I
say, "Okay, maybe I'm going to try it.
So, it bumps the priority of the module.
So, how do you get to just to take a bit
of a tangent there?
You know, the dumb thing is if you try
it and before it then it turns out to a
different codec than you would have
expected,
uh most players just break there. Yes.
Yes. So, how do you not break? There's
just a philosophically, I'm sure there's
a bunch of stumbling blocks along the
way where you you it's easy to just
break and stop, freak out, that's it.
How does VLC not? This is why VLC is
popular. Um but the reason is because
actually VLC was
is just a client of a streaming solution
called VideoLAN from from from very long
time ago, from the late '90s. And when
you playing video which are on UDP,
right, in network, they might be
damaged, right? So, you don't trust your
inputs. And this is very important in
today's security is that you don't trust
your inputs. So,
everything in VLC is prepared to um
work with broken files. Mhm.
>> [clears throat]
>> And it's a philosophical idea from the
beginning and everything is engineered
into that. And it's a culture, right?
And so,
for example, and VLC became very popular
on that because a long time ago when
people were pirating content, um which
they do a lot less today. Um and none of
us ever have No, of course not. Um
the metadata to play some files like AVI
is at at the end of the file, right? And
when you're downloading, you don't have
that, right? So, VLC was just like,
"Hey, this file is broken, but I'm still
going to try to interpret it." And this
was very useful.
We hinted at the awesomeness of the
various different stages.
We hinted at the awesomeness of codecs,
the depth and the richness and the
complexity of everything involved there.
What Let's just try to define what is a
video codec. What What's involved there?
What What does it mean to compress
something? You already started to hint
at it, but can we elaborate a little bit
more? So, there's a huge amount of
redundancy in any video, uh both spatial
and temporal. And the point of any video
codec is to remove this redundant data,
use mathematical properties as part of
this reduction process.
So, more often than not using several
orders of magnitude more compute to
compress, because that's more costly
versus both costly both financially and
in CPU resources.
Versus the decompression. So, it it's
asymmetric in that respect. Often the
case because compression is done once,
but there could be lots of viewers of
another file.
So, to take that information and
compress it by
100x, 200x, removing redundant
information,
and using mathematical properties to
make that small, but also have
properties such as error resilience. So,
as as JB suggested,
VLC in the beginning was was used to
play UDP network feeds. And UDP network
feeds lose packets. And so, some of the
design goals of a codec is also to be
recoverable. You You need to actually be
able to join the stream. It's not
necessarily a file. You need to join,
get on the decoding process, and start
decoding. And and to give a more
image to to to to people who are not
familiar, right? Like, when you're going
to see any type of movie, right? You're
going to see the camera is going to pan,
right? And and and travel. And you
realize that, for example, all the
background is the same from for like a
minute, right? Or 30 seconds, right? So,
you can use the cloud that you see uh
on the background, you can reuse that
from a frame to another, right? And so,
it's gets
the more the more memory you have, the
more power, the more comparisons you can
make, right? And so, the more compressed
you can be. And most of the modern
codecs are basically doing that. So,
just to make it even more explicit. So,
what is video? Video is a
bunch of pixels
of an RGB
three values
and you have a grid of pixels and you
have let's say 24 or 30 or 60
of frames a second
and you just have all these pixels
repeating and showing different stuff 30
times a second.
And so the question, the philosophical,
the technical question is how can I
compress all of that?
Store all of that at 100x 1,000x, right?
1,000x
>> The target is 1,000x, right? And the
goal is when you say redundancy
what is redundant meaning stuff at best
that humans wouldn't notice if it was
missing. So, for example, you have a
picture of a cloud, right? And from the
next frame there are still going to be
the same cloud, so it's redundant. You
could just put it once and not do it,
right? Or you have a a black background
behind me, for example, the black is the
same on the whole picture, right? So,
you can say, "Well, you know, in this
picture take the pixels that you have on
the top left and the one on the top
right I'm not going to give the value.
I'm just going to tell you it's the same
at the top left." And then you can say
for frame one,
"Reuse something from the previous frame
or the previous previous frame and so on
and so on, right? So,
you could basically it's unlimited, but
then it's limited in terms of memory or
in terms of compute power because, for
example, if you need to compare pixels
on 200 frames in the past on
4K
resolutions, it's a huge amount of
compute.
And then when you're showing it, you
have to do the decompress of all of
that. So, you is it the codec that has
the encoding and the decoding is a is a
coupled process that you're developing.
>> Exactly, right? And those are two
different
trade-offs, right? Are you going to
compress more,
but then it might be more difficult to
to to decode. Um are you going to comp
to make it a codec that is more complex
to encode and easier to decode? Are you
going to make a codec that is easier to
encode because you need to be fast, but
then the the client side, the player is
going to spend more time. That's why you
have so many different type of codecs is
that it's not always easy.
And to make it even more complex, modern
codecs like AV1, AV2, or VVC are
actually not codecs. They're a
collection of tools, right? They are
multiple tools, multiple codecs in the
same codec to depending on the image get
the more compression. So, just to
elaborate,
codecs like AV1, VVC
have a much wide have a wide audience.
It could be
a screen share content, it could be
video, it could be animation. All of
these require different coding tools.
So, what happens these days is a
collection of tools are put in and
called AV1, called AV2, called VVC to
allow for different use cases. So, you
may be on Zoom and sharing your
PowerPoint and then you need to show the
audience a video. That codec needs to
start changing its tool set depending on
the content to compress in a different
way. And like you said, there's a a
bunch of incredible engineers behind
each part of that, each part of the
tools that make up AV1 for example.
Sure. Uh so, we've uh kind of danced
around it. We've talked about VLC, the
logo, the hat.
Uh let's talk about FFmpeg. What What is
FFmpeg exactly? FFmpeg is basically the
low-level
libraries for codec
to compressions and decompressions,
muxers and demuxers, and filters. It's
The core is this, and then you have a
several tool which allow you to create a
type of pipeline to process any type of
video files.
Uh and it's used as a library absolutely
inside everything from VLC to Chrome to
your smart TVs to basically any video
you see online,
um you usually use FFmpeg. And FFmpeg in
it has all those type of tools and
sometimes depend on other libraries like
x264,
uh libvpx and others, right? So, so it's
really now the de facto um
tool to process images. From a
philosophical level, I think it's
incredible that your home videos, your
your grandmother's home videos,
and trillion-dollar corporations
effectively are on a level playing field
using the same technology stack, uh
It's It's It wouldn't be a surprise, you
know, these big companies just have
3,000-line FFmpeg commands. There are
some that use the API, but there are
some that just have long command lines.
So, yeah, there's a bunch of tools like
literally command-line tool, FFmpeg, of
course, FFprobe, there's libraries,
libavcodec, libavformat, libavfilter,
but the FFmpeg
on the command line is like legendary
because you can cut There's so many
parameters, you can customize everything
to hell.
>> It's a language. It's an actual
language.
>> actual Yeah, you could think of it as a
programming language.
>> course, I'm sure. Because So, most of
people they're going to take FFmpeg file
in, file out, and specify the format,
right? But you can We've seen
thousands of characters and we've seen
also like people like doing um
programming um
generation of command lines to to to
make FFmpeg. There is a ton of people
who are using AI to generate command
lines for FFmpeg because you have no
idea what it is. But you can do specify
so many filters, right? Uh on command
line, right? So, um FFmpeg is a
collection of toolbox for multimedia
processing that everyone everyone uses.
And everyone that is watching your
videos are also using, right? You you're
on YouTube. Well,
FFmpeg on on the client side. Well, do
your server side you on the server side,
the client side is probably Chrome.
Well, you're using FFmpeg also. And and
you're using OBS to record. Well, it's
FFmpeg, right? You're using a ton of
important like big box professional
boxes. Well, it's very possible that
inside some part of FFmpeg is running. I
mean, there's like so many just give
people idea. Like I use FFmpeg a lot and
and everything. Just trivial stuff like
uh take a video,
add an intro video and an outro video,
and fade one into the other like uh what
is it called? Dip to black like where it
dips and then shows the next video and
does the same thing with the audio.
Uh [clears throat] there's like a cross
dissolve of the audio. It's a quiet It
quiets the audio and makes it loud
again.
And then there's a bunch of stuff like
uh showing the captions on screen hard
like baking the captions in.
You can customize the font.
You can do all kinds of layering of
audio and video. There's a million
things, and of course, all of that works
like magically with basically any codec.
Like anything you you can shove in on
the audio and the video side, it works.
>> But it's like if you if you look like
for example,
you can do things that you would do with
Adobe After Effects Mhm. in command line
on FFmpeg, right? It's
And it's very interesting because for
example, for for for images, there is
not such tool. There is a few tools, but
not with the breadth of FFmpeg. So,
ImageMagick has a similar kind of Yes,
but we'll not do some
>> filters, complex filters. You don't have
the equivalent of Photoshop in command
line, right? But you for video, you have
FFmpeg in command line.
>> Yeah, it's incredible. I mean, it's like
it's an example of a thing where a bunch
of great people get together and they
get a vision and they stick by that
vision for many years, which is
incredible. And the vision behind
and the same for VLC and FFmpeg is that
we make every everything that is very
complex easy to use for the normal
people, for everyone, right? Our goal is
to make something that is insanely
complex technically and make it easy to
use, right? And and people they use VLC,
they drop a file, they don't realize how
complex the file is, but they they play
it. Or or people put any type of thing
inside FFmpeg with filters and it just
works like magically, right? And people
and this is our mission, right? Make
very complex things. We wouldn't be here
and you wouldn't be here if
this required, you know, a traditional
television studio setup. It's tools like
FFmpeg that democratize this the podcast
and streaming revolution, the YouTube
revolution
was caused, you know, FFmpeg was a big
player in that because it it
democratized this technology that was
once in the in the '90s, for example,
you needed
equipment that cost hundreds of
thousands of dollars to do compression.
It was the size of a car.
And now everybody has that at almost an
exact level playing field. And that's
something that's so remarkable. It gave
voice to a lot of people. And we just to
clarify, when you say you you wouldn't
be here, not the human, but the podcast.
>> sorry. [laughter] You you as the sorry.
>> still VLC did not have anything to do
with my biological well
>> [laughter]
>> creating me as a human. You realize also
everything move from text to images and
images to video, right? Look look at
social networks. Video is everywhere.
It's a most powerful
medium there is, right? And and when you
see shorts and and in reels and and
TikTok, right? It's amazingly powerful
to to to give video is amazing for that,
right? But the complexity is important.
>> It's what people don't realize. I mean,
this is really
it gave power to the individual all
across the world. is real freedom. And I
think I can't believe it, but we still
haven't mentioned the actual obvious
thing for people who are not familiar,
which it's open source. And there's an
open source community of users and
developers behind it. So it's really
it's a movement. So like we'll talk a
bunch in a bunch of different ways about
the community behind it. But
can you speak to the open source
element? So if we were to say what is
FFmpeg? It's an open source project.
>> Yeah, so FFmpeg
VLC x264 VideoLAN everything we do is
fully open source. And for the people
who don't understand how open source is,
my usual analogy is about a chocolate
cheesecake right?
Usually for you when you want to buy
your cheesecake, you go to a bakery,
they give you the cheesecake.
The other one way of having a cheesecake
is have your grandma give you a recipe
of how to make that. When we do open
source, we give you the chocolate cake
and we give you the recipe to actually
we make the same cake, but at the same
times tell you how to build the oven and
also how you allowed to modify the
recipe and we sell it to someone else.
Yeah.
>> And this is because software is just a
very long recipe of small instruction.
Computers are not very clever. They go
very very fast. So a normal program has
tens of billions of instruction instead
of the tens when you have your chocolate
recipe. So
a lot of the software industry was about
selling software like like where you
just have like the final cheesecake. In
open source
we make we give you everything. And that
managed to get a lot of people work
together, right? Because then you decide
that you're going to make the best
program, the best recipe for video and
you create communities in
FFmpeg since the beginning of FFmpeg
probably
2,000 to 3,000 people have contributed
from the beginning, right? And then it's
exactly like the Linux kernel, right?
The Linux kernel has probably 10,000
people contributing everywhere. And they
get together, well, mostly online,
right? So, they
virtually get together to create the
best tool for something. And on FFmpeg
and VLC, it's just like
Well, this codec doesn't work. So, I'm
going to work on the codec, and I'm
going to add the support for this file
inside FFmpeg, so it will be beneficial
to everyone. Because again, we work for
the greater good. We work for everyone.
And that is what open source is.
And we should mention, depending on the
licensing,
uh you could probably build a
billion-dollar, maybe even a
trillion-dollar company
around
basically as a wrapper.
>> [laughter]
>> Well, yes, people do. People do, right?
There was a lot of
problems with mostly cloud providers who
are basically running some open source
tools
in in the cloud and just give you uh the
API to access to that, and there was a
lot of
databases like or Elastic who
changed the license in order to avoid
those type of of scenarios. This is a
question we get a lot in FFmpeg is, "Why
don't you do that?"
And you can't We have We have thousands
of contributors. Some of whom aren't
even alive anymore.
You would need all of their agreement to
do that. And And JB will go maybe a bit
later and talk about how challenging
that process was in VLC to do the
re-licensing. The license is a social
contract in the terms of who so de facto
of the community. The community does not
agree on much beside the license. People
go around, discuss around
because of the license. And that also
allow those license fork, right?
Sometimes the community splits, but it's
possible because of the license then to
merge back. And we've seen that so many
times, right? The GCC and GC
um and EGCC in the past. We have seen
for example all the web browsers, right?
They started as web KHTML which becomes
web kit and then which becomes blink,
right? So, open source license is like
the the core of the community and um
people
are coming from all around the world,
very different type of uh religion, um
political borders. They they work
in the same way on a project to solve a
specific problem. And the specific
problem we're working on is to make
multimedia easy for everyone.
Uh looking it up on Perplexity here
looking at the different open source
licenses.
Most major open source licenses fall
into two buckets. Permissive, very few
conditions, and copyleft share alike
requirements for derivatives. Below is a
brief practical summary of the main ones
you'll see in the wild. MIT license,
BSD,
ISC,
uh Apache,
uh GNU GPL,
GNU AGPL.
Where's the LGPL? Yeah, LGPL.
Let's see, there's the the Mozilla
public license, there's Eclipse public
license. It goes on. There's a lot of
variety. I mean, I think I think the
really popular ones is MIT, GPL, LGPL.
And BSD. And BSD, Apache. Sometimes
you'll see
another license, that's an option. It
attempts to dedicate code to the public
domain with a fallback permissive
license. There are many licenses for
many different thing. What people don't
understand that public domain is
something that doesn't exist worldwide,
right? So, it's um all the open source
licensing use the copyright law, right?
The international copyright law in order
to give rights on how you use the
software or how you modify. It's the
facto uh
a copyright license contract that you
give to the end user or to the
developer. And so, you have like the
first one which are basically very
permissive MIT BSD. You give the code
and basically you do whatever you want,
right?
You take it, you want to you modify, you
do what you want. Um and this is uh
popular for uh
JavaScript and the type of BSD operating
system. So some of them what one of the
parameters is whether they require
attribution, meaning if you use the code
you have to say Yes. So in those type of
permissive license some you need to say
if you use it which is called
attribution and some you don't.
And then there is a the other part of
license which are copyleft where you
need to give back to the community your
modifications. And with different string
attached um some weak uh copyleft
license like um the Mozilla public
license to some which are a bit stronger
uh like GPL or even very strong like
AGPL. So all of those are different um
type of licensing that depends on what
your goal are and how you want to
structure your community which is why I
spoke about social contract because this
is very important to understand.
Um
FFmpeg and VLC are mostly GPL or LGPL.
Uh the Linux kernel is GPL. Uh but
Android is Apache. Uh a ton of uh
JavaScript framework that are using um
mostly MIT. Um
all the BSD kernels OpenBSD NetBSD are
of course BSD. Um and and so the it's
philosophical philosophical change on
how you want people to contribute back
basically. So there's a
I think you talked about that
>> [sighs and gasps]
>> uh you've moved at one point from GPL to
LGPL on certain parts of the project.
What what can you describe the
difference in the two and what does it
take to move to I guess a more
permissive So that direction is more
permissive. LGPL is more permissive than
GPL. Yeah. So you have to realize that
you can always go from more permissive
to less permissive, right? Because of
course those license are basically
statement. So, if you restrict, you can
always restrict more, right? So, in a
GPL project, you can take MIT code, but
you cannot do the opposite, right?
Because they are more constrained to to
match.
Um
indeed, in fact, I changed the
core of
libVLC, which is the engine of VLC
>> Mhm. from
GPL to LGPL. Uh and there were two
reasons to do that. The first one is
that so people can use
the VLC engine, libVLC, into third-party
applications. So,
a lot of applications which are playing
video on your phone on your tablet are
actually VLC engine in it, which is
calling FFmpeg in it. Yeah. Um so, that
was
one of the way to create one of the
company I created, which is doing
consulting and integration of those
applications where you integrate VLC
into third-party solutions. Um like
inside game engines or stuff like that.
With GPL, you couldn't do that because
that means you needed to open source
everything, and those are for a lot of
like commercial companies who don't want
that. So, you can create a company with
LGPL, you can create a company around
it. Yes.
>> can do a commercial thing, you don't
have to open source it. So, it's a big
big leap.
>> can play video in your game. Yes. The
prob- The problem is I'm a game
developer,
and I want to play some videos, Mhm. and
I don't want to be forced to open source
the entire game just to play those
videos. So, that's where the the
consulting business, the libVLC LGPL
Mhm. allows you to do that. The LGPL,
the library GPL as it used to be known,
allows you to do that.
>> And FFmpeg is exactly the same.
It force LGPL forces you to give back
what you change on this component, this
the library, which is why it's library
GPL. Mhm. And so, you can use FFmpeg as
LGPL into like any type of application,
even non-open source, but you need to do
give back the modification you did on
FFmpeg, same on libVLC. Is it limiting
from an open source perspective to go
GPL?
Because if you if your uh library if
your code is GPL, it means you're not
you you're basically discouraging
companies
from building a business around it,
right? Is that Does that fair to say?
>> It depends on It depends on the company,
but the company whose business model
requires the source the the application
to be closed source, yes, it's limited.
So, that's why, for example, I moved to
LGPL. The second reason um is a bit more
obscure is that the the terms of
condition of the uh App Store, the Apple
App Store for iOS makes it very complex
to have GPL application on it, while
it's easier to have LGPL applications on
it. So, VLC on Windows and on Mac uh on
Linux is GPL, the core is LGPL, but on
iOS uh the iPhone version and the Apple
TV version is a type of different
license called the MPL.
Um and yes, I I I I went and changed the
license and it was a long story. Yeah,
so I I think basically to change the
license, you have to contact all the
contributors. Yes, it it it's very
important to understand that open source
projects are what we call in the US
copyright uh law joint work or in um
civil law um
collective works or collaborative works.
Is that you work all together in term of
the same goal and then it creates one
software, which is one release. Um but
the copyright is kept by all the
individuals. Some open source project
don't do that, they force copyright
assignment, but this is not what we do
we communities. So, everyone has
basically copyright on what they
changed. Um and this copyright stays
even if at the end your your
contribution was deleted because the new
contribution was based on your previous
one, right? So, if you want to properly
relicense, you need to find all the
contributors. And at that time, I had to
contact more than 350 people. And
sometimes, well, they're just an email,
right? So, it's you need to actually
track down. I I actually like travel to
some place to go somewhere that I was
like sorry that I had found online to
see a
to go to their job and say, "Well, you
licensed that. Can you Do you want to
change from GPL to LGPL?" Most of the
time, they don't even care. They wanted
to help PLT. But also, it brought me to
very complex situation. I arrived to the
work of a person who was a factory
worker. Mhm. Um and I said, "Well, I
need to you to sign that
because it was his son who died who
actually wrote the code, right? So, I
had to explain all those type of open
source meaning and no, I was not a
company trying to rip out the two line
of five line that that guy did, but was
useful and the whole community agreed on
that. And he had no idea he was a
factory worker. He's
And I was a lot younger, right? Like it
was
14 years ago and
like like I was almost in tears, right?
It's we very difficult, right? We're
talking about life of people and he
explaining and we went talk about the
photo of his guy, right? So,
it's important to do it right and to do
it correctly.
But yes, that means tracking down
everything because every contribution
works. Mhm. There are some project who
don't respect that and we do
re-licensing a bit like aggressively.
But as I said, it destroy the whole
heart of the community because it's we
only agree on this on this license, so
that's important. I would emphasize the
community is such a wide-ranging group
of people. There's
people in the Syrian war zone with
electricity part-time. There's
There's all people from all walks of
life, rich, poor, young, old, um
so
it's quite remarkable to get
you know, a group of people aligned on
something. And now,
an achievement in itself. Yeah, it's
incredible. And a lot of them are
introverts. So, you come come into find
them and getting them and getting in
them to answer an email might be quite
quite difficult.
>> Most of us are introverts, right? You
You need to be more precise. You have
extremely introverts, extremely
extremely introverts and introverts,
right? It's just like a whole spectrum
of different people. It doesn't matter.
The important is is your code good? Is
your code great? Is your technology We
care about excellent code. We don't care
who you are. Sorry, it's just like we
have no idea to check. We cannot check,
right? Like maybe you're a dog. I don't
care, right? I don't care where you come
from. I need to look at your code. And
this is important because people don't
understand that and they come to the
community and send them some patches and
they get rejected and they don't like
that because
I mean you're just like, "Sorry, it's
not up to our standards." "Oh, yeah, but
I'm engineer at this very large company
in in in in Italy, in Germany, in the
US." We don't care. We care about the
quality of your code because this is
what defines our community. And which
means that we have a lot of people who
contribute who are some very different
backgrounds and and and very introverts,
sure, but that's okay, right? So, one
one of the legends of the community is
uh of course Linus Torvalds who uh
created Linux and is a long-time
maintainer of the Linux kernel.
As legend goes, he can be pretty harsh
on this meritocratic process of
reviewing the code and saying it's not
good enough. Can you Can you just speak
to to the legend of Linus Torvalds?
Linus is one of a kind, right? And and I
would even go and say that what he did
on Git is more interesting than what he
did on the Linux kernel.
He's very harsh, but what people don't
see is usually when he's harsh to it's
people who are maintainer of part of the
kernel, right? So, they know him, right?
So, he's not very harsh like that to
everyone. The thing is what he created
in his room is basically powering every
server online, right? Even at Microsoft
Cloud called Azure. I'm quite sure
70-80% of the servers are running Linux.
All your Android phones are running
Linux. What he did
um
with the power of a of a resource, sure,
is amazing. Um and yes, the quality of
the Linux kernel is very high and yes,
it's difficult, but
we cannot compromise on that. We cannot
compromise on quality because in the end
and you have to understand that is the
core community of VLC is five people.
The core community of FFmpeg is 10 to
15.
And we are the ones who are going to
maintain your code, right? Because 1,000
contributors in the timeline and just 10
stinks, 1% chance that someone comes and
stays. 1%. So,
you will have change of job, change of
wives, you have children, you have
accidents in life, you're going to
change jobs, whatever. You're not going
to come back.
It's most likely. So, we are the one
going to maintain your code. It needs to
be maintainable. It needs to be
excellent.
And yes, sometimes that means that you
need to rework your work because it was
good, but it's not excellent and we need
excellence because we have very few to
maintain something that is critical for
the whole But we should also mention
that there is some some spiciness, some
harshness to the language
that's sometimes used when you're
keeping this high bar of excellence. Uh
is there something to say to that?
>> It's true, right? Um it's also the fact
that for example, what we're doing is
low level, it's extremely technical. Uh
you get into this community, the tone
gets um
very like a type of it's a subculture,
right? So, people who arrive from the
external um basically not known to the
subculture. Most of those people around
FFmpeg and VLC, we do VideoLAN DevDays,
VDD, every every year. They're so fun in
real life and they love it, but it's
true that you're online and sometimes
like the the tone you don't realize how
it is. Uh but that's okay. It's a
culture. I mean, you you get this in the
gaming culture. There's pretty harsh and
tense the way people communicate. And
it's everyone understands that the way
you show love and respect just looks
different in different communities.
Sometimes people It depends. If it's a
book club, usually people are going to
be much sweeter. If it's open source
>> [laughter]
>> project that's very high stakes and used
by millions of people. But it's very not
often insults that you see for example
in the gaming, right? And so, Linus
Torvalds a bit unusual even for the open
source community. It's more like it's
more harsh on the result thing. No, this
is not good. This is crap. Those type of
things that you will see. Try not to
make it about the person, make it about
the code.
>> Yeah. Yes. It's very very
matter-of-fact. And I think you've got
to look at it in terms of
you know, the famous FFmpeg is developed
almost entirely by volunteers and that's
true. And you've got to imagine
someone's done a hard day's work at
their day job. They come home.
You know, terseness might be a thing,
you know. And and that's not something
to take personally.
You're tired, you're busy, but you still
care about this open source stuff.
But you may not be able to explain and
and handhold someone on every subtle
detail. And also, you have to
realize that most people don't speak
English as a native language. And and
this is especially for for open source
projects like FFmpeg and VLC which are
mostly centered out of Europe. Sometimes
like um
people who are from the US or or just
like are very not happy about the tone,
but most of the time it's also like they
don't know better, right? It's
difficult. The language is English is a
difficult language. There is so many
subtleties and tones and so on that you
don't have, right? So, um often it's
also difficult in those type of
community about like different cultures
and languages.
So, as the legend goes, JB, you have
repeatedly turned down millions of
dollars
to uh keep VLC open source, free for
everyone, without ads.
So, take me through the reasoning behind
that decision of leaving millions of
dollars on the table. Yeah, that's like
almost a meme, right? On on Reddit.
>> There literally is a meme on Reddit.
9GAG [laughter]
and yeah, yeah, I see there's you
looking like a wizard in the in the VLC
hat on Reddit. This is uh JB, the
creator of VLC media player. He refused
tens of millions of dollars in order to
keep VLC as free.
Thanks, Jean-Baptiste Kempf.
You can even summon him on Reddit. Yeah,
[clears throat] and usually if you see
right, it's usually like people tag me,
right? And and then there is me and then
like I say, "Good morning." I got 24K
upvotes, which is great, right? My
comment on Reddit is amazing.
>> [laughter]
>> At least on that account. Um
so, the question is needs to be answered
first is what is the story about VLC,
right? Um because
yes, this is true. I refused
dozens of millions of dollars. Yes,
several time. Yes, I could be a
multimillionaire and be somewhere on the
beach. Um but
I did not do it because I thought it was
not moral and it was not the right thing
to do. And this is very important for
myself is to be like I work for the
greater good. I work for people and I
don't want it's not just about my by
myself. But the reason is also because I
I did not feel that I'm completely
legitimate to do that. And let me
explain you why. VLC story is a very
weird story.
In France, we have university and we
have a type of top colleges Um and those
top of
excellency schools are engineering
school, business schools and basically
lawyers and medical, right? But they're
outside of university. And in order to
enter those, you spend two years working
like crazy math physics to enter those
best engineering school.
One of the school is called the Ecole
Centrale Paris. It has changed name
since, but it was called the Ecole
Centrale Paris.
And because it was
they had to move it because it was too
small after the World War II and and
they moved it and wanted to move it to
the central of France in place called
Clermont-Ferrand and the alumni decided
that this was not okay, right? It is the
the school that Eiffel, all right, the
one who did the Eiffel Tower attended
to, right? So they said, "No, no, we are
amazing great school. We cannot do
that." And so they bought a piece of
land south of Paris,
very near Paris.
And it was a campus managed by a
nonprofit of the alumni. Okay?
Because of that, everything on the
campus was managed by student. The
university did nothing, right? So
radio, TV, supermarket,
library,
defining who was going into which rooms,
everything was managed by the student.
>> That's an amazing experiment.
That it all didn't go to hell quickly.
It somehow
flourished. It worked great and I
learned so much in my life doing those
side activities, right? Because you're
you're 22 and you need to run your
campus, else you don't have electricity,
right? So you care about that, right?
But anyway, in the '80s,
they did a full experiments of deploying
a network, mostly sponsored by IBM and
3Com, which was a token ring network. So
token ring is something that probably
almost no one knows about anymore. It's
a networking technology where you don't
have routers, right? Everyone is linked,
um it's type like really a ring, and
when you want to send a message, you
talk to your neighbor who's going to put
the message to the next one who's going
to put the things to the next one.
In terms of ring. The issue with token
ring is of course is that it's very slow
because every computer on the network
needs to open the message, see if it's
okay, is it for me? No, it's not, and
then send it back like a token which is
traveling around the ring.
In the '80s, you're doing some Telnet
and sending mails as university, that's
okay, right? But starts the '90s. And
the '90s end start video games, and when
you have li- high latency video games,
basically, you die, right? So, in 1994,
1995, around Doom and Duke Nukem coming
around, they want to faster network. So,
the students go and see the university
and say, "You know what? We want to
faster network. We need to work,
which also play video games, um and the
university tells them that basically,
"Oh, I'm sorry, we cannot help you
because you understand,
the campus is not ours. You manage it,
so
do something." And you should see some
basically partners of the university and
basically go away.
And [snorts] they go, and they actually
go and see um the the the CIO of uh
Bouygues, which is a large French
company, and who's doing some TVs in
France, and he says, "Well, you know
what? The future of video is satellite."
Well, today we know it's not, but at
least it was a good idea. Yeah, 1995,
the first of satellite dish, and he says
that
instead of having like one satellite
dish and a big decoder for each of the
students, which are 1,500,
what about you build uh like you put an
enormous dish and only one decoder, and
you send the video directly
on the network. Mhm.
>> [snorts]
>> And that required a very fast network.
Today, it's obvious, but at the time was
like the first to do video streaming.
So, they build this project which was
called Network 2000.
And of course, we we are in the '90s,
right? Everything is futuristic is
called 2000. Like
>> yeah.
And so, they do the network 2000
project. It's completely hacked. It
crashes after 45 seconds. That's okay.
The demo is 40 seconds. It leaks memory.
That's okay. They put 64 megabyte of RAM
instead of the eight or 16 you have. And
the demo should have stopped there. And
that was the Network 2000 project by the
students.
>> What was the format of the video that
they had to work with? MPEG-2 because
satellite is MPEG-2 TS for transport
MPEG-2 video and MPEG-2 audio at that
time. And
the project should have stopped there.
Everyone was happy. They had like
amazing ATM network at 155 55 megabit
per second. They had probably one of the
best network in Europe at that time. And
they stopped the project. Six months or
a year later, two students arrive and
say, "Well, you know what? Maybe other
people care about video streamed on a
local network." And they create the
VideoLAN project, VideoLAN. And one of
them is called Christophe Mascio that is
a good friend of Bosquet and me. And
they start the project. It's not even
open source yet. And they spend around
three years to get the school to agree
to make it open source. Because the
university wanted to get some because of
the IP and copyright of the students
wanted to basically monetize these
MPEG-2 decoders. Just to be clear, so
what was the main application? Streaming
on a local network?
>> It was streaming on a local network.
>> just like to state the obvious. This is
before YouTube. This is before
>> 10 years before YouTube. You have a
Pentium 60 or 75, right? You you you you
the main machine was 486 DX at 33
megahertz, right?
>> Bear in mind, television was the main
form of video at the time. You could get
new channels in the '90s having even one
new channel when you you grew up with
four channels, having a fifth or a sixth
was a big deal. And so, having
this satellite service with you know
dozens even hundreds of channels was so
groundbreaking. Especially because this
is a university where you had ton of
different nationalities, right? So there
was a ton of people who wanted so the in
the end they had like several dishes on
different type of satellite, right?
Because for example, a lot of people
were coming from the Maghreb or the
Middle East and and they they so they
went to different type of
of satellites. Anyway, the solution
worked great.
And they started the VideoLAN project.
The VideoLAN project has several
and some are completely crazy solutions
like one how to create multicast on an
unicast network, but let's not come to
that. It's too too complex, but VideoLAN
client part is what became VLC. Mhm.
Actually, they basically strong-armed
the university to force it to open
source because university did not
understand that. And in 2001, it's still
early, but basically yes, the university
agreed early 2001 to make it open
source. I joined the project in 2003
because that's when I joined the
university. So the first thing is
I'm not the one who created VLC because
actually
no one did, right? It just kind of
naturally emerged from the VideoLAN
project. And we should mention that like
again, you you you said it just but to
make it clear, VideoLAN
as what it became or was at the time is
a set of technologies around video. The
VLC, what you call the client, that's
the thing that most normies
uh
>> That is correct. And think of like as
the thing which is like the thing that
pops up when you click on a video and
you play it. So I arrive in 2003 and
then I will create
the open source
non-profit organization called VideoLAN
and I took everything out of the
university to create it a non-profit
project and something sustainable. It's
yes, it's true that I spent more time
than anyone on VLC and VideoLAN, that is
sure. Um but it's a continuity of a
previous project VideoLAN, the student
project, which is a continuity of the
network 2000 project, which is a
continuity of that and that. I'm sure
there's moments along the way there you
were thinking like what is the future of
this from the open source perspective
cuz as as the internet is blowing up and
there is companies, I mean for people
don't remember, like there's companies
making huge amounts of money.
>> And I can tell you that in 2005 the
project should have died.
Um and I made it to continue the
project. At some point we were only two
active developers.
Um
and I thought it was a great technology
and was useful and it will be useful and
and and I made that my my my life and my
my time. Um and I made that grow from a
few hundreds of thousand of users,
millions of users to what we have now,
which is probably billions of uh version
of VLC around the world and used
everywhere. Um so
that's a bit the story of VLC. There is
ton of very funny story around that.
Many people from
uh around the world working on it, like
you said in Syria or middle of nowhere
in India.
But along the way I got several offers
which were either to bundle
uh toolbars, right? You remember those
horrible toolbars which were basically
spyware or changing your web browser or
your search engine or even like
advertisement inside VLC. And
I didn't like that, right? I am And and
people don't understand that is not I'm
not against money, right? I'm very happy
to make money. I created several
startups and one I hope that is going to
work very well. It's a fact that I
believe that you need to win money
ethically. There is a right way of doing
that. And and doing sneaky advertisement
or stealing data is not the correct way,
right? For example, if Netflix arrived
at some point and say, "Well, we want to
put Netflix inside VLC." Probably the
story would have been different, right?
But they didn't. The only people who
came to us were
shady ads company. And if I do that,
right? I would have a ton of money,
right? And then 3 years later,
project is gone, right? Someone forks it
and and something else happens. So, it's
not even necessarily ads or any of that.
It's the shadiness of the dishonesty of
the So, you had a good radar, you had a
good threshold of like, "No, this
compromises the spirit of what this is
supposed to represent."
>> But also it's it's for me, right? I'm
like very selfishly, I need to go to bed
at night and be happy about what I've
done, right? Maybe it's my upbringing.
Um maybe it's my parents' fault or
whatever, right? But I believe there is
right and wrong, right? And
this was the right decision at the time.
It still is. I want to be proud of what
I've been doing. And
like if I had sold out, I would have
betrayed so many other people work.
>> Yeah. Well, I should say me and most of
the internet thank you for that
decision. It's inspiring
uh for others. Uh I think that
um that are pushing open source movement
forward.
That it's okay to do these kinds of huge
sacrifices if you believe it's right.
And I think in that case it was right
and it was the reason that VLC became as
successful as it was cuz it it's an
embodiment, it's a symbol of
like, [snorts] you know, freedom and
what the open source community can
create. Yeah, and be of service for so
many people around the world. And this
is important.
>> We should emphasize in the 2000s it was
really normal to download a program and
it secretly install some spyware. Yeah.
It was it was buried in very faint text
or in the the
text box that nobody reads that at the
bottom, "Oh, I will be installing this
toolbar and changing all these things."
And it was It was very common to have
to, you know, you install a program to
do something at the time of any sort. To
put yourself in the mind of a developer
at that time, I think it's very easy.
To everybody listening to this, it's
very easy at that time to convince
yourself
to take a few thousand dollars, a few
thousand dollars to do it.
To to say no
to much more money takes
guts and takes vision. The last offer I
had was obscene.
And they say, "Yeah, but imagine with
all that money, you could build
something new open source, right?" It
was like the mind trick was
it was difficult. And for me, it was
just like, "No, this doesn't work like
that or this is not the right thing, so
I don't do it." I I I
And again, right? It's not that I don't
like money or whatever. It's just like
it wasn't right.
Well, once again, thank you for me and
for the rest of the internet.
Let me talk a little bit more about the
open source movement, about the fact
that, as you say over and over and over
and over, FFmpeg
uh
is and many open source projects are
built by volunteers. So, uh there's a
bit of drama recently uh Karen on the
interwebs, on Twitter.
Uh you have a spicy style on Twitter
that I think articulates and celebrates
all the incredible developers and uh
development and the uh
the code, especially assembly, that's
involved in uh building some of these
codecs and building some of this
incredible technology. But, that brings
us to the a bit of a debacle that
happened. Tell me the full saga of what
happened with the Google security
engineers. Just to be clear, Google
[clears throat] are one of the biggest
supporters of open source out there.
They have been for a long time. It's
just I think some things kind of went a
bit overboard this time. So, FFmpeg
itself, and and this is not like a
secret, it's on the homepage in the the
it processes untrusted data. There can
be security issues when you parse
untrusted data, that's very normal. But,
recently what changed was Google started
using AI to create security reports on
an open source project, FFmpeg.
>> [sighs]
>> Volunteers had to deal with that. They
did they provided very limited funding,
and they even went to the media first
announcing how good their AI was
before the issues could be fixed. And
this is in the public forum. Yeah, this
is
>> So, they're reporting reporting an issue
using AI to find an issue in the code,
which is a security vulnerability, and
then reporting that publicly before
you're able to fix it.
>> Yeah. It's announcing how good their AI
is. They provided a standard 90-day
industry deadline,
um
without potential without really
understanding the nature of
volunteer-driven development. In
addition, this vulnerability was one of
the obscure 1990s game codec.
Um
the way and let's look at it from their
standpoint to begin with. Let let's you
know
>> Yeah, can you steal man their case?
>> Yeah, sure. They have substantial
resources working on the security of
open source projects
that, you know, are ubiquitous, and
they've used, you know, a lot of
computer to do that, and very expensive
and very capable security researchers um
to do that. And that that's their
viewpoint is they are contributing
by doing that. But, I think that's where
opinions differ.
Um
It it it opened up a lot of interesting
fissures, uh I would say. Um
It does seem that there's a portion of
the security community that um
look at themselves a bit like building
architects that never have to go to
site. You know, going to site is
something that is a little bit beneath
them, the actual day-to-day
construction. They're there to do their
security things, and it's someone else's
problem.
>> [sighs and gasps]
>> The security industry also kind of has
a very aggressive tone towards things.
The language they use is extremely
aggressive. They use very strong
language like, "You will get popped." Um
so, and to Joe public, get popped
you know, it means something quite bad.
Um for them, it means to get hacked.
The way I would look at it personally is
a little bit like the padlock on your
home. Um
not everyone that a padlock on your
home, or you know, the lock on your home
is there to
to protect against the
capabilities of of what it's there to
protect. It's not there to protect
nuclear secrets. It's not there to
protect Fort Knox. And
it could be looked at that they're using
AI at a level of scale to go and
pick those locks and then say, "Hey,
your lock's your lock's not secure. You
need to deal with this." Whereas
actually, they're the ones with
resources
to be able to
to fix this. But, that seems to not be
something either they'll contribute to
in terms of patches
or in terms of financially. And if the
scale of AI is kind of the issue that
the
the bug reports are very wordy. They're
very very It's almost a denial of
service by AI-generated bug reports on
very niche codecs. Um
And the other issue the security
community has is everything is marked
high priority. You're going to you know,
this is the most important thing in the
world, and you need to deal with this.
High high high vulnerable scary scary
scary
on a game codec used
on one disk in 1993. Yeah.
And that that's where the dichotomy
lies.
Going around
telling everyone that their padlock's
not safe, well, that's a hobby project
of somebody.
The the safety of that codec is
consummate to what that person thinks.
It's their hobby. It's good that they're
security analyzing it, but it doesn't
need a big scary warning, "This is a
critical vulnerability." Um
may also may may recently also um see
that um there was another quote-unquote
vulnerability. It wasn't at Google in
this case, but um
a filter could overflow and have an
integer overflow, and one of your pixels
could be the wrong color.
And this was marked high, 7.5 severity
in red.
And at some point the security industry
needs to realize you can't keep crying
wolf like this because this just leads
to people, you know, the equivalent
thereof of putting
password stickers on their PC, you know,
you can't just keep crying wolf every
day. And and I appreciate, you know,
that's their modus operandi is to create
as much
scared and fear, but
from the Google standpoint, at the end
of the day,
they need to contribute either
financially or with patches. Google uses
FFmpeg at a a scale probably you or I
couldn't even contemplate.
Millions of CPU cores.
And yes, they contribute in areas mostly
regarding their own products, so VP9,
AV1,
but
in a wider sense,
there's a disproportionate level of
contribution. Yes, they fund students.
Yes, they fund Summer of Code.
And I think so Alex Strange is a former
FFmpeg developer I think posting in a
personal capacity. So he posted about
security engineers on Hacker News.
His post reads, "The problem with
security reports in general is security
people are rampant self-promoters." In
parentheses,
"Linus once called them something worse.
Imagine your humble volunteer open
source developer.
If a security researcher finds a bug in
your code, they're going to make up a
cute name for it,
start a website with a logo.
Google is going to give them a
million-dollar bounty. They're going to
go to Def Con and get a prize and I
assume get some kind of secret security
people orgy where everyone is dressed
like they're in the Matrix.
Nobody is going to do any of this for
you when you fix [laughter] it.
They're basically commenting on the sort
of the incentives
for the different people involved and
misaligned. The problem here is
is the disproportion of means on
discovery compared to patching it,
right? And this is the biggest issue,
right?
And after that debacle, Google did some
changes.
>> to send patches, which is yeah. And they
also now have rewards tools for fixing
issues. So, it has changed a bit because
of that
debacle. So, it's good, right? But we've
seen and we talked about Google, but we
have seen like some some other large
companies saying, "Oh, you need to fix
this bug because it's critical in our
product."
>> Can you explain xc fiasco? The ffmpeg
tweet reads,
>> [sighs and gasps]
>> "The xc fiasco has shown how a
dependence on unpaid volunteers can
cause major problems. Trillion-dollar
corporations expect free and urgent
support from volunteers." Microsoft
Microsoft Teams posted on a bug tracker
for a volunteers that their issue is
high priority.
After politely requesting a support
contract from Microsoft for long-term
maintenance, they offered a one-time
payment of a few thousand dollars
instead. This is unacceptable. We didn't
make it up. This is what Microsoft
Microsoft Teams actually did. And then
they uh you give
the image and the details and all that
kind of stuff showing that these
trillion-dollar companies are
not giving much money, not giving much
support.
>> they think an open source project is a
traditional vendor that they have an
SLA. They think a public bug tracker is
actually,
you know, a a third-party vendor's Jira
where you can do all of these things. It
It It's not It It's there to report
bugs.
I think the thing that made this
particularly heinous was
the name dropping of Microsoft, the name
dropping this is a visible product.
If this was if this was a just a general
bug report, I think that would have made
it a lot better. Yeah, so they literally
said like this is a big deal because a
lot of people are using it in Microsoft.
I wonder what happens psychologically.
So, I think what happens in these
companies, maybe you can correct me,
is they you're you're right. They just
think of FFmpeg as like a vendor
that Microsoft surely is paying a huge
amount of money to.
They kind of assume that in their
interaction and nobody anywhere on the
stack is going like, "Wait a minute.
Shouldn't we be giving like millions of
dollars to FFmpeg?"
>> And this is a very big problem in large
like we're talking about some companies,
but it's the same
everywhere, right? Um a lot of those
companies
like the the when we talked to that
person, right? He was just like a
manager on one project in Microsoft
Teams, right? He had like never really
discussed with open source community. He
had no idea, right? He was like and
but the problem is that usually there is
what we call OSPOs, right? Open Source
Program Offices in those type of
companies and they are the ones who are
supposed to discuss with open source
vendors
or or open source communities, but like
they often don't explain that correctly
internally, right? And here he's just
like
"We are not your supplier. If you want
me to be your supplier, I'm very happy,
right? I will send you a contract and
SLAs." Like I created a
five companies who are doing that around
open source projects, so that's okay. We
should say that some some of the spicy
tweets that Kieran you're behind and
some of the debacle
produced results, positive results.
Donations have increased substantially.
They're still not enough to cover even a
single full-time developer, but
on both
you know, awareness level and a
technical level,
there's substantially more technical
awareness and sort of awareness of the
importance of FFmpeg as a result
as a result of X and and what's
happened.
I can say you know, it it it served its
purpose. People realize
the level of importance FFmpeg has. And
on VideoLAN it's the same, right? Like
for example, a a very simple example,
>> [sighs]
>> for more than a year we couldn't update
VLC on Android because of a bug on the
Play Store, on Android Play Store,
right? The only way we got someone to
answer was to put a
very spicy as you say um tweet saying
that we were going to stop distributing
VLC for Android, right? And we have
around 100 million people using that. Um
and now then
someone from Android actually came and
discussed to us, right? Um
we had the same issue with with um
Microsoft or or like saying that we were
going to stop distributing VLC on the
Windows Store. And unfortunately, we are
so small that the
only very strong power we have to solve
those issues
is blaming on social network because
it's no balls and now they listen to us.
But so as large companies often have
difficulty
talking to us. Like for example, VLC
right is probably one of the top 10
software used on Windows.
I am not part of Microsoft ISV
programs, [snorts] right? I don't have a
point of contact at Microsoft, right?
Well, I'm sure any other software,
Adobe, Spotify has a a point of contact.
I don't have that, right? So
raising awareness works. It's sometimes
very spicy, a lot of drama. Um
X and Twitter are okay for that, but
it's efficient.
Uh so, everybody listening to this
should go
uh follow FFmpeg on Twitter
on X,
follow VideoLAN on Twitter on X, uh go
donate, donate
to FFmpeg. And thank you, Lex. Over the
years, several years, you've been a
supporter of, you know,
FFmpeg and VideoLAN on X, you know, just
giving us shout-outs, appreciating, you
know, what we do. FFmpeg for life. And
for example, like um Tim Sweeney,
Carmack, and a few others, like very
high-level people have raised also the
awareness on on our X accounts, and that
helped a lot also. Car party Car party,
yes.
>> yes. Yeah. Yeah, I mean, also, you know,
outside of the fact that so many people
use it, it's so impactful on the world.
It's also a great representation of a
great open-source project. Like the
value of assembly in C, and making sure
that like you take
programming seriously for real-world
systems. It's not just that. We We'll
talk about assembly later, I'm sure, cuz
that's its whole topic in itself, but
it's also celebrating
people like Andreas Röhnisch who do
maintenance. It It's
I believe unpaid. As I believe as a
volunteer, he's doing massive
refactorings. Uh Andreas Röhnisch and
Anton Kern of rewriting ffmpeg.c with
threading. Celebrating those guys,
celebrating the untold labor that's gone
into this
that actually doesn't change anything
from the user standpoint. The files are
exactly the same, but wow, the the the
airplane has been rebuilt whilst it's in
the air. Christian Garcia said as a
teenager running this account, referring
to the FFmpeg account, and you
responded, "Teenagers have written more
assembly in FFmpeg than Google
engineers."
But also just
pointing out that there's a lot of
incredible contributors who are
teenagers. Like JB said, "We don't care
who you are, where you're from, what you
do."
Teenagers have written thousands of
lines of assembly
over the years.
Give a shout out back in the days to
Daniel Kang.
So, also highlighting the work of people
like Ruikai Peng. This is a 16-year-old.
Some of his first contributions to
FFmpeg
actually doing and putting some of these
quote-unquote security researchers to
shame by actually by actually finding
issues and fixing them and being 16.
There's no barriers. There's no barriers
to you have to study on at college under
this person and understand these. It's
You can learn C. And let's be honest,
it's from it's from the K&R book. Learn
C.
Uh you can learn assembly. We'll talk
about that maybe a bit later.
You can contribute to world-class
technologies. In VLC, um one of the
oldest contributors called Felix, he's
the one doing everything on Mac and iOS.
He starting working on VLC, he was 16.
Um we had a guy called Edward Wong who
used to be a Google Summer of Code
student who stayed for 3 years around
VideoLAN. He was 14, right? Um and and
part of Google Summer of Code and Google
Code-in, which are programs where uh
basically we have students or high
school. Um we wrote a ton of assembly
for x264 and for VLC and for FFmpeg,
right? So, everyone can contribute. And
he also did a good job because he didn't
play the alarmist um CVE highest create
a CVE, which is like a
public exposure security and but do
these big scary red 7.5 high priority.
He just fixed an issue in Git after 3
days and just fixed it. He didn't need
to go and play a big security drama
about it. And I think
I posted, you know, the kids are all
right. Whereas there's there's there's
there's, you know, there is a
I'm not saying all security people do
this, but there is a portion of the
security community, as Alex said, that
likes to hype themselves up by creating
drama. They would have happily raised,
this is a high priority CVE 8.0 or
whatever on a
on a issue that actually was in Git. It
wasn't even in a release. It was in
development and 3 days later it was
fixed.
Well, I just want to put a little bit of
love out there even to the bigger
community.
Um
much love and respect to Google
engineers. Like you said, they're uh
uh some of the the the best software
engineers in the world and they do
contribute a lot even on the security
front. And also, you know, I'm a big fan
of Theo. Much love to Theo. He was part
of this
uh debacle and drama a little bit. I
think when you just zoom out
on the grand arc of human history, the
drama contributed positively to
everybody involved. Donations went up.
It brought [snorts] more attention to
the topic. Allowed
everybody to bicker in a way that
ultimately got them to figure out what a
femboy is all about. So, the way the way
we looked at this is like it's a rap
battle at the end of the day. You know,
>> [laughter]
>> but it it is
We say stuff. We say stuff. Yeah. But we
can we can leave it on X is a perfect
place for, you know, international rap
battle. You say stuff. I say stuff about
your mama, but it doesn't mean, you
know, I'm going to have an actual
personal issue with her.
And that's what it looks like. The the
Theo situation, you know, JB can maybe
expand one a little bit too far and it
was a little bit
You know, it it's just a bit of fun.
It's just a bit of rap battle. It's a
bit it's
WWE. You know, everyone's having a bit
of fun on X. It doesn't need to be taken
seriously.
You know, the the teenager thing, you
know, that So, that that guy was a
Google employee saying, "Hey, you know,
there are other ways to run an open
source business. Go and go and go and go
and go and just have a bit of fun, you
know." That's what the point of this
account is. And and furthermore, if you
can teach people about the ways of
open source projects, assembly, etc. By
doing that, I think there's a lot to be
offered here. It's not dunking on people
for dunking sake. It is showing actually
the story that I think X learned is
these are not big corporate open source
projects. This is not Kubernetes where
there's
you know, hundreds, maybe thousands of
people paid to develop this stuff. These
are just people in their basements in
their spare time.
And if you can address that topic in a
fun and entertaining way,
I think that
that that's the good thing and that's
that's the value of X and then the reach
we have. And and and to be honest,
right? Like even on at Google, Google is
one entity but so many different people,
right? And and some and there is a ton
of Google engineer we work with
um
all the time and even like Google from
YouTube to Chrome to Chrome media to the
rest of Google. Those are very different
type of entities, but what we do is
efficient. And and for example, for for
for Theo, right? It went a bit too far.
I had him like I I calm everyone down. I
had him on the phone. We said, "Okay,
like this goes too far." and so on. But
in the end,
yeah, it's a hard battle, but it's
positive for the project. It like the
awareness we have on open source and and
I mean true open source from
communities, right? Not is
increased dramatically in the last 2
years and this is useful.
Uh what really motivates
all the incredible contributors that
we've been talking about? Like what's
the what's the engine? It's so
interesting to see. Like you said,
they're sitting in the basement. What's
the driver? What's the engine there?
There are many uh drivers, but weirdly
the main one is that what we do in
multimedia plays videos and video is
cool, right? And and for example, we
have so many people in the community who
arrived because they loved watching
anime, right? And and this is like the
advice when people ask me,
"What should I work on in open source?
How do I start?" And my question my
answer is always the same. Work on
something you love. I am working on VLC
because I love movies, right? And I love
watching the same movies over and over
even if my wife hates me when I do that,
right? But because it's interesting,
right? Because it's a topic that you
like, right? The first That's the first
thing where people come to usually to
VLC and FFmpeg. The second thing is that
technically, we, because we search for
excellent, this is the best school ever,
right? This is the best school ever of
programming. If you good in C, in
FFmpeg, if you know how to write
assembly, I assure you you're going to
be one of the best programmers ever,
even if you're working on writing type
trip. Because this is the most amazing
thing to do. And you will like have to
get reviews by some of the most seasoned
programmer ever who are going to look at
every part of your code and tell you why
it's not great. It's like we have the
best teachers that you've ever had in
programming, right? Andrew Kelly started
Zig. He was an FFmpeg developer and
started Zig after the FFmpeg school. I
mean,
it it's the place to learn so many
aspects of programming in the real
world, in a thing used by billions of
people.
You have nowhere to hide. You have to be
open and honest about your flaws and and
how you can learn and be better. And
what is also interesting in multimedia
is that
you have 16 milliseconds to display a
frame.
It's not like a game engine where you
can basically slow down and wait a
frame. Like so, it's you need to be
good, right? There is no choice. Else
you don't have your video. And and
because of how codecs, if you miss a
frame, you're going to destroy the look
of the video, right? So, you need to be
good. You need to be perfect to have the
right thing. But also
is that it's not just pure programming
in the mathematical sense, right? A lot
of people don't understand, but um
in order to program correctly on the
open source multimedia community, you
need to understand how computer works.
And and when you write assembly, you
need to understand about uh CPU
pipelining, right? You need to
understand how a works, how the ALU
works, right? You need to understand how
IO works, right? And this is what I
think that is missing to a lot of
engineers and software engineers today
is understanding what we call computer
architecture. Um and like seriously like
some of the debates is like should we
use this assembly code or this one and
people say well no it's going to be like
three cycle on this type of CPU and this
one and it has massive impact on the
output, right? We should expand FFmpeg
is probably one of the biggest CPU users
in the world. There's probably it's
probably running
as we speak
easily a hundred order of magnitude a
hundred million, maybe even a billion
CPUs as we speak. So every instruction
matters. There's not
the the impact at least in terms of CPU
is massive for everything that we do. So
first you come because it's an
interesting subject, then you stay
because it's excellent and in the end
you're very proud of it because it's on
the end of everyone.
Like so many people like oh I'm working
for whatever consulting company and I'm
doing some
portal to download invoices for your
PG&E. Wow, great. Like so many jobs are
like that. You're not going to to tell
that to your grandma. But if you go to
see your grandma and say I do this so
that you can play video on your laptop,
they understand. And this is very
important, right? Because you're working
on VLC, FFmpeg, x264. It's in the end of
hundreds of millions of people and you
have an impact. Um and so you can be
proud of yourself. And so I think that
in addition to great doing a great
resume, all those things are why people
contribute. Yeah, those are side
effects. My favorite quote on this topic
is John Collison. He said the world is a
museum of passion projects, you know,
everything out there is is a passion
project and
open source multimedia and open source
in general you can just do that so much
faster. There's such a faster network
effect, you know. Mhm.
I can open a cafe and that can be my
passion project, but I have to get
building codes, I have to build a
building, I have to find a
find a location, I have to do all the,
you know, all sorts of things. Well, in
the software world, that passion project
can be can move quickly, it can be
amplified by the network effect. And
that amplification can be more than the
the sum of the sum of the parts. You
know, you can be you can find people
interested
in extremely obscure things and have a
network effect and make something that
is truly amazing. And
on that topic of passion projects, uh
Tim Sweeney actually said in a reply
to a tweet that was uh complimenting JB,
he said, "Many things in the world only
happen because an awesome person decides
to do it. This is the case with VLC."
And that speaks to something interesting
to me. That does seem that a small
number of people, sometimes one person,
can create
something incredible in the software
world. Like you said this over and over
and over. I think JavaScript is an
incredible thing created by by uh
initially a single person. The some of
the programming languages like Python
and C and Java, like there's one person
has this vision, has this design, and
brings it sometimes over a weekend is
the initial spark. Yes, Linus built Git
in 2 weeks. Yeah.
Wow. Yeah. And changed the world. Git, I
mean, it really changed the world.
Linus' passion project. Hey, I'm
uploading these tarballs to an FTP, like
deal with it. But for me, it's not just
in software, right? And I believe in in
in individuals that are going to change
the world, right? And it's with a good,
as you said, vision, right? I want to do
that. Um it is useful, it will be
useful. And whether it's going to like
build trains or cars or rockets or
something like
I I believe people who believe in
themselves and have a vision can have a
huge impact for humanity.
Let's actually zoom out before we zoom
back in. We'll just keep going up and
down the the stack. So, uh you know,
we've been talking back and forth VLC
and FFmpeg. Karen, you said that FFmpeg
and VideoLAN VLC coexist. And there's no
central point of importance. Is it kind
of what you call the binary star system?
Yeah. Uh they succeed because of each
other. Can you explain the difference,
how they interact, what is the
Are they competitors? I don't I don't
think they're competitors. I think I
think the simple answer is the short
answer before I go into detail is VLC is
to FFmpeg as Android is to Linux.
So, they depend on each other, but they
they coexist because of each other. So,
they are a binary star system is the
analogy I used.
By the way, I feel horrible that I just
recently learned that Alpha Centauri,
the closest star system to us, is a
triple star star system.
>> And and when you start doing the
physics, it's a nightmare, right?
>> Yeah, I I I I I I I I I I I I I I I I I
I I I I I I I I I I I I I I I I I I I I
I I I I I I I I I I I a lot of FFmpeg
pipelines involve the x264 project,
which is a VideoLAN project. I would I
would put a finger in the air that's say
80 plus percent of those pipelines are
dependent on a VideoLAN project.
VLC, obviously we've discussed a
VideoLAN project, uses FFmpeg, gives it
reach, exposure to weird files, uh
historically used some donation money to
fund FFmpeg FFmpeg development, and
we'll talk a bit maybe about some of the
reverse engineering later.
So, it's a binary star system. They they
work and feed off each other. Many of
the developers are shared.
There's no central location. It's a
virtuous cycle working together.
I wish to mention that x264
is the encoder for h.264 video standard.
So, h.264 is the standard.
>> Yes.
x264
>> open source implementation of the
standard that's used by basically
everybody for everything. Yeah, it's the
main driver of this. When you think of
an MP4 file that has H.264 codec in it.
If it if it came from a software
environment like a data center or
somewhere, the chances are it was
created with X264. And that's under the
flag of VideoLAN.
>> That's a VideoLAN project. So, in the
VideoLAN graphic, it sits in the
VideoLAN world. And VideoLAN has a
There's a bunch of stuff in it. Go to
the VideoLAN website. There's a bunch of
icons. Like if you look, there is so
many libraries, right? Um libdvdcss,
libdvdnav, libdvdpsi,
libvlc of course, VLC unity, libbluray
libbluray
Uh yeah, there's a lot of
>> And there is so many more, right? Like
lately the David project or that we
might talk about is the last project
from VideoLAN. It's everywhere, right?
And we do we have a
audio lately that we announced. We have
Check ASM Check ASM which is like an
insane project but amazing. Um so, and
X264 is one of those VideoLAN project
and my opinion for example is that
X264 was is the most amazing encoder
ever designed
and this helped the adoption of FFmpeg.
A lot of people and large companies went
through FFmpeg because they wanted to
use X264 and X264 increased the
popularity on FFmpeg. But also, VLC had
its popularity because it played so many
files that were done by FFmpeg, right?
So, it's it's many projects that are
interwind and work together.
>> Yeah, unfortunately there's a there's a
thing on X where
VLC is mentioned and there's people
quick reminder that it's FFmpeg inside
doing the actual work and that and
that's like I said, it's not
that not the case. We work together.
And and to give you an idea, right? When
I compile VLC for Windows, I compiled
around 16 million lines of code, right?
1 million of those are inside the VLC
repository and FFmpeg in total is
probably two.
Around two, right? But that means that
so many dependencies are outside. And if
you also look at FFmpeg per se, FFmpeg
also is integrating third-party
libraries like x264, lib opus, and so
many others, right? So we all depend on
each other.
Uh yeah, that's why I was hoping to do
this episode as we are doing. They just
kind of joins FFmpeg and VLC cuz it's
really it's really two two of the same
except
binary star system and we're all just
orbiting it. Uh can we give a shout-out
to some of the people along the way we
didn't really quite talk about the
history of FFmpeg. So
maybe can you tell me about Fabrice? Can
you tell me about Michael Niedermayer?
Can you tell me about some of the key
figures here?
>> the the eras of FFmpeg cuz there's
key eras and key people that made this
possible.
Uh
Fabrice Bellard as you mentioned,
creating the concept. And then probably
in the 2000s era, I would call the era
eras tall of FFmpeg is that the 2000s
era was Michael Niedermayer.
So
key things he got done was exhaustive
support for DivX and Xvid
at the time and all sorts of weird
variants of what's known as MPEG-4 Part
2. So this predates the MPEG-4 Part 10
that we used to. So this was 2000s era
video codecs where there were
uh flavor after flavor of weird weird
decoders.
At the time in the 2000s, you needed a
new player to play every different type
of file format. So there was Windows
Media Player to play Windows media
formats, there was RealPlayer to play
RealMedia formats.
And those were the other the other key
thing in FFmpeg at the time were native
decoders for those. I actually remember
being
a teenager, I must have been,
figuring out there was this one player
that could play
could decode these files without having
separate bloated players. Cuz at the
time when you downloaded Real Player,
there was a ton of other stuff in there,
a ton of ads, a ton of other things. So,
just having a simple library
that was fast led to that.
And then I think 2008 was a 2008 onwards
was a big change because that's when
H.264 got its maturity. And and I think
something hopefully we'll talk about a
bit more. This was the beginning of high
definition video.
So, H.264 was the key decoder of that.
So, I'd call that the late 2000s and
2010s. And that's when the big reverse
engineers came along and really did
astonishing work.
The beginning was a single player that
could play Xvid, DivX,
Windows Media, and Real Player was
already in a massive achievement in
itself. Without codec packs, without
weird stuff you had to download that had
weird ads and weird spyware. VLC 1.0 was
out on those times, 2000
2009, 2010. And this is like
where it exploded. Yeah, without codec
packs, it just works across all these
different It The fact so it's just like
all the codec packs are FFmpeg inside
VLC. Plus, we have other modules for all
the type of codec.
>> at the time that wasn't is there were
weird In the 2000s, there were weird
codec packs with DLLs coming from this
place, DLLs coming from that. With
spyware, with you know what. You It
wasn't reliable. You didn't know. And
having a single player that was open
source, a single playback module {slash}
player
that could do this that was open source.
But I think the thing to emphasize is
this task in the 2000s that Michael did
was was Sisyphian. It was really The
number of edge cases are or beyond
comprehension in terms of you could have
a Chinese CCTV system that did one weird
variant of MPEG-4
part two was known as MPEG-4 ASP and
that was a weird variant and you had to
fix that without breaking everybody
else.
>> Mhm. Times a million. So that's uh so
you said that that's where a lot of the
reverse engineering was happening.
>> It start It started in the 2000s with
the Windows Media stuff cuz that was
proprietary. It started with the Real
Media stuff with Benjamin Lawson. Kostya
Shishkov. Kostya Shishkov that era.
Those were the key That was the key
groundwork.
And then in in the 2010s was kind of the
poor Mahol Kostya era building doing
doing some of the most difficult codecs.
JB maybe can talk about GoToMeeting 4
and GoToMeeting 5 and What? What's the
What's the good in that?
>> so so so like let's talk about this
amazing Ukrainian guy called Kostya who
was
at the time living in Germany and who
was in love with Sweden, right? He
And the guy was the most He He's like
like
like a lot of the people in the
community are very clever. He's one of
those who are like borderline geniuses,
right?
>> Mhm. He was able to reverse engineer
extremely complex codecs um
and he he does that and we do a a bit of
engineers with Kieran but clearly not at
this level.
>> No, no. Um he reverse engineered binary
blobs which are 20 megabytes.
>> Yeah, so just for reference
a 1 megabyte binary blob to reverse
engineer is probably
order of magnitude a month of work and
this guy is doing 20-30 megabyte blobs.
Maybe we'll talk about that in a minute
about the subtleties of how you do that
but this guy is doing it for very
difficult and very obscure codecs. And
and did that for fun, right? And And
um so GoToMeeting was a big problem with
VLC because it was that's what like the
number
number one
feature request for a long time so I put
a the
And the guy at some point said, "Okay,
JB, I'm going to do it." And in a matter
of
2 months. And then he explained how he
did it. He was just like, "Oh, I looked
at the code. Like, this looked like a
DCT that I used to see on WMV and so
on." He did that. And the
funniest part is that the code is
written is a ton of jokes. And there is
there is a ton of JB, right? My name and
and Kemp
and Kemp and Kostya jokes inside the
code. The code is beautiful, right? So,
one of the things I
I want to comment is
I got a chance to speak to some of the
developers, some of the
assembly language level people. And they
all always make everything sound like
it's kind of easy.
There's a a kind of humility
because I mean, maybe
just the level of what's required to do
this stuff is so high that everything
else seems easy. I guess is the lesson
to take away from that. So, in the
community, like some of the most
impressive people are the ones doing
reverse engineering. And the other ones
doing the assembly falls, right?
Um and
both of those type of people are
amazing. Um
x264, for example, became amazing
because of a guy called Lauren Merritt
who is was from University of
Washington, I think. At the time, yeah.
And who was like who made everything
great and fast doing a ton of assembly.
Um
yeah, so this is like the the the
golden era, I guess, where so many
things got done.
>> look at Kostya, for example, he looked
at the world as a binary specification.
He didn't need documentation or
anything. It's I have a binary and I can
figure all of this out. And and he
regularly used the phrase
binary specification. Ah, you know, it's
not a problem. And he went and he would
go away and he would come back and
he would do interesting stuff. Can you
actually speak to the details or any any
add color and texture to what it takes
to reverse engineer a blob? Yeah, so so
let's look at GoToMeeting for example is
a good one because
um I record a meeting uh on GoToMeeting
for example.
How do I play it back without needing
this GoToMeeting
player? There may not even be a player.
I may I may need to send a recording of
a meeting to someone that doesn't have a
player or whatever.
So fir- first of all there's a ton of
other stuff there. There's a actual
video conferencing client. You need to
go and find it may be easy it may not be
easy to find the actual module doing the
decompression.
You need a way to actually dump the YUV
data from the module. So often it
involves opening in a disassembler,
trying to guess where the hooks are
to incorporate that module and run that
module natively
to decode a sample file. So figure out
where this module is doing the decoding
process
and and find a way to hook in and output
the raw YUV data cuz you will need that
as a point of comparison for when you
actually do the reverse engineering cuz
you will need to be bit exact or in some
cases
close to bit exact.
And then you you open up your
disassembler
use a lot of intuition to go and figure
out, you know, where the DCT is, where's
entropy coding. There there is a kind of
>> [sighs]
>> not a rule book, but there's always a
pattern of some sort. Um for example,
GoToMeeting you know it will be a a lot
of screen codec tools.
There's also different variants. So
often I think there's what's GoToMeeting
4 5
>> 2 3 4 I think. 2 3 4 Yes. So I searched
here on Wikipedia. GoToMeeting uses its
own proprietary codec for all their
recorded sessions historically stored in
WMV files that require a special decoder
to play properly on Windows.
Without this decoder installed, Windows
Media Player and some editors cannot
decode the video tracks so you may only
hear audio or see a black screen. Boy,
do I remember that. But this is reverse
engineering that. This is key, right?
Because because the GoToMeeting is
something that not many people know
anymore, right? Well, you know about
Zoom and and Teams and so on, but like
now let's fast forward 10 years, 15
years.
And like this is a GoToMeeting.exe for
Windows 32-bit, right? Which is like,
"Oh yeah, but I'm on Android. I'm on an
iPad. I'm somewhere else, right?" How
are you going to do that? I'm going to
be on RISC-V, on ARM.
Those are blocked, but there are tons of
files we need to support for the future.
And this is why those type of work are
in
exceptionally useful for humanity. I
just have to say though, that reverse
engineering process is mind-blowing.
It's crazy. It's like
it's a kind of like
you know, I've been reading a lot and I
interview archaeologists.
I mean, you you just have so little
signal. Yes, yes, you know
over time you get so much experience,
you understand the structure of the
original code, so you can kind of start
inferring basics. Yeah. But you're like
a like like like archaeologist with a
little brush trying to reconstruct the
entire human civilization. Kieran is too
humble, but Kieran has done some reverse
engineering. Of of CineForm, yeah. At
the time um CineForm, nice. Yeah, at the
time before um actually led to the open
sourcing of that work um
So in parallel to doing the binary side,
you obviously have samples. In many
cases, you don't have many samples um
so you have to figure out what all the
different flavors are, and you may have
a So CineForm, for example, is actually
a collection of different approaches and
toolkits within that codec cuz often it
it grows naturally. And and the hard
part is finding the sample that gets you
kind of
somewhere to start without having to
implement 10 different other things. So
start there.
I think thankfully at the time I found a
sample by pure chance that had a lot of
flat blocks. It was animation, so that
really helped a lot because
it wasn't using particularly complex
coding tools, etc., and you could kind
of get somewhere and then and then build
up and build up until you go, "Hey,
here's a few bits here. I missed this I
missed this this if branch that it does
and go, oh." So, when we see samples in
these sample videos
>> Yes. And then and then you're tracking
trying to infer like what is this codec
doing
>> Yes. by observing the sample and then
looking at what at the at at the machine
>> What the machine code saying, "I I have
this byte is six. Take this branch." And
then a different sample, "Oh, it's
>> nuts, man.
That is nuts.
>> So, you see this is not. Then you go to
things like go to meeting. It's like
Mine was easy, right? Yeah, imagine
right.
>> two order of magnitude of more
complexity. A guy alone
somewhere in Germany doing that. Yeah.
And for a long time you work you're in a
black box. Because a decoder for a long
time because there is so many steps from
the entropy decoding, the intra
prediction, the motion prediction, the
IDCT and so on. For a long time you
don't see anything, right? So, you're
debugging purely in memory. debugging
guesswork. And you may have the buffer
that the coefficients are stored in
completely wrong.
And so you may be going down a complete
rabbit hole thinking it's this and then
oh, damn that's not that's that's
something else. And And you're doing
that on binaries that are tens of
megabytes.
Millions of instructions, right? So,
you're stepping through the debugger
like one by one, you know, instruction
by instruction going, "Hey, this
instruction changes this. This does
this." Pausing the program on the CPU
level, right?
>> Pausing it yeah on the CPU level,
watching what's going on, trying to
figure out
>> Sometimes you need to like be in a VM so
yeah, you can pause the VM. Yeah, pause
the VM, dump the memory cuz it could
some of the codecs could have
encryption. There could be um like uh
DRM on there.
So, you need to dump the memory from a
virtual machine. Like when I joined the
Ecole Centrale Paris in 2003
Jon Lech Johansen basically broke the
DVD specification and created DCSS.
Showed us how he was breaking a DRM
which was MP4 FairPlay from Apple.
What he did on his laptop, and I was
young, I was 21, was just like
mind-blowing because he was basically
debugging Windows inside a type of VM
with ex- like Wow. It's incredible. It's
mind-blowing and inspiring. Does it get
like from your experience and from what
you've seen in the community, does it
get discouraging? Does it get People
help you, people send you samples,
people are keen. Sometimes you don't
have access to an encoder, so
this is even more difficult because you
just you just ask and you have to ask
for samples. I remember VideoLAN used to
tweet for samples at one stage. Hey, I
need this obscure sample and
>> For a long time it was, oh, I need this
codec and I need this codec. And and and
if you were really lucky, you would find
like if you were un- if you were
unlucky, you'd get like one or two you
get nothing or you get one or two.
And then they would sometimes you'd find
a goldmine like, yeah, my company has
100,000 of these files cuz we're
dependent on it for some reason.
Um and so those are the those are kind
of the best if if because then they can
test bit exactness across
the huge range of coding tools.
Can you explain bit exactness? Bit
exactness, so um
most but not all video codecs
certainly from about the 2000s onwards
have a bit exact definition, so every
implementation must produce exactly the
same bits bit for bit in exactly the
same data that comes out of a decoder.
>> For like a large number of samples? For
a given sample. So Lex's implementation,
JB's implementation, and my
implementation of H.264 must match bit
exactly.
That wasn't the case in the '90s of
MPEG-2, probably fair to say
one of the biggest mistakes the video
industry made, and I think people who
were in the room in '92, I don't know,
most of both of us were in diapers, I
suspect, but
>> [laughter]
>> have acknowledged um I I would give a
shout-out to Yuri Reznik.
He's acknowledged that was one of the
big mistakes of the era. And you're
saying the encoders needed to be able to
run tests and then the the the bit
exactness.
I mean, that's a nice thing to
guarantee. Look, there's a parallel sort
of development here on
the way the web browser works, which is
a you know, takes HTML and displays it
and there's no bit exactness there
across the different engine. I would I
would point out actually FFmpeg is
unique in the sense that it's
it has been a winner takes all scenario.
You have Browsers is a good analogy
because it has to parse a lot of
different content and render it in a
particular way like a decoder.
But there still are multiple browser
engines. There's Firefox as one, there's
Chrome as one, there's a few Japanese
ones that are pretty decent.
That's not been the case in multimedia
in general um
across a wide range of codecs. FFmpeg is
kind of
won it all I suppose in the sense
because of because of the fact that you
can get
every new codec added is actually worth
more than the value of that codec itself
because it makes the whole thing better.
Man, this is really cool. Uh going to
Perplexity, Yuri Reznik is a multimedia
signal processing researcher.
Got his PhD in computer science from
Kyiv University with over 150 papers and
more than 80 granted US patents.
Contributor to major multimedia
standards including H.264, MPEG-4 AVC,
H.265,
uh MPEG-4 ALS, G.718.
>> G.718 is telco stuff. Telco. And so he
was more connected to company
>> Real Video, right? That was
>> Yeah. Oh, yeah.
>> Very important that I thought. XenCoder,
Brightcove, Context. This man, I need to
hang out with Yuri. He's legit.
>> Yeah. And he's like one of the most nice
person ever, right? Like like for
example for for my for my startup that
I'm doing right now called Kaiba, right?
I met Yuri because I met him every year
at the Mile High Video conference, which
is in Denver.
And he would he gave me like so much
good ideas and good things. He's like
really amazing person. He tell he tells
us how how you know, how great it is to
be you know, even know us and then he's
just like you know, you look at that and
I think it's
I think it's the other way around, Yuri.
That reminds me of a thing that you
mentioned to me about fate testing and
like the insanely rigorous process
that's used
to test everything that's incorporated
into
um into FFmpeg. Can you take me through
the testing process? Yeah, so FFmpeg has
a system called fate FFmpeg automated
testing environment. Because FFmpeg runs
on so many different OSs and can be
compiled with so many different
compilers,
there's been a crazy number of
configurations. So, you can see the
absurd combination of um
compiler variants, operating system
variants, instruction sets. You can see
at the top Mac OS has tons of different
variants because it has iOS, it has
tvOS.
>> I'm looking at a page fate.ffmpeg.org.
81 minutes ago, 76 minutes ago. Looking
at the different architectures, the
operating systems, different compilers,
Apple clang
version
combinations of the combinations is
saying this
>> are all run by volunteers. So, these are
all volunteer systems. The ones at the
top, for example, the Macs, I host in my
office, for example.
Uh host all sorts of different stuff.
Other people host other things. So, it's
really there to make sure because FFmpeg
does quite complex C code, for example,
you do have miscompilations. So, the
compiler will sometimes compile C code
incorrectly, for example. This happens
once in a while.
Oh, there's like there's a log of all
the compilations. Yeah, log of all the
compilations. All the tests. I think one
of the other ones will show all the
tests passing. If you click, you can see
all the tests.
back
All tests successful. And logs test,
yeah.
So, you see all those tests are passing
of all the different codecs, all the
different filter transformations.
All the
The level of scale is is quite crazy. On
all the combinations, it's it's not just
a matrix at this point. It's like a
pivot table of different combinations.
As nerds. And it's a key part of what we
do because you you may be able to test
something locally, you make a change,
but actually that breaks
GCC version 11 on Mac or something like
that, and you're able to then fix that.
We also have miscompilation. So, the C
code sometimes the compiler can have a
bug in it where it creates the wrong
output.
And that can have quite a big effect
sometimes on a video on a video because
of the way frames have dependencies,
even a small change in the output
can can cascade to actually quite big
glitches. You see PowerPC,
you see RISC, you see ARM.
>> There was RISC. There was weird stuff in
the past like DEC Alpha.
You see Visual Studio, different
versions of compilers.
>> Intel compiler, Apple clang, you name
it. What are some of the pain points?
Like maybe do you have emotional
triggers?
Uh maybe nightmares about a particular
operating system, a particular container
coder combination? For me it's really
easy because um so I have a day job. Um
my company builds
the company I started builds um
equipment for broadcasting sports
matches between TV stadiums and studios,
for example.
We have to work with 10-bit video, and
10-bit video has um a set of challenges
that
you can't process 10-bit data natively
on a CPU.
So, that means you have to stick it in
um 16-bit.
So, that means you have six wasted bits.
So, there's different packing formats to
actually pack the data more efficiently
because when you send that over a
network,
you lose cuz you need to you need to
save that 40%, for example, on PCI
Express you may only have bus bandwidth
to do that. And so, I think internally
we have about Some some are some are
industry ones and some are internal to
our own hardware that we build.
We have a I think a 5x5 or 6x6 matrix of
every single format to every single
other format conversion. In fact, one of
one of them I sent you and they're all
written in handwritten assembly and
they're all written and they all support
different CPU generations.
So, this is really traumatic handling
all these different combinations
times a million. But, with the company
you're talking about is Open Broadcaster
Systems.
>> no relation to the free OBS streaming
service.
>> Yeah. Yeah. But, JB and I have started
companies
broadly speaking around the FFmpeg VLC
ethos. So, that's really low-level work.
So, so in most companies this this
wouldn't be written in assembly. It
would be accepted that C is C is fast.
Um as you can see from that, C is not
fast. Uh so,
here it says [snorts] 62 times faster
than C.
>> Yeah, so it's taking those the ethos of
doing low-level programming, real-time
programming
and take using that for commercial
applications. And JB and I have started
companies around that, in many cases
hiring developers from the open source
community
to use that ethos. And and so, that
that's a great example of of
some of the things we're doing. In most
companies it would be said, "Oh, I'll
write this in C and it's fast and we're
done." But, actually you can get a lot
better. For me, like some of the
headaches we have is around
some OS that are difficult to support,
right? Because um
if you look at VLC and thanks to fate
and FFmpeg, we run on the light version
of VLC runs on Windows XP
and still runs there and runs on Windows
11.
Um we work on Mac OS 10.7 to the latest
Mac OS, whatever it is, right? 26.
Um we work on iOS since iOS 9. Well, we
are actually iOS 26, right? We support
um
we support many types of Linuxes, BSD,
Solaris.
The last version still runs on OS 2,
right? Like there is maybe 10 users of
OS 2 in the world and one of them is
maintaining VLC. Then you realize that
this very small team around VLC and
using FFmpeg codecs and and all the
other ones support more OSs than
Microsoft or Google or Apple and they
have infinite amount of
of power and resources. But for example,
the worst is iOS.
For in order to build on iOS 9, we need
to do some very clever mixing of several
version of the Xcode ID and SDK from
Apple from several version and do a type
of Frankenstein version of that so that
we can still support iOS 9, which is not
supported at all by the the compiler of
of Apple in order to still run on arm 32
on iOS 9 and you've seen on faith that
it was still supporting iOS 9, right? So
my headaches are mostly related to the
the support of so many OSs and it's
important because like we receive so
many people saying, "Hey, thank you. I
still have my iPad 2 to watch movies and
it still works on iOS 9, right?" And
it's also an impact of like not forcing
people to buy new hardware when it works
fine. If you optimize it correctly,
which brings us to what we were saying
about assembly. It's also fighting like
the fact that you need to buy something
new non-stop while you could optimize
more, which is
a lost art.
You got to tell me about this lost art.
Or this
the carriers of the flame of assembly.
What What is What What is assembly? Why
is it beautiful? Why is it challenging?
How does it work? So when you write
assembly code, you write this using the
instructions that actual processor is
using directly. So most of the time you
would write in a language let's take C
as a good example. The compiler would
use that to create
assembly language and machine code
instructions for you based off your C
code.
And there's a specific flavor of
assembly that we use in FFmpeg that's
called SIMD SIMD single instruction
multiple data.
So this means for example
say say I want to add five to a number
in scalar assembly. So this is what's
known as you work on an individual
element. So I want to have a number of I
have the number 10 and I want to add
five. I use the add instruction
and I add five to 10 and I get 15.
With SIMD with SIMD I can have a whole
vector of 16 different numbers that
could all be different.
If I want to add five to that I can I
can run one instruction
and that one instruction
sums all 16 elements.
And that as you can imagine lends itself
very well to video video video is you
know a pixel grid. So I can perform
operations on multiple pixels at the
same time.
The key thing that we do differently in
FFmpeg is we don't use any abstractions
or any major abstractions on top of
that. So
there's a part of the world that uses
what's known as intrinsics. So these are
C functions that behave very similarly
but not quite the same to writing
assembly by hand.
So the registers that data is is stored
in
on the CPU the compiler allocates those
for you.
And so the key thing to understand is
when we write SIMD is we have
a 10x and not percentage 10x to 50x
speed improvement. That that function is
62x That's nuts. on the FFmpeg account
as you know posts and tweets a lot about
that to try and say hey we're doing this
stuff. You are a person who sees the
beauty in assembly but it's also
extremely useful for these kinds of
application to actually significantly
outperform even C, which is crazy. It is
necessary.
>> Yes. Because like one of the projects
that we need to talk about is called
David, right? So, David is a decoder for
the format
that was done by Alliance for Open
Media, which is an video decoder called
AV1. So, for people who don't know,
we've been talking about H.264, AV1 is
another hugely popular standard and
codec that is increasingly taking over
the internet. And when this format was
launched, many people said, especially
even from the Alliance for Open Media,
right? Which is Google, Netflix, Amazon,
Mozilla, they say, "Well, this format is
so complex, it must be done in hardware
to do the coding, right?" And well, I
arrived with a few other people, mostly
Ronald, Henrik, and Martin, who said,
"We need to have an extremely good
software decoder
because it's going to take time to have
hardware." And so, we wrote this
project, which is beyond insane.
We are talking about 30,000 lines of C,
but 240,000
lines of handwritten assembly, right?
Handwritten assembly, 240,000
lines.
That's incredible. That mean I mean some
of the stuff we're talking about is
probably the biggest assembly
code bases. To give you an idea, and
Karen can correct me, but I think that
FFmpeg has 100,000 lines of assembly for
all the codecs.
>> All codecs. And just this one has
240,000.
It's a video on project, of course,
and
it is optimized
at the maximum because the motto when we
starting the project is every cycle
matters, right? Every cycle matters
because David is used in VLC and in some
software AV1 playback stacks. We are
talking about probably 3 billion devices
which are going to decode video non-stop
because for example 30% of the video
from Netflix are now in AV1, 50% of
YouTube, right? So and you often don't
have your hardware decoder because not
many devices have hardware decoder. And
with David we realize that with one or
two cores you were able to decode 720p
correctly. So it is like literally
incredible, right?
Yeah, so this is
another spicy tweet from you. This is
what peak video codec should look like.
79.9% assembly, 90.6% C and 0.5%
other. And what's incredible is with
those tweets, which is factual, people
get
crazy. They are unhappy, right? They say
For years for those two years they go
crazy. No, intrinsics is fine. The
compiler is Oh, they go You cannot
optimize your compiler auto
vectorization. It's your fault. You
don't understand. And we've tried that
forever, right?
>> For two years and two years later
showing
hundreds of examples of of handwritten
assembly. No, no, no, you're doing it
wrong. The compiler can do this.
>> So we we should actually just articulate
a little clearer. So the intuition there
from the software engineering folks,
when you have code like Okay, let's just
take an example, C++.
There's a compiler
that's doing a lot of the optimization.
Yes. And the assumption is if you have a
good enough compiler, if you continue to
improve the compiler, you're going to
generate code
>> Yeah. that can perform like optimal
performance. You cannot possibly beat
it. And you're consistently challenging
that thought that if you
>> By orders of magnitude. By orders of
magnitude handcraft assembly can
outperform
See, the two things that they tell us is
yeah, but modern compilers have auto
vectorization, right? Because SIMD is
what we're doing is vectorization. And
like it's not even close, right? It's
not even close, right? It's not like 5%
10% slower. It's multiple times slower.
So can we I don't know if you can say
something philosophically cuz there's a
lot of there's a lot of great software
engineers, great engineers, great
machine learning people. Karpathy will
listen to this and say what's the
intuition he's supposed to get from
this? What are we supposed to Karpathy
learned assembly because of the tweets
by the way. He just He
went He's like I think this is a
movement. Let me figure out what's
happening here. And and you know the way
he documents his work and so
Philosophically, what's important to
realize is that we passed the time where
hardware was going so much faster,
right? We're at the end of the Moore's
law. We have limitation for
for AI, for memory. You need to go down
in the stack and optimize more to get
more power from what you have because
request for power, CPU power, GPU power
are exploding while the hardware is not
exploding in
speed, right? So you what people do is
that they add more cores, right? But
that's basically like at some point you
cannot add 250 cores, right? So what we
do is to take every inch of the machine.
Not just that not just that we we abuse
the machine. We we we go and use we use
the machine in ways that the
that the creator didn't expect.
Sometimes we use an instruction that's
completely unrelated to what we do. We
use a cryptography instruction in video
processing to do nothing related. And
one of other things that we do for
example in David, which is a bit crazy,
is that we don't use the function
calling convention from the operating
system. We should explain that. That is
extremely complex, but basically usually
when you do move from one function in
code to another, there is a way to save
the registry, the state of the CPU to
enter another function. Um and this is
like standard. It's a bit complex. I
would I would simplify this a bit. So,
So, David does things to abuse the
calling convention. You could define the
calling convention as
I've written a function and I want to
call another function. How is the data
shared between the functions? Cuz
there's a convention what's known as a
calling convention. And what David does
for optimal reasons is
create its own calling convention
sometimes. So, if I want to call Lex
Fridman's library, we got we've got to
agree on a convention so that I can
share data with you in the assembly
language space.
And one of the challenges in assembly is
every operating Well, not every
operating system, but there are Well, at
least four that I can think of on x86.
Linux 32-bit, Windows 32-bit, Windows
64, Linux 64.
They all have their own calling
conventions. And so, one of the amazing
things Lauren Merritt did, who we talked
about before, was create a very
lightweight abstraction layer. So, you
could write your assembly code once and
it handled all the calling convention
stuff for you.
Which is always a problem because you
had to manage four different variants.
But, David takes this even further. For
speed reasons, it does its own calling
convention um within itself
to bypass the kind of rules the rules of
the rules of sort of of functions and
say, "Okay, actually I'm going to call a
function this way because I know it's
within my library." Does that have to be
special to every single operating
system? Well, if it's custom, no. But,
the the the challenge is
in general, yes. And in terms of in
terms of each instruction set. So, the
thing to always emphasize is
we do this on every instruction set. So,
every instruction set has its own
handwritten assembly.
Which is even more crazy. And that that
that has um
that matrix has got bigger in recent
years because of RISC-V, because of
ARM 64, because of the new SVE, there's
SME, X86 has AVX-512, AVX. So, we do
runtime processor detection. We see what
the machine FFmpeg is running on or
David is running on is capable of
because you could be on a laptop from
2008 where this isn't there. Runtime
detection, we set function pointers
accordingly.
And then from then on
off you go. Or you could be on a machine
with risk five. Yes. And in all that, we
don't even respect the calling
convention of the operating system in
order to be faster because we know that
we are going to be called from within
our binary. So, we can share data
without saving all the registry in the
common way because that can lead to
loading and saving registry on the L1
and L2 CPU and gets us faster. So,
that's why I said that understanding
CPU architecture, computer architecture
is key. And this is also why it's
handwritten. I don't know anyone I've
never hear any other project than David
doing that. This is what Kieran calls
the calls it an art, right? It is an
art. I think I think in the in the mass
world there isn't something on billions
of devices. I know there are some
specialist industries. I know in high
frequency trading they could take this
really seriously where they're receiving
feeds from a market and they need to
react within X number of microseconds
and so the instructions matter. But
that's not a mass, you know, a mass
produced thing that's on a billion
devices. That's hyper specialized
running on hyper specialized hardware.
We're running on all hardware from Sorry
to linger on it. But like that's a
really counterintuitive, almost like
revolutionary
idea here that there's a huge amount of
value to assembly. Like what are we
supposed to take away from that? Like
what, you know, there's a bunch of
people listening to this
they're basically like, sorry, from
myself included, you know, I I
programmed for many, many years in C C++
going up to standards of C++. Found love
with C++ even meta programming and so
on. And then transition more and more
because of machine learning about 15
years ago to Python. And so like for me
in this Python world, JavaScript world,
now vibe coding where I'm just using
natural language sitting in my jacuzzi
drinking a drink and just talking to the
computer.
Like like
record stops. Why is the value to go
back all the way down to the low level?
Because you can get more power per
dollar invested, right? And sometimes
it's going to be a problem that is
limited by your hardware.
A good analogy is what you see in
quanti- quantization in in LLMs, right?
And people are doing, "Oh, I'm going to
do that in FP8 or FP FP4 or some some
crazy things like Microsoft fee who did
in 1.5
because you're constrained by memory,
because you're constrained by the
machine you can run, because at some
point we are doing real time and I
believe this is going to happen on AI
inference also is that at some point you
need to get faster and you cannot always
get harder
more powerful hardware, right? So you
need to analyze code and see where like
where is the mission critical, where is
the things that are called non-stops.
And for example, David is a good
example. It's going to be run billions
of hours per day. Yeah. That makes
sense. It doesn't make sense to be on
the glue of FFmpeg CLI. It makes sense
over there. Yeah, and this has to do
also we'll talk about it more, but your
new effort, your new company Kyber is
doing that kind of thing for ultra low
latency. So the slogan being every
millisecond counts. So when you actually
extremely highly constrained in some
dimension. We are also arriving at the
point where we've done
so many great things, but the hardware
is getting back to us, right? Because
cost is increasing because we need more
power. And so you're limited by either
your CPU, your RAM, or your networking.
And you need to optimize, and this is
where
value is going to be. Especially because
like doing AI is going to help do the
programming of like business, right? And
so the core thing that you will not be
able to write code are optimization for
the hardware to be as fast as it
possible.
I'd love to talk to you about who and
how
should learn assembly. But first, I
think we need a bathroom break.
Quick 10-second thank you to our
sponsors. Check them out in the
description. It really is the best way
to support this podcast. Go to
lexfridman.com/sponsors.
And now back to the episode.
All right, and we're back. There's this
nice repo with the assembly lessons.
First of all, do you think developers
should learn how to program in assembly?
And how would you go about learning it?
What is
this ASM-lessons?
>> So, I personally wasn't happy with the
way assembly is taught in books and
online
cuz it's very grammar-focused, and you
don't in general learn a language from
learning the grammar and the structure.
You learn a language by
asking someone what their name is, and
you start from there, and you go and
solve real problems that you have when
you want to communicate. You don't learn
sentence structure. This is the
interrogative and the adverb. And all
all the assembly books seem to be doing
like like going through every
instruction, even ones that aren't
really relevant,
explaining what they all do and how they
actually doesn't really change much. So,
And the other problem that we have in
our community is assembly is taught sort
of hand-to-hand, like person-to-person,
like blacksmithing one by one. That's
That's the only logical sort of analogy,
and that doesn't really
scale online. It doesn't do other
things. So this this this
this I started a set of assembly lessons
in the in the way it's done in FFmpeg
which is a little bit different to the
way
assembly in general for I don't know
trying to think the other good big use
case of assembly is in embedded devices
in really really low power cheap devices
and that's completely different to what
we're doing here.
Think it would be good if you could
highlight the requirements which are
quite simple. It's high school
mathematics and C. And actually not even
C really really is pointers. To
emphasize yes we've talked about how
brilliant this stuff is
but high schoolers like Daniel Kang have
written um
assembly in FFmpeg. I think there's been
contributions because of these lessons.
So it's really about
trying to to get this dying art to
continue because we've shown it's
possible with David to produce something
amazing. Mhm. There's still a lot of
codecs in FFmpeg that are only maybe
partially assembly
um assembly optimized.
And so it really it really starts with
basic and continues explains a lot of
the jargon a lot of the syntax.
It doesn't really try and explain to you
you know
interrupt handlers and interrupt
instructions and all of these different
jump targets actually makes this really
vector focused. And uh describes all
kinds of registers uh general purpose
registers vector registers
uh really nice examples.
Oh this is cool. It's a classic yes
classic example of FFmpeg but um
some of this assembly language is is is
really beautiful and I and I think it's
beautiful because it's kind of like
flying a Spitfire. It's really
aviation at its purest but also pushing
the aircraft beyond what the designer
thought was possible. So we're abusing
for example sometimes cryptography
instructions to do certain things and
there's a level of
beauty and art where
it's really you and the processor. Mhm.
There's there's there's nothing in
between. It's you and the the the
joystick of the cockpit and you and you
you move that joystick and it's
physically connected to the ailerons
and you can push that plane beyond what
it can normally do and that there's a
level of
yeah, beauty and amazingness to go that
but
I don't think
the sort of person by person assembly
that is that someone taught me and I've
taught multiple people is going to work
long run
as because of the particular flavor and
the way that we do it. It's literally
now I should
I was going to say wizards handing it
down. I realize I look like [laughter] a
wizard wearing this hat. But yeah,
basically just like the sages the wise
sages handing down the craft. Can can I
ask you about LLMs? Like can they help?
They had more of an understanding than I
expected but they are still
I've asked it questions and it still
goes and
starts hallucinating not hallucinating
but making modifications and then I go
is it bit exact? No, fix it and then it
just goes and does the same thing and
it's going it there isn't the corpus of
information like Stack Overflow to work
on. There is not enough data to train
on.
Um and this is the biggest issue. Um I I
started my career actually doing some
uh assembly for Itanium, right? So the
Itanium is a dead um processor type,
right? Which was done by Intel and HP a
long time ago when they wanted to do
64-bit
well, they lost and then we got AMD who
did it AMD64 which became x6 x64. But
Itanium was extremely interesting in the
sense that um those were processors who
had a ton of computing power to do
floats, FMAs, which is similar to what
we need now for for LLMs, right? And you
could pack three operations per line
that could be loaded. So basically you
had an output of basically 6 billion of
operation per second but the bus um
the memory bus only allowed 1.5, right?
So, you your CPU was four times faster.
So, you had to do crazy things to to
pack things in memory, reuse the
registered, and those type of semantics
no language could do that, right? So, um
like I I
I have the Itanium programming uh book
because Intel did amazing books, but
that's exactly what Kieran says. If you
don't know what you're
you you're going to do, it's impossible
to read, right? It's a ton of jargon and
so on. While those lessons
are amazing because they are targeted to
real problem, and you can do it
yourself. People have. People have that
patches and they said, "I studied your
lessons and here's my first changes."
That's amazing.
>> And
part of that um in the lessons is is a
framework called x86 inc written by uh
Laurent who was working on x264, and it
allows you to do more things about that
to create a type of like uh not caring
too much about different calling
convention, and
we had a lot of students who uh
gave code to x264 using uh that a long
time ago, right? So, it's really doable,
and I believe it's um
necessarily to understand uh
assembly language even if you don't do
it much to understand what's going on
inside your computer, and that will make
you a better programmer. And I assure
you that because doing that you will
understand some of the architecture of
the memory inside your your computer,
right? Understanding register L1, L2,
L3, RAMs, uh SSDs, disks, and so on, um
which are very important because then
you have a good programming culture that
will make you a better programmer. Uh
what do you think about the Rust
programming language? Cuz that's a bit
of a meme. We have very different
opinions with Kieran.
>> I think it's valuable what they're doing
in terms of memory safety as a concept.
Can it achieve this some of the speed up
that assembly achieves? Uh not not
assembly by hand, no. I think that
that's a given. C potentially, but I see
it very
it has a very big Esperanto vibe about
it. It's like we're going to solve this
and
we're doing this in a particular way.
Meaning it's a bit too utopian? There's
a lot of focus on the self-importance
rather than than solving real-world
problems. It reminds me of the Sinclair
C5. Sir Clive Sinclair of Sinclair
Computers built a car
and he said, "Oh, everyone will be
traveling around in in a one of these
electric cars." And it was um
it first reminds me of that where
I think the community doesn't the
community doesn't quite understand that
in order to get people to move, you have
to build something that's as good as if
not better than what you have now.
Um yes, people are doing Rust rewrites,
but if they're
if they only if they only do 85 90% of
the feature set of what
what we need, like things like core
utils, that last 1% takes 99% of the
time. Um to to use Elon's famous quote,
"Prototypes are easy." Like this kind of
stuff is easy, but this to get a real
electric car, you have to make a car as
good as if not better than what we have
now. And Rust isn't in that stage yet. I
think we I don't think anyone would
object to seeing
Rust code in FFmpeg,
but it needs to work as well and support
the same unit testing as everything
else. It needs to be flawless. It can't
just randomly break. They can't just
randomly break ABI when they want to. It
needs to
it needs to have I think more I think it
still has only one compiler
implementation. Yes. So,
it's got to be as good as if not better.
And saying, "Hey, here's my utopia of
memory safety." isn't enough, even
though we we probably all agree that
that's the goal.
So, um I've done a ton of Rust. And the
two major topics I had was adding Rust
modules inside VLC. One of the reasons
VLC got popular um and which was one of
the main architectural decision is that
VLC is a very small core and a ton of
modules, right? And so, you can write
modules in C, in
C++, in Objective-C, and anything that
is basically interoperable with C. And
and and so, we we we did some Rust
modules. And so, I have experience on
that and and I wrote some of it. And
also, like my my new startup called
Kyber is an open source project
mainly done in Rust.
>> [snorts]
>> Um what Rust is extremely good in in the
sense that
um
it's a better C++ that cares about
memory and allows you to do things about
memory ownership that no one else can do
so far.
>> [sighs]
>> However, it's great when you start a new
project from scratch and you do
everything in Rust. But it's very not
good when you interop with existing
part. And some part of the Rust
community believe that they need to
rewrite everything and everything will
be better with Rust. And and the answer
is like, no. Like, I'm almost always in
all my
years of being engineer, manager, CTO of
startup, and so on, don't rewrite.
Right? Is that that's the that's the
initial instinct for a lot of people
when they show up to a code base,
probably before LLMs, is like
probably because they don't understand
the the the wisdom of the way things
have been done in the past to say,
"Well, we need to rewrite it." Hence why
there's a thousand JavaScript
frameworks. But the reason is the
following.
And this is very important to
understand. It is an order of magnitude
easier to write code than read code.
Yeah. And you see that also with LLM,
they can write code, they analyzing is a
lot more difficult. And so, when you
arrive and when you arrive to a very
complex piece of code, right? You you
don't understand it, right? Um because
it's so much more effort to understand
the code from someone else because you
don't have the thought process.
Um,
and often I joke about um,
some some languages, mostly
Pearl, for example, um, which has very
complex syntax. And imagine I am at my
maximum intellectual efficiency in
programming, right?
And I do write the best code ever. I
will not be able to understanding myself
6 months later, right? Because reading
code is more difficult. So,
very often you arrive, you don't
understand all the wisdom, all the
business logic, the reasons that were
done that is maybe not documented. And
you say, "Well, I'm going to write it."
And the thing is, no, you don't, right?
Because that's as Kieran said, right?
"I'm going to rewrite core utils in
Rust." And then, of course, you arrive
very quickly at 80%, um, then 90% takes
a bit more time, and then you got the
last ones, right?
On the other side, right? So, for new
projects, it's great. Everything related
to parsing files, uh, networking, uh,
because of the memory, uh, checker,
borrow checker, it's amazing, and there
is nothing else.
To answer a bit differently for us,
imagine I take a piece of software like
a David or H.264, right? Which has a ton
of runtime in assembly, right? Um, I
rewrite the C part in Rust, right? So,
it's more secure. Yes, but then you
arrive into the assembly, and you can
jump anywhere in the memory because we
are doing handwritten assembly. So, even
if I rewrite the C part in Rust
for security reason, you you break
all the security when you you write
handwritten assembly because we can jump
anywhere.
So, in my opinion, we need to do
something that is,
um,
secure assembly, right? So, which is
compile time check the assembly, which
is similar to the check assembly project
that we're doing on on David and his
2612 with VideoLAN is
to start
instrumenting your assembly at compile
time to check that it's not jumping
anywhere in the memory because else you
might rewrite a part of C in Rust. But
if you want to have the same performance
as you're going to have inline assembly
and so you destroy your whole security
model.
Um so that's a bit what I think about
Rust. Uh I just want to I I would say on
a personal level I'm so in awe about
this assembly. I actually
once in a it never gets old the speed
improvements to show 62x.
Uh so there are months put on a personal
level I I run our internal test suite at
work and just see I'm still in awe at
the gains we have.
>> There there's a source of joy and
happiness with programming for different
reasons
but I think one of the
>> [clears throat]
>> greatest
happinesses is in the optimization of
code and it sounds like you're like at
the cutting edge of that. Oh, that was
cool. In the community I want to speak
about two people who are
wizards of assembly, right? The two of
them are actually working living in
north of Europe,
Sweden and Finland and um
Henrik Gramner knows so much about
Intel x86 assembly that when we ask
questions at Intel about things they
tell like why are you asking us Intel?
You have Henrik. Henrik knows better. He
knows all the cycles of almost all the
SIMD instruction by all the CPU
generation. Oh yes, this is a P4, this
is a Nehalem, this is a Core 2, etc.
That person is like the best person on
assembly in the world and he's the
nicest person that you've seen like very
He arrive you don't see he's amazing.
And the other one
is is called Martin Martin Storsjö and
he's the doing mostly the same on arm,
right? So, neon, right? And iPhones and
Androids and so on. And he codes in
assembly
on his phone
editing it with the crappy
keyboard like virtual keyboard you have
while watching his kids play in the
playground, right? Like like this is
just like wizard level. So, those two
people are like
So, a part when you're programming
assembly at that high level, a part of
that is knowing the architecture that
you program on. So, x86 On arm in
particular, yes. Arm in particular.
But x86, I mean, these are complicated
architectures, right? Yeah, but um
in some ways it's more x86 with out of
order execution is not so bad. Arm, you
really need to understand all the
different generations of arm processor
cuz they're all different.
A72, etc. etc. And there's the Apple
variant, there's this variant, there's
that and you need to write code that
works
efficiently on all of them. x86, but
broadly speaking, you have Intel AMD,
you have sub variants, but
generally speaking, there's
something fast is going to remain fast
on all of the variants. Whereas in arm,
it's a completely
much more complicated ball game.
We are taking a non-linear journey
through history here, but we were
talking about Michael Niedermayer.
And I wanted to ask
about this. For a time,
there was a split in FFmpeg and
a libav. Yes, so um
in open source projects,
um
sometimes you disagree, right? Um
>> [laughter]
>> That's such a nice way of putting it,
yeah. And the good thing is because of
the license, you're allowed to basically
do your own, right?
Um and this is normal and this has
happened all the time, right? For at a
point there was a GCC at the time of GCC
2 and EGCS, uh which became then GCC 3,
right? There is what we told KHTML with
WebKit with Blink. Um it is a same
process. And also like when I want to do
a new feature today in VLC, I fork I do
my thing on my own and then I merge back
to the community. So there was a a split
in the open-source community on FFmpeg,
which become Libav and FFmpeg. And after
a few years, well, the community merged
back and people moved on. It's a bit um
drama that is normal in open-source
community, but forks are even
they're important because they they they
change the statute quo of a community.
Um um
not talking about FFmpeg
and and and Libav here, but uh the GCC
fork made GCC a ton better because the
some people wanted to change the
architecture fundamentally to make it
faster. And of course, it's always
question of people and so on, but in the
end you realize that
FFmpeg today is better than it was uh
before the fork. Um and now, well, we're
back all together, right? And I spent a
lot of time in in Camden say uh in the
in in the community. Um it's not often,
to be honest, uh very well explained
because a ton of the reasons are not
very public. Uh but I think that's
that's normal and that's good. Yeah, I
mean, you're making it sound really
nice, but there there is bad there's
pretty heated battles inside open-source
projects. I mean, it is a very
passionate community and you're kind of
in a distributed way have to define the
direction of things. So here looking at
uh Perplexity, FFmpeg and Libav split in
2011 mainly over project governance,
leadership style, and development
processes, not because of a fundamental
technical or disagreement.
Uh FFmpeg effectively absorbed Libav's
work
while Libav withered and most
distributions and developers went back
to FFmpeg. Yeah, that was a that was a
weird that was a from a user's
perspective that was a weird experience
cuz you know, I'm a Linux user so you
know, whether it's Ubuntu and so on all
of a sudden I think for for a
for a little bit Ubuntu I feel like am I
remembering correctly switched to Libav
12.14 something like that. Something
Yeah. And then they switched back to
FFmpeg. I was like, what is happening?
From
So on the sort of you you get the feel
the ripple effects of the different
internal debates that are happening. To
be fair on Apple when you type GCC you
get clang like they did something like
that as well. So Yeah, so
to me it's like
the fork was like heated drama but
most of the development from Libav was
merged back into FFmpeg, right? So the
facto FFmpeg got a
a super set around Libav and so that
gave the user because in the end we have
to use for the users
a larger set of features and a ton of
things that were um
discussed. For example, the debate on
reviews and on how we push are something
that now is completely settled in FFmpeg
and is following mostly what
everyone in the community agrees, right?
So the facto everyone who was active on
Libav came back in work on FFmpeg
because
the disagreements were fixed and in the
end FFmpeg is stronger than it was
before, right? And
I know people love drama but um
Well, my my main concern I I understand
I think looking at the
the long history it's all
for the good.
But I do I am concerned because there's
so few humans
that are critical to the success of open
source projects, that I have seen it uh
be a psychological toll on folks.
And, you know, sometimes leads to
burnout. So, you have these incredible
people that are at the core of open
source projects. There's a moment that
happens cuz like what is the motivation
of doing it? Ultimately, it's because
you're passionate about it and it makes
you happy. And at a certain point, you
wake up and it's like this has been a
bit too much
heat from the drama. So, like at the at
the project level, the project continues
and often flourishes. But, sometimes
there's these individual humans
that are just like, I've had enough.
Yeah, but it's not just about folks,
right? So, it's a very what what you
what you are referring to is a one of
the most challenging and most
interesting part of open source today is
maintenance
burnout, right? And AI is a problem
because of that. And Daniel Steinberg,
which she's the maintainer of curl,
who's probably one of the
best promoter of open source in the
world. He's, by the way, a member of the
European Open Source Academy with me.
So, I'm very like humble to be on the
same community as him, right? He's
against what he called AI slop, right?
Because it gives a ton of
fake reports or bad reports, bad
patches. And then, a lot of maintainers
have a lot of burden to maintain the
software.
And this is straining the
the mind of open source developers much
more than folks. And for example, the XZ
fiasco was because there was one guy
maintaining it and he got basically
hammered by two attackants who were
asking him questions non-stop at weird
times at night to block him and at some
point he got fed up and said, "Okay, I
can't do that." and gave the commit
access to the attackant. Um so,
burnout in open source community is
something that exists,
but mostly it's about maintaining
things, right? No, for sure. Well, I I
wonder how we we help that cuz those
people are so important. You know, the
human beings are so important at the
core of these projects. So, so for
example, now I am maintaining a ton of
multimedia and non-multimedia library as
maintainer
because the maintainers
got fed up, right?
Someone video and someone outside of
video and
because it's sometimes you need a
tough skins, right? Because you get like
it's not really attacks, but Oh, this is
not working. This is not working. And
you feel it personally.
And this is also why resources or the
the Google fiasco is was a problem,
right? They don't realize that in the
end you have
you know, it's like the same graph where
you see like everything and it's just
like one random open source project that
is maintaining the whole
>> guy that did it. internet you see the
one, right? The Yeah, this is the meme.
I mean, it applies to to a lot of open
source projects, but this is
the all modern digital multimedia
infrastructure and then that thing at
the very bottom that everything relies
on is FFmpeg. It's true. And then
there's usually like, you know, a
handful of folks that are maintaining
that. And FFmpeg or VLC, right? You have
a community of 10 15 core developers are
not the worst open source project. Exe,
which is even in more installations, is
one person, right? There is one guy
libxml is Yeah, libxml, right? There was
a big stop. No one is maintaining libxml
anymore, which is like pass the only
library that is able to pass XML
everywhere.
>> All the crazy edge cases of XML under
ridiculous circumstances and they get
attacked by security researchers because
there's one other crazy edge case that
they haven't thought of. And they say,
"Yeah, but
the body of knowledge to actually
resolve that is massive."
There is one guy maintaining all the
time zones for everyone who is in the
middle of I think was it Nebraska or
South Dakota? Like the mental health of
the open source maintainers is something
that large corporations don't care or
don't see, right? It's just like, "Oh,
yeah, I'm just doing an open source
report and so on." Some of it is
financial, but some of it and people
should definitely support open source
financially all across the board. But,
some of it is also like spiritual on a
basic human level. There's something
that happens
like with this image of a of a FFmpeg
and so much of the internet depending on
it where people almost like talk down to
the folks who are carrying these
projects forward and maintaining it.
>> security community, they certainly did.
That was one of That was one of the
things I think that argument came out is
there was there was a portion of the
security community that said, "No, these
guys write crap code. They need to fix
their crap code." I'm like, "No, no, no,
no. This is a guy's hobby project
You've You've have a security bot that's
gone found some AI generated stuff. That
guy didn't write crap code. It's just
an edge case to the 99.99999%
he didn't think about because it's his
hobby project decoding Star Wars games.
>> aspect of it. It's It's just hard work
and it's It's beautiful and the right
approach there is to celebrate people
for doing incredible
incredible work. It's It's It's just
incredible that humans step up Sure. not
really paid at first or maybe ever and
then they're doing it out of the love of
it and we need to like human
civilization runs on people like that.
We need to celebrate them.
>> To give you an idea, I received death
threats on VideoLAN, right? And You
mentioned that to me. What What is What
is behind that? So, that must be
what? 2009, 2010, right? Um
Apple is moving from PowerPC to Core
Duo. Um
that's probably in 2006. And by 2009 or
2010, I decided that we are not going to
do new versions of VLC for Power PC.
Mhm. Like at that time, like VLC we were
close to the number 1.0 release. We were
four of us, right? Like just like, "No,
this is not possible." So, I received a
death threat with some powder in it,
right? It Remember there was some
anthrax threats at that time, right?
Um and it was because I had
taken the decision to not maintain the
Power PC port anymore. And of course, it
wasn't anthrax, of course. It was some
type of flour and so on, but I received
that as a with a letter of like,
"You You're piece of You should
die.
Power PC forever." and so on. And was
2009 or 2010, right? I was I was uh
I was young. I was just like,
"Why? Why did I do?" right?
>> can break your spirit. It's like, "Why?"
>> My mother freaked out, right? We had to
go to to see the police and so on. And
now, like
I
I'm going to say that I'm quite happy
that this happened at that time. It It
taught me a lot, right? I am
I I can see I can take a lot of uh
of hate on me. I'm I'm okay with it,
right? It sucks that that's part of
reality, cuz all the people that love
VLC, all the people that love FFmpeg,
like me, you know, I I legitimately
hundred probably thousands of times in
my life had a smile on my face because
FFmpeg made me happy. Period. And how
many times did I get a chance to say
that? Zero. Until I realized there's a
Twitter account. [laughter]
And every once in a while, I'm like
messaging it. One of the things I like
on the Reddit meme about me, which I
don't like this meme for a lot of
reasons, but and someone says, "Oh, JB
is on is on Reddit." which I am, right?
And I say and say, "Hello." right? And
then I got so many people who say, "Oh,
thank you for VLC." And like, I take
pictures and then I share that to to to
the signal to IRC. Yes, we use IRC on on
different
>> I I I saw you as a quick tangent. You
mentioned IRC is like Slack for old
people. So, you still use IRC? Of
course, yeah. I have it on my phone as
well. Of course, every day. Works fine.
Wow. It works fine.
>> Works fine, yes. You have to power with
a crank.
>> No, but there's there's no
there's no
there's no tracking, there's nothing.
Well, it's uh The the biggest issue, to
be honest, right, compared to Slack is
that it doesn't have threads. That's
annoying. It doesn't have emojis for
action. Sometimes it it would be nice.
Yes, V3, but no one does it and you
cannot edit your messages. Yeah. Right?
And the rest, it works perfectly fine
for everything.
>> you communicate without emojis? Well,
that's that's why I said it's for old
people. Old people.
>> [laughter]
>> And we do we do emojis with like, you
know, the colons and that. Yeah,
exactly.
>> [laughter]
>> So anyway, you communicate I see. What
were we even talking about? Yeah, we are
talking about death threats and and but
having people thanking you and sometimes
they got people who sent me a message
and
oh, thank you for VLC. And I always
answer because I want to to to validate
the fact that you need to thank the the
the open source community. Yeah, please,
everybody listening to this, celebrate
celebrate FFmpeg, celebrate VLC,
celebrate all the incredible
open source projects, Linux, everything.
There's so many There's so many And and
And you know what? I mean, even outside
of open source,
just celebrate companies
that create software
that you use a lot and love. Celebrate
human endeavor. Celebrate the human
effort to not just build something
that's okay. Yeah. Build something that
is damn good. Yeah, this is important,
right? Like because as we said, right?
We work for
technic we do something very complex for
the normal people. Like we want our
excellence in tech to be useful for
everyone. And this is why like this is
why we work, right? This is why I wake
up in the morning is because I want
people to use our stuff
because it's making everyone's life
easier. Want to solve our problems. Work
on something interesting, work on
something interesting technical
challenges.
>> We are engineers. We love to build
things, right? When I was young, like
very early I knew I wanted to build to
be engineer. I wanted to do to do cars,
right? Maybe at some point I will go
back to cars, right? But
this is like we want to build things
that are cool and useful and they need
to be challenging, right? Because you
want your brain to turn on. When did the
two of you first fall in love with
programming, with with building, with
engineering?
When is the first time you programmed,
Kieran? Microsoft QBasic. As I was on
Windows 3.1 and Windows 95, Microsoft
QBasic.
>> Oh. Wow. What did you build? Uh like a
multiplication. Just counting loops like
10, 20, 30, 40. Nice. Uh then I thought
I could do everything after that. I
wanted I I jumped from doing that to
I wanted to create a soccer or a
football soccer video game and I drew
all the I drew everything out and I was
like I want to do it and I didn't quite
grasp that actually
uh I didn't grasp actually it's a
massive piece of work to jump from basic
and drawing some pictures to a video
game, but there we go. I think I did um
also basics and then Turbo Pascal
when I was
yeah, um
end of elementary school,
but mostly the first time I actually did
some serious programming was the the
first year of um
you call that middle school when you're
11? Mhm. Um I was
I lived in Italy for a year in Florence
and was amazing year
and like the math teacher told us to to
work in a programming language called
Logo where you had a turtle that was
designing things
on the screen and you would turn left
and right. And in the end, we used that
to do
very complex programming because of
course you could do things. And And this
changed like I knew I was I wanted to do
things with computers and program. I
don't think we quite talked about x264
probably. Talked about David. Can we
return
backtrack a little bit to x264, this
thing that powers basically all of video
on the internet? So
Uh can you tell me the story
of x264 and Karen, you're actually a
contributor to x264.
>> x264 is is a video encoder for the H.264
video standard.
It dominates internet video, but also
other areas such as Blu-ray discs. And
Blu-ray discs are interesting because
the people that make them really want
the highest quality.
And there's some really cool high-end
films that have been encoded
broadcasting and all sorts of other
areas.
x264 was a big step change. Um
Cuz it kind of happened at the right
time as well. A lot of the development
took place when HD video was coming out.
Intel Core 2 and Nehalem CPUs were
getting fast. You could do real-time
video. But the most the most important
thing
was um
a key sort of focus on visual metrics.
So industry and academia for
20 years before was obsessed with um
mathematical metrics that was known as
peak signal-to-noise ratio. So
mean squared error, logarithm of mean
squared error. And that led to tons of
issues because mean squared error um
leads to blurring cuz you actually want
to you want to minimize you want to add
a little bit of error to everything to
to reduce the mean squared error as
opposed to having a big error. And that
led to loads and loads of blurring.
So hob- but hobbyists bucked that trend.
It was for their own personal videos,
mostly anime.
So there were two there were two things
they did differently. And there's a big
iterative feedback loop with the
community.
They did some stuff differently. Um
Two two big things, psychovisual rate
distortion, so using
block energy, trying to compensate for
human perception when making decisions.
So, the psychovisual distortion, that's
the critical thing. That's the thing I
mean, it's kind of revolutionary like
that we can like rethink
don't don't make it like this kind of
theoretic thing of compression.
Make it all about being pleasing
visually to the eye.
>> Yeah, yeah. So, compressing in a way
that loses least amount of information
for the stuff that matters for us
humans.
>> Yes, exactly. As opposed to what
industry some parts of industry are
still obsessed by this, which is
mathematical numbers that don't look um
good in reality. And then adaptive
quantization was the other big one where
it was biasing bits against um complex
areas and redistributing them to less
complex areas like grass. Grass
has some high frequencies, but it's kind
of
it's less complex overall compared to
more complicated things. And this came
around by um
Park Joy. So, Park Joy was really the
canonical sample that was
it's still running around in the park.
>> This one. Yeah, so this guy was really
the um
So, this this was created by Swedish
television in um the beginning of HD and
it was done on film and it was no
expense spared in terms of production
quality and it was given away for free.
This was really
and this is the sample really that sorts
the men from the boys in terms of it has
so many challenges with the trees with
the water, with the grass, with the
motion, with the
I don't think there's there's still been
any any public test sequence as good as
that these days.
>> So, for people who are just listening,
we're looking at
a bunch of humans running
>> Yeah. along a river. So, you have the
reflection, a lot of really high
information textures everywhere, the
leaves and the lighting playing with the
leaves and all of this. You could show
clearly that encoders with high PSNR
will blur everything.
>> will blur everything and you could see
actually I could turn on psychovisual
stuff. I could turn over that the
quantization and
it would just look so much better but
your your metrics and these metrics are
at the time were at the time were
considered so holy. These are the holy
metrics that are untouchable. PSNR is
the most important thing. Can you speak
to how do you measure psychovisual
stuff? Like how do you turn how pleasing
a compression is for human eye into a
number? Is that even possible?
>> That's what that's what Netflix have
been trying to do with VMAF. They said
they've used a machine learning model.
That's a more recent thing but back in
the when the x264 was being developed
that's by eye you're basically
>> by eye. It was It was developers on
their laptops. So it's not like even
with big companies with professional
screens or anything. It's And that was
actually one of the goals which was I
don't the developers at the time Lauren
Merritt in particular is I don't want to
test this on a $30,000 screen. It's I
want this to look good on someone's
laptop at home. Yeah. Brilliant. And
there is another sample which is
uh
a sample that is Planet Earth killer
sample that I absolutely love and you
are going to see why, right?
Um it's a ton of birds, right? Flying
and the more it goes the more there are
birds and at at the end, right? It's
almost like
you have millions of birds. It's the
most complex thing ever to encode,
right? And well, you're watching it on
YouTube and you see how bad the YouTube
encoding is actually, right? Um and this
is like
phenomenal to to optimize and get
perfect quality in a constant bitrate.
There was a lot of optimization mostly
by by Lauren also
on anime, right? For a long time anime
was very badly encoded because there was
a ton of banding, right? And you see
those
those issue and there was a ton of
things. So x264 is like and today it's
still the reference to any encoder, new
encoder, AV1, AV2, VVC, HEVC, everyone
compares to x264. One of my favorite
films,
Cinema Paradiso, I know the engineer who
created the Blu-ray and he showed me the
comparisons of x264 versus others and
that it's completely different and I
think
a bunch a bunch of guys in the Blu-ray
world started using x264.
I think the big one was Chris Anderson
from Warner Brothers. He did the whole
French box set with that that's a quite
like a thing that a person on the street
actually watches and wants to look good
and so they kind of took a risk in their
jobs doing that cuz they're in a big
company. That big company can buy
whatever they want and they said, "No,
no, no, I want to use this free and open
source thing so that things look good
for my my customers and build the best."
And to this day I personally still try
and avoid watching the most cinematic
films on streaming services and buy
physical discs because they look
they look good without even having to
buy an expensive TV. I think that's the
key thing. And x264 is yet another
example of open source project. It was
started by Laurent Aimar when he was at
the Ecole Centrale Paris where VLC was
born and then you got generation of
people like Laurent, like Jason, like
Mans, like
so many
Henrik [clears throat]
and this is Anton and this is where the
assembly
thing that we use now on FFmpeg, David
and so on was born, right? So x264 is
like amazing project with people who
were really all over the world and I
think most of them never met each other.
But [snorts] all of them, according to
Karen, a large percentage love anime.
There's several things I've never gotten
into and one of them is anime and I need
to
>> I watch anime so much. Especially at the
time,
like at the time it was like
a lot of anime content doesn't exist
commercially, right? So, we are before
Crunchyroll, right? So, what happens is
usually people who love anime who take
some things some DVDs in Japan and rip
them because there is no commercial
offering and some of the people who are
what we call fan subbers are basically
translating themselves to make
subtitles, right? And at that time you
download completely illegally. It was
the only way to do that, right? And so,
all of that was handcrafted and it fits
the open source community, right?
Because they needed tools to encode to
do fan subbing, right? One of the most
amazing open source projects for
subtitles is called A A A E G sub and
it's it's a subtitle it's done for anime
for for for
South Asian and Japanese languages.
There are weird textures in anime that I
don't think you get
in real life content. I think that was a
key one which was optimizing these weird
textures that you get because it's not
done in a normal fashion. Yeah, the the
way you produce it is not you mostly
produce it like on screens, right? A bit
of time and you have all those
gradients, right? In colors because they
are very easy to produce digitally, very
complex to to produce in real life
and
and the subtitles also are very complex
because you need to have often the
Japanese and then
you need to have the diacritics, right?
The the what we call the rubi, right?
Which is the hiragana and the katakana
for the kanji and then because of course
you so that you have the official
subtitling, but you also need the
English subtitles or the French
subtitles because you want to to learn
that, right?
And there is so many things crazy on
subtitles and we had like crazy samples
on on subtitles that we've seen all
around. So,
this is an important part of the the
culture, but also because there was no
official offering. There was no way of
doing that.
Can you speak to the difference between
H.264 and AV1 and then X.264 and
David, this is this big step. Can you
help people understand
are some of the streaming sites moving
more towards that direction of AV1?
Let's be honest. All of those codecs
since
MPEG-2
video are the same concepts.
The same concept about inverse
transform, about intra prediction,
motion compensation, entropy coding. All
of them. However, each generation gives
you a bump between 25 and 50%
more compression for the same quality.
Um, and so you had the MPEG-2, you had
the DivX area, you have H.264 which was
like
changing, right? H.264 improved so much.
And then you had more, right? You had
HEVC, um, you had VP9 at the same time.
of HEVC, VP9 is a bit similar to HEVC in
terms of quality compression, but it's
royalty free because in multimedia there
is ton of patents and the licensing
after H.264 became out of hand, right?
And it could cost hundreds of millions
of dollars per year. So it made no
sense. So Google did this VP9 and the
Alliance for Open Media did this new
codec called AV1.
Um,
so you can imagine that AV1 saves
between 40 and 60% less bandwidth than
H.264 for for the same quality, visual
quality. At a given bit rate. At a given
bit rate, right? So that's really like
you increase the quali- either you you
set the bit rate and you increase the
quality or you set the quality and you
decrease your bit rate. But because now
you move from from SD to HD and HD to 4K
and 4K to 4K HDR, like you're increasing
the size by like two factor two, three,
four, right? So, you need to have better
compression to keep it in terms of
something that is manageable. It's more
coding tools, more bigger blocks, lots
more sub-partitions in each block. It's
just exponentially more complex.
>> It's more complex because the the
encoder needs to search more
possibilities, right? So, you for
example, um
one of the things that is easy to
understand is
to predict a block a a color block to
another, you have directions, right? So,
you can go left, right, bottom, up, and
then in terms of uh uh
like the other quadrants, right? And
then I could north northeast, northwest,
and and so on, right? But, that's eight
directions. Then you can do more
direction. You can do 16 or 69 or 128,
right? You can And every time your
encoder is going to spend more time to
see, "Oh, well, this block is exactly
this one." Um
and those type of tools that you can
bring and the encoder needs to check
which of the tools are going to compress
you better. And so
I guess that AV1 encoding is two order
of magnitudes more than H.264 in terms
of CPU cycle, right?
Order of magnitudes, right? Yeah. And as
we discussed, CPUs are not getting
faster. You're just throwing more cores
at the problem. But, also it's a fact
that you encode once and you have
hundreds of millions of users, right?
>> Yeah. So, for example, YouTube, a very
good example. YouTube encodes almost
everything in H.264, but the popular
video gets re-encoded in AV1 because
it costs more, of course, to encode, but
you encode once and you send that to
millions, right? So, it's a trade-off
between encoding time and complexity and
and CPU usage on the server side and on
the client side. Because at the end, if
you're distributing a video to hundreds
of thousands of people and the size is
half of the other, then it's better.
It's better for your battery, it's
better for your modem, etc., etc. So, we
can lay out, let's say, the
top five codec
container combos would be H.264 inside
MP4 containers,
AV1 inside MP4 WebM containers,
uh ProRes for nonlinear editing,
uh inside MOV containers.
>> So, for people who don't know, I guess
ProRes is It's Apple's codec for
editing, originally for Final Cut Pro,
and it's designed to be faster decode,
faster seek, because an editor will need
to move very quickly. So, it's a
different use case to the
distribution element. There's no or very
minimal uh temporal compression.
>> There's none in There's none in ProRes.
So, you can cut So, you can do cuts.
This is what we call intra only codecs,
right? So, uh I'm going to explain
quickly what is
IPB frames. Yes, please.
>> Um so,
I frames often
key frames, but
is complete frames. It's like an image.
It's a JPEG, right? You have You can
start, you see everything, right? Um
and then, you the next image can be a P
frame, which is a predicted frame. So,
you take
some part of the previous image, saying,
"Well, I need the block five and seven
and 42,"
and you replace it, and then you just
give the extra information, right? But,
that means that in order to decode this
P frame, you need to have access the
previous I frame, right? Mhm. And then,
of course, you have more complex one,
which are B frames, which are B
predicted um frames, which can be depend
on
different type of frames, some in the
past, some in the future.
Um and so, ProRes is an intra only
codec. For the people who can see, this
is a very good one, right? So, I frames
are complete frames.
B-frame basically depend only on I-frame
and B-frames can depend on in front. And
this GOP group of pictures, I think the
default for actually FFmpeg
for H.264
is like 250 frames, something like this.
Yes. And to me it's just it's like
magic. Like you could predict that you
could have a complete frame every
several seconds, that means several
seconds and then you could still you
could have this chain of predictions you
make and the fact that you can the fact
that somebody like me can can use FFmpeg
to compress something and not notice
that the result still plays back
smoothly is is like magic. You can even
have
and we use that in tons on Kaiber is
what we call intra refresh
where basically it's
there is no I-frames
>> You have no I-frame. You have one at the
beginning and you never send an
[clears throat] I-frame.
>> How does that work? What is your You you
build up an I-frame gradually across as
the stream continues. So So you refresh
certain parts of the image. But so you
never have an I-frame. Like this is
intra refresh that we use, right? But
for me for me the the the biggest
mind-blowing when I started was the
B-frames. Yeah. B-frames means B
predicted frames can depend on frames
that are coming in the future.
That means that in order to decode this
B-frame, you need to wait for the next
frame that is dependent. Yeah. But first
that, decode that one so that you can
decode the B-frame, right? So the the
the way you decode the frame, the
decoding order is not the same as the
display order, right? That means the
encoder needs to be very clever and
decide that well, you know, I'm going to
depend on things like in the future. So
this is like
mind-blowing. Yeah. The fact it works so
smoothly every day is kind of miraculous
in some ways. It works so
You can have a stream that works
across the world on their decoder versus
one in the US versus one here of
different manufacturers and they produce
bit for bit exactly the same material.
That's quite remarkable and do quite
complex things and getting more and more
complex and still be bit exact.
There's a lot of work that goes into
that. There's a lot of knobs you can
control in this whole process. There's a
lot of really fascinating parameters
that I've gotten to know more and more
over the years that FFmpeg gives you
complete access to.
Maybe you can speak to some of them. So
first of all, like obviously we can
lower the resolution, we can lower the
frame rate, we can use different kinds
of codecs as we mentioned from H.264 to
AV1.
There's ways to tune the trade-off
between bit rate and quality as we've
kind of spoken to.
You know, you can do constant bit rate,
you can do constant quality CRF CQ.
QP.
We can
do the longer or shorter group of
pictures GOP that we mentioned. I mean,
all that kind of stuff. It's crazy.
Number of B-frames. Yeah, what is crazy
is that
a ton of people
whose job
is to optimize those parameters, right?
A ton of people that you see at YouTube,
at Netflix, at Meta and so on. They're
not writing codecs. They're just like
finding the right
parameters for the file they have for
the format they have, right? Because
like something that is for a movie or
something that is user generated content
from your phone or a screen recording or
something that you're going to video
edit, you don't want the same things.
And there are thousands of people whose
job is just to optimize all that. Yeah,
they're wizards. Hats off to them.
Uh YouTube, like they deliver all the
streaming sites actually. They deliver
at scale. And like YouTube is is really
magical because it's not just doing like
what Netflix it does which is one way
broad like broadcasting type thing.
It's also has to upload videos from all
the places. So, they're also doing
encoding at scale
for videos are going to be watched by
like five people. And it still has to
deliver them re- like
at a moment's notice. No no delay,
nothing. No late Well, I mean, very
minimal latency.
And And it also serve it
in all different resolutions. Like
YouTube is basically the web version of
VLC. Yeah.
Well, actually, this is funny because
like Google Video, which was
something they did before they acquired
YouTube, was actually using the VLC
plugin so that you could run VLC inside
the web browser
using the ActiveX plugin. And so, it
worked in in Internet Explorer and you
were actually running
VLC inside your browser.
Which is funny because today we have the
opposite where we have VLC web assembly
where we compile all VLC and FFmpeg to
decode to run VLC in type of inside the
JavaScript virtual machine
with web assembly.
Okay, there's this legendary story that
you pointed me to
that
it was discovered
via WikiLeaks release of all sorts of
documents the CIA was using a modified
version of VLC
to basically try and trick people what?
To steal their data? Yes, exactly.
>> So, can you explain what the heck
happened with
>> [laughter]
>> So, so so this was a surprise, right? Um
because at some point WikiLeaks
mentioned some documents. There were a
few ones with something related to
Blu-rays and VLC, but the the most
interesting one was the CIA Vault 7,
which if I understand correctly,
was the CIA had like a custom version of
VLC
where they had a specific plugin. Yeah,
exactly. This is like we had to do write
a press release on that. VideoLAN wrote
a press release saying the only safe
source for getting VLC media player is
the official VideoLAN website. I mean, I
suppose that's a security vulnerability
for basically any piece of open-source
software. Somebody can trick you to
download in a fake website or targeted
advertisement. Like that was a targeted
advertisement to watch a specific file
you need to watch with this custom
version of VLC. And it was the normal
binaries of VLC except they added one
DLL. I think it was psapi.dll,
which was basically
reading your
your document folder, encrypting that,
and send sending that. And the thing is
this is very clever to be honest because
once you're watching a movie, right?
You're going to do that for 2 hours and
you're not going to touch your computer.
And sometimes it's normal because it's
HD that your your fans are going up and
say
and there is some of the CPU usage
because you're using VLC, right? That's
normal. But the thing is what you don't
see is that actually a
powered version of VLC that is used by
CIA. Um we had exactly the same problem
with Chinese hackers that were targeting
Indian people and that got VLC banned
from India until I had to to fight in
court in India the Indian government to
unban VLC. They didn't use VLC. They
took just one DLL because we signed the
DLL correctly.
Um and they used that DLL to do another
program. Uh so you had the vlc.exe and
was calling libvlc, but it was calling
it into a fake one. And they used that
to to target.
There is not much we can do actually to
to to block those type of hacks. Yeah,
and I think people should for all open
source software, for all software in
general, people should pay attention
where they download the thing. Yes,
because that means that they were not
downloading it from our website. Do the
search engines help you? No, they don't.
Just to clarify, cuz you can you know,
to prevent threats from people
manipulating SEO to get up there on the
links
>> Absolutely not, right? We have a big
issue for like more than 10 years is
that there is a fake version of VLC in
Germany that was reported for now for
12 years, and Google basically decides
to not they know what's in it, but the
binary is too big for their virus
analyzer to analyze it. And so, well, if
you're in Germany, you can go to a
website that is a fake version of VLC
with a custom installer, and it's very
popular in Germany because the website
is in German, and and Google's mentioned
that before VideoLAN. And the weirdest
thing is that it doesn't do anything on
your machine for 3 weeks. Mhm. Because
that's how they they do the detection.
And after 3 weeks, there is a small
program that is a service that installed
at the same time that wakes up after 3
weeks, and it start downloading spyware
and adware. And Google knows about it,
they decided not to do anything. The
guys use dark SEO in Germany to to to to
do that
at some point. Um,
and this is very damaging, right?
Because one of the things that they're
downloading is actually something that
is replacing your ads inside your
machine, right?
>> It's actually quite surprisingly
effective.
Whoever's doing it with Twitter and X
with X, I'll get emails about your X
account has been hacked. And however
they phrase it, it gets me to like at
least click on the email not to follow
the thing. And then you're like, man,
whatever they're doing with the
psychology to try to trick you, they're
quite good. There is a security visual
of VLC, right? You receive an email
saying, "Hey, there is a security
version update on VLC. Think about
updating right now because it can hack
your computer." You come, it's a website
that looks decent and and you download
it's a new version of VLC. Great. You
don't know a month later you're hacked.
You have no idea. You're part of a
botnet. Yeah.
So, [snorts] make make sure wherever
you're downloading stuff is legitimate.
>> [laughter]
>> You're part of the botnet. Uh speaking
of which, so uh you've mentioned that
uh VLC sandbox is something is something
you're working on and it's actually
something quite challenging. Why is it
important? Why is it hard? So, VLC is
a core with around 500 plugins, right?
One of them is FFmpeg, but we have we
support so many other formats, we
support uh new protocols, we support new
filters, we support weird architectures.
And in this release of VLC,
you have modules that are going to call
your drivers, right? Uh mostly the
hardware decoders, which are going to
call
uh
your Intel, your Nvidia, your AMD
driver.
Um and
all calling FFmpeg, right? And there
might be a security issue. There might
be a security issue in the shader, there
might be a security issue in VLC, in
FFmpeg that is going to basically crash.
The issue is that you're running VLC
like every every other program, like
Adobe, right? You're running it
on your machine and it has access to all
your documents, right? So, the idea is
to be sure that you do a sandbox so that
we can protect
from ourselves because inside the VLC
process is running some code that is not
even ours. It's It's open source. The
other projects that we integrate in VLC
or it's your GPU driver or something
that is provided by someone else inside
and so when we crash, we want to not
allow people to do bad things, right?
Because one of the common way of hacking
people is to crush a program, very often
done with a web browser, very often done
with PDF files,
less often with multimedia, but that
could happen. And when you crash, you
launch something on the on the machine
of the person. Could be a ransomware,
could be a botnet, right? So, security
of desktop application is important. On
mobile, it's a bit different because
most of the mobile application are
running on the inside their own sandbox.
But
for VLC, we could run it inside one
sandbox, but the problem is that we need
access to so many things
that is basically we we would do we
would have all the permissions, right?
And so, if you have a sandbox and you
put some holes everywhere, it defeats
the purpose, right? So, what we are
trying to do and we're actually doing is
splitting VLC into several processings.
One is decoding, one is demuxing, one is
filters, and all of them run into their
own sandbox. So, that the whole VLC
a part of VLC crash, like Chrome crashes
on some on some tab, right? It crashes
the crash, but it did not crash the
whole program. And this is what we're
trying to do. And it's difficult because
it's a sandbox that needs to sustain
gigabits per seconds of of mem copies.
Now, it's not a website which is 5
megabytes or 10 megabytes. We're talking
about hundreds of megabits per seconds.
So, this is why it is quite challenging.
And this is a a research topic that we
we are working on in order to have
multimedia player that is secure. This
is all the kind of stuff you have to
think about when millions of people are
using. You you mentioned something
somewhere where like all the different
features of VLC,
when you have that many people using it,
somebody will use every single feature,
and they will tell you about it.
>> Best feature in VLC is called the puzzle
filter, right? So,
you click the puzzle filter and it
transforms your video into a jigsaw
puzzle, right? And you can click and
move the pieces, right? Yeah. Um very
very useful when you're watching a
French movie, right? You're bored and
because it's like like very long things
or or a love triangle, right? You've
seen that so many times, right? But but
you need to watch it because someone
your wife or Yeah. told you to do that
or your boyfriend told you to do that,
right? So, you're doing that, right? And
you can click and move the pieces
around. Yeah. It's absolutely useless,
right? Like, who cares about that?
First, it was done by a math teacher in
high school in South of France to teach
his students about Bézier curves, which
is something that everyone should know
about, right? It's very useful.
But the code was clean, so it got in
VLC. It was merged in 2010.
Five years later, I receive an email and
saying,
"Hello JB, I have a problem with VLC.
The puzzle is too simple." And I was
just like, "What?"
And
>> [clears throat]
>> yes, the puzzle was in the UI maximum by
16 by 16, right? Only 256
pieces. And it says, "I'm sorry, but in
a movie, I love puzzle.
This is too too simple, right? So, there
is a commit of me you can take it
online, which is JB changing that the
dimensions are 256 by 256.
Brilliant. My point is
so many use features
are used by a few people, right? There
is a way to watch VLC movies in common
line
without any UI, right? I saw that you
can do ASCII. ASCII art. Is it useful?
Very useful. Imagine you're debugging
Imagine you're debugging a multicast
network, right? You have thousands very
complex
very complex networking stack, right?
You can SSH to all of the routers and
put VLC on it with no UI. And you're
going to see whether it's black or it's
not black, right? So, you see if Oh,
it's all green or not all green, right?
So, you can see
>> Amazing. Right?
People don't realize there is so many
things in VLC that are useful
and they are
they have users because once you have
hundreds of millions of users
you have people who use every feature.
I would like to sort of uh
zoom in and and talk a little bit more
about the distinction between kind of
downloading a file and watching it
offline versus streaming. So, the the
complexity and the challenges of
streaming. Is there something we could
say about what it takes to
uh stream files? Cuz we've been talking
about codecs and I think a lot of that
implies
encoding and decoding
uh without the having to communicate
over the network.
>> Sure. Sure. Uh so, can you can you
elaborate like what's required to do
over the network stuff? Yeah, but it is
less complex than it seems compared to
everything that we've talked about. Um
especially because the most complex
thing is not about streaming in terms of
um
streaming services, but it was was what
was done to actually broadcast through
satellites. Um because in in in most of
the modern uh
broadcasting services, you can pause and
you can go on. But when you're sending
live streaming whether it's broadcast
for streaming services which are live,
this is much more difficult because you
need to encode in real time. You when
you go on a satellite, you have a
specific size of the link, right? You
cannot have a burst of bandwidth even
for a second, right? Because you don't
have the space for that in your your
total file. However, there is different
types of challenges which are
interesting challenges, but I think they
are less complex than the one we've seen
with um
late '90s and early 2000s about
broadcasting and streaming through
satellite. They're different. Their
control systems challenges was was some
are more mathematical. I think that's
the difference. In the streaming world,
what you have is called what we call
adaptive streaming because the
difficulty and it's not really a video
problem. It's mostly a CDN problem is
that you might have too many people
watching the same thing at the same time
and it's a congestion of the network,
right? So, your player
has difficulty downloading things fast
enough to play them. So, what happens is
that locally the player is going to read
lower resolution of it.
But,
there are some very clever algorithms to
do that, but most of it is quite basic
to be honest. Even on the buffering side
is pretty basic. Yeah, you you you you
start you download a
a segment what we call a segment and
then you you time, right? And if you if
it takes more than 50% of the time to
download a segment, you go down to
right? And the difficulty is more about
when do you go up in bandwidth in
quality, but this is not very complex to
do. When you encode, you're going to
encode seven resolutions, right? And and
you're going to give the bit rate. The
difficulty is to have your encoder give
the same bit rate, but it's not as
strict as it used to be. So, Yeah,
probably YouTube has to figure out how
the human psychology side of that, like
how pissed off do you get
when it's like very low bit rate
and
uh how long should it wait before it
increases the bit rate even though the
connection is better
because maybe the the changes in the bit
rate is what like affects you
psychologically.
>> I I think actually the the interesting
one is the audio. The you can kind of
notice when they move from um
full fat AAC to the um
they're compressed versions of AAC that
use spectral band replication. You can
kind of see it goes a bit tinny and that
up and down is very jarring. The video
side
is a lot smoother and there's less
notice. It's really the audio you can
you can definitely you can definitely
feel it from when it's moved you from a
different audio profile to one of the
other.
I don't know. We're surprisingly
tolerant at skipping audio glitches. I
I'm surprised people I know who are not
video engineers how tolerant they are
how tolerant they are to watching sports
at 30 FPS for example where it should
really be 60.
The world is a lot more tolerant to that
but audio people are very there's it's
an immediate feedback mechanism of all
If you hear a glitch, you realize it
directly.
>> Yeah. I get to fully realize that I
suppose one of the things I'm afraid of
when I listen to audio more and more
that I get to notice every single tiny
detail and that you can over obsess when
uh, people people in general are able to
kind of
kind of blur their consumption. They
they can they can look past certain
imperfections. But then when you combine
like, um,
an event that is, for example, a sports
event that is probably going through
satellite or somewhere else and goes to
a central place for encoding and then
you need to encode this all the
resolution in real time. You don't have
time for QA. You need to push that to
CDNs. You need to add probably DRM uh,
or protection. You need to have that
over a ton of different, um, devices
then yes, it is complex. Um, but
and also like you in the web browser or
in very much different devices that you
use for television where you have like a
a defined set top box or cable box that
that you know where you control end to
end. Um, so it's a challenge but it's
less I I think the networking part, uh,
while you agree to have 10 20 seconds of
latency. I don't think this is very
difficult.
Speaking of networking and latency, so
your new efforts we mentioned is Kyber,
which is aimed at ultra-low latency.
As you say, every millisecond counts,
and you're applying that to remote
control machines like robots, drones,
computers. Can you tell me about it?
Sure. Um if you start from where we used
to be, right? You used to use FFmpeg to
encode files, right? And then we used
FFmpeg and VLC to encode in
streaming services, right? And then you
need to go lower and lower. And the
question was where up to where we can
can we go? Mhm. Um and this question is
a very important because there are many
use cases where you need to be fast. And
it's when you have
feedback interaction, right? We're not
just listening to something. You're
actually controlling it, right? Because
And that's a big difference that
compared to what we've done so far is
that I
I need video to have a feedback on
something that is happening live.
Whether it's a drone flying, whether
it's um
controlling our humanoid robots from
distance, whether it's controlling a
rover, whether it's playing a video game
in the cloud gaming because this is um
what I did on a previous job, right? I
was CTO of a cloud gaming startup. Um
and this is a very interesting topic
because you push to the limit the
network. You need to be to care not
about the quality like we've done on
video and we've talked about with H.264.
You care about
latency because a milliseconds
is
meaningful when you're controlling a
car, right? Well, you with you've seen
you use Waymos, right? When Waymos don't
work, and that happens even if 1% of the
time, there is someone that is basically
remote controlling that. Um
And this is exactly the stuff that we're
building. It's a really an SDK
platform
to do end-to-end
control of machines. So, this this comes
up quite a lot in a lot of different
contexts in robotics. So, obviously
teleoperation, teleop is becoming more
and more important
and
including for training
robots via machine
>> learning. Yes, and what we do is a bit
different from any everyone else is that
we take only one socket, one connection,
which is a quick protocol based on UDP,
which is interesting because it's done
for low latency. It doesn't have two of
the what we call the TCP and offline
problem and HTTP and offline problem.
It's different by default, but on the
same wire, we send multiple streams like
multiple struck. We send audio, we send
video, but we also send the comments,
right?
Mouse, keyboard, gamepad, and so on.
And we do that while maintaining
coherence, right? Synchronization.
Because what people don't realize is
that all the clocks actually drift. And
when you're controlling a robot, a robot
is going to have like two cameras, five
cameras, 10 cameras, a ton of captors,
GPS, and so on.
And if you want to train correctly your
robotic AI model, you need to have all
those
that are in sync and currents. And what
we've done, and it's all the stuff that
we learn on VLC in broadcast in real
time and MPTS that Kieran's know well,
is that we account for clock drifting.
And so, when I record a Kyber stream
a robot, I am sure that it's going to be
predictive in the way you play it back.
And so, when you're going to do
recording and training of your AI model,
you need to be sure that every time you
retrain based on the data, the data is
going to stay coherent.
And clocks actually drift. Like the
[snorts] existing solution works with
one camera. Once you're going to have
five or six, it's more complex. Uh so,
you want to make sure
that the visual
snapshot perfectly matches the time it
actually happened. Exactly. And also, if
you're going to control, right? I do
something on robot. I need to be sure
that it is actually happening at that
precise time, right? And so, we have on
the the server, which would be a robot,
the time of like re-timestamping
mechanism accounting for clock drift for
that, right? So, that's one of the use
case um of Kyber to to control robots.
Um I also think like remote drones,
remote uh whether it's defense or
non-defense, remote cars, remote
submarines. There is many places
industry or remote surgery where
the expert cannot go everywhere the
machine is because is a dangerous or
it's too costly, right? So, you you
allow people to have machines
next to you, right? The goal of Kyber is
to make distance disappear um because
it's is a projection of skills or
projection of power, right? So, imagine
we we are all like you've seen the Meta
Raven and and everyone else, right? You
need to stream there, right? Because
you're not going to run anything over
there, right? So, you need GPU power
results on the cloud on the phone to
stream that. And so, all of these use
cases needs to be not about extremely
low latency, but real-time latency for
video. And so, that means you need
we are toying with the encoders so that
the encoders encode a frame in 4
milliseconds. And and and Kiran with his
company also goes under those type of
of of latency because
you need to optimize
at max the
local latency, right? Because it's a
decoder, the encoder,
um and so on.
Um because this time is going to be
added to your networking time.
Um, so and it's not just about low
latency, it's also about like
reliability. We do
clever things like uh forward error
correction, right? So forward error
correction is you over transmit a bit of
data, right? A few percent. Um, and
while over transmit you allow to lose
some packets.
Because all of that is very difficult
over uh
internet network uh where you're going
to do things very far away. Um, and
if you check that all packets are
delivered, you add a ton of latency. If
you don't want latency, what we do is
that we over transmit some data that you
can retrans- reconstruct on the client
side when there is um things that are
broken, right? So um and we um if you if
you days weeks ago we are doing the demo
around Las Vegas for the CES about we
had a
a rover that is fully 3D printed, but
it's very simple. It's a car, right?
It's a small car with a
a telescopic arm. And it was actually
controlled from France, right? And the
the video uh was uh with a webcam and
and a very small server, right? It's
small small PCB, but basically running
and send that to someone that is on the
other side of the planet.
Uh and so there is so many use cases.
You can also think about having AI who
are going to control many drones and so
on. And the technically we need to be
amazing in video. We need to be amazing
at networking. We need to care about any
milliseconds in networking, in encoding
time, in decoding time. And also you
need to integrate very low level. So I
think everything together well, but how
like what kind of latency can you get
to? Like what when you say milliseconds,
what what's the goal?
So my goal is 4 milliseconds
glass-to-glass latency.
Um, what's glass-to-glass mean? So it's
easy, right? You have a computer which
is running a program, right? Probably a
video game.
And this one is actually running, right?
It could be it's an example of a robot,
right? And you have the replicate that
is done through the network. And you
want
if you take a
1,000 Hz camera, you can take a picture
and you want that to be at 4
milliseconds. 4 milliseconds means 240
Hz.
>> [gasps]
>> Right?
>> Yes, not.
Um so far we we achieve um 7
milliseconds from a Windows to Windows
or Windows to Mac. Um and if you look in
the timing, most there is around 3.5
milliseconds inside the Nvidia uh
hardware encoder and around 2
milliseconds on the Intel decoder,
right? So,
like the encoder plus the decoder is
already 6 milliseconds, right? So, in
order to go down, we'll need either to
have some other type of codecs
um
or some better encoder that are faster.
Uh but 4 milliseconds is would be the
grail. That's fair enough. I love it,
though. I I don't think there's anyone
that's ever achieved that, right?
That's fast.
>> achieve that with custom hardware.
With SDI, with professional hardware,
but I want that to work over the
internet. I want that
to work with any robots where you're
going to have a small Jetson Nano in it
or or an 150, right? I want that because
there is going to be millions of robots
or
drones are just rolling robots or flying
robots or or swimming robots, right?
It's just you a machine that you
control.
And in order
either you need to teleoperate them
or when everything will be fully
autonomous, you need to teleobserve
them, right? You need to check what's
happening. And in my view, in the
future, like all those remote cars will
be teleobserved observed by an AI model
which is just going to say, "Well,
everything is going good." And when it's
not good, say, "Hey, there is a
problem." And then you have an operator,
right? And this is going to be about
safety, right? When you have your
humanoid taking care of your grandma or
my grandma,
I want to be sure that everything goes
well and I'm not in those type of
horrible scenarios where the robot is
dangerous. Or when I'm driving at I want
like the car to to stop when it should
stop and if needed someone takes care of
that, right? And so there is so many
care cases scenarios about real time.
And so the goal of Kaiber is to make
real time
control of machine.
Distance disappear. It's It's
incredible. Some of the same technology,
some of the same ideas that we're
talking about is
is connected to what you're doing. And
for for me it's amazingly challenging,
right? Because I would say that on video
I'm doing okay, but networking I'm I
have so much more to learn, right? It's
about like congestion protocols, bit
rate adaptation in real time.
Um but it's it's quite funny. And and so
I created this project and and we we
have fundraised in the US, of course.
But it's open source, right? This is
important, right? Like we've not said
that, right? But everything on Kaiber is
open source. So how do you make money?
It's a a dual license, commercial and
AGPL, right? You remember what you said
about about
licenses.
Basically, if you want to use Kaiber in
your product, you must have your full
product open source. If you want to use
this amazing technology, but not open
source, you pay the commercial license,
right? So the small people or the the
the hobbyist and the the very small guys
who want to do that, they can use the
technology, they build something that is
open source and cool.
>> That's awesome. And if you're a large
company, you're going to have the
support, all the IP, the right to
modification and so on. So
yeah, it's really cool and and and also
I'm building robots and I love that,
right? Like Like the the rover we have
is 3D printed. Um we are finishing a
demo with an actual wing, right? Like, a
type of drone wings that is also fully
3D printed. Um we are trying to do a a
sailboat that is uh 3D printed. Uh and
and and we'll work on some humanoids. Of
course, they're not going to be very
good robots, right? It's not our job,
but we're here for everyone to make
robots. Cool. Uh you're talking to the
right guy. I love robots. There's a
bunch of them upstairs.
Uh and teleop is going to be really,
really important, especially as the
number of robots scales across the
world, so. 100%. Let's talk about the
future of um
multimedia.
FFmpeg, VLC, but uh some of the codecs
we didn't really mention AV2.
So, can we just lay out what is AV2?
What is the hope for it? What is H.265?
H.266? So, AV1 is this codec that is
done by the Alliance for Open Media,
right? Where there is uh Google,
Netflix, Amazon, Apple, uh VideoLAN,
where we try to make a royalty-free
very good codec, right? And now it's
being deployed, but actually the codec
was finished in 2018.
But, a codec takes years to be used in
wide scenarios, right? So, uh AV2 is the
next generation of this codec. It's 30%
better.
Right? So,
if you keep the same uh quality, you got
30% bandwidth reduction compared to AV1.
What's the connection with the David and
AV2?
We are going to do a David 2, right?
That I call "David" because "de" is two
in French. Haha, well done. And and you
have to know that David is an actual uh
what we call recursive acronym, right?
Because it means D David is an AV1
decoder, right? So,
>> Oh, nice. Nice. I I even think of that.
And uh people should know that David
spelled with a one. Yes. It's um And so
David 2 is going to be spelled with a
two. Please don't
>> to be d a v 2 d. Sorry, I don't know how
you pronounce that. Uh
and again, we did a demo at the CES of
VLC running the first demo of AV2. So,
can you clarify to me the specification
of AV2
and then the encoding and the decoding?
Sure. So, the specification is like the
document who explains how the codec is
supposed to work, right? And that's
really AV2. That is AV2. Like H.264,
yeah, right?
Then you have an encoder. The current
encoder is called AVM, and there will
probably be other encoders, probably one
called SVT AV2, and those are the
encoder. The same way X.264 is an
encoder to H.264. The same way that
X.265 is an encoder for the H.265 codec.
And
the decoders for everyone is
David. The decoder for AV2 is David 2.
The decoder for H.264
is FFH.264 inside FFmpeg.
The decoder for HEVC is FFHEVC inside
FFmpeg.
Um and there is a next generation codec
from the MPEG world after H.264, H.265.
There is one that is called H.266
or also known as VVC. So, HEVC is H.265.
VVC is H.266.
Why is H.266 super sexy so much better?
So, the the question often we have is
why are there two names?
Because most of the time it is a
conjunct work from the ISO world
and the ITU, which is the International
Telecommunication Union. So, are two
regulatory bodies One is a private
entity and one is the United Nations.
Which one is the private?
>> ISO is private. In theory, H.264 is
MPEG-4 Part 10
H.264
{slash} AVC.
Mhm. And this is the full name. Nice.
So, it's the concatenation of the ISO
name and the ITU name. Yeah, even though
they work together. This is this is
politics, historical, you know. And for
H.265, it's MPEG-H, H.265, HEVC.
Got it. And there is H.266,
which is also named VVC. Is there a
high-level thing to say about the
improvement? 30% each generation is a
best summary. This is true both for the
AV codecs and the H.26456.
So, so the professional who are
listening to us are going to kill us
because they say, "No, it's 35%
But globally, you need to know that HEVC
is 30% better than than H.264. H.266 is
30% better than H.265 because there is
so many cases and so many scenarios.
For example, there are cases, especially
for screen recording, where the gains
are
humongous because you arrive you have
the right tool that is done for that.
And so, for specific video, a new
generation is going to give you 70% gain
or 80% gain.
Um
but there used to be a ton more codecs,
but now the two main codecs for
transmission are the H.264, H.265, H.266
and the other is AV1, AV2.
>> And I guess that the major difference
would be the cost of encoding. Yes. Yes,
and the royalty of the patents.
And this is the reasons why you see the
AV version of codecs is because um they
try to be as royalty-free, which means
no cost for the patents
as much as possible. Because what you
need to know, and we've not talked about
that so far, is that
multimedia is what we call a patent
minefield. There is two places where
it's where you have the most patents.
It's everything related to 3G, 4G, 5G RF
and multimedia. Um because it's very
mathematical and you can get great gains
and so on. Um so
Google and Meta and Netflix wanted
something where it was royalty free.
There are people who said that they have
patents outside, but they are fringe
patents, right? So,
it's mostly true that it's patent free.
Well, you should extend patent patent
checking was done as part of the
standardization process in AV1 AV2,
whereas patents are not even discussed
in the MPEG world. Patents are off-topic
completely. Can you actually give me the
patents side? So, usually so MPEG does a
format, right? And then there is um
everyone comes around and say, "Well, I
have all those patents on the format."
And they do usually
a union called what's called MPEG LA,
MPEG Licensing Association. Um and you
put all the all the patents in and then
you ask everyone who's using this format
to pay for it.
>> Like, can you elaborate? What does it
mean to have a patent of a codec? Why is
there many patents?
Uh imagine I'm doing something where I'm
going to instead of doing blocks, which
are square, I'm going to do rectangles,
right? Oh, so every idea Yes. somebody
patents it. Yes.
Oh, man.
Yes. Oh, man. People and their
How many lawyers are I mean, it pays for
a lot of lawyers, right? The biggest
issue is not the following, right?
Because at time of H.264, the patents
were, let's call it like, sane. But
there was there was so much money in
that Yeah. that for HEVC
a lot
there were a ton of things that were
pushed inside the specification which
are not useful in 99.9%
of the time but so just one could add a
patent on it.
And so it became that for HEVC licensing
there was MPEG-LA plus another patent
pool called HEVC Advance plus I
think was Nokia was outside of the
patent pool.
>> of them were outside and some other one
And so it was impossible to license,
right? And I think that several months
ago HP decided that they were going to
remove support from HEVC in their
Windows laptops because the the cost was
increasing of those patents.
And it arrived at a point where and
there was uncapped patent. And so for
YouTube or Netflix we could talk about
hundreds of millions of dollars of
licensing for patents per year. And they
said, "You know what? I don't want to
give them
>> [laughter]
>> millions per year, you know, I could
create my own codec." And this is what
they did. And so that's why we have the
Open Media Alliance Alliance for Open
Media where we are part of that is that
created AV1 and creates AV2.
We create also audio codecs.
But yes, so the main difference would be
that and because you need to work around
the patents or go
do something that are not patented.
A lot of things are different, right?
The basic things that were done in
MPEG-2 30 years ago are of course out of
patents but so for example there is
things like
golden frame, S-frame or
different type of These are all patented
ideas.
>> it's I can't believe it's not butter. I
can't believe it's not a B-frame.
It's I mean I mean it's kind of what it
is in some ways. It's like a Oh, so it's
a different variant of a B-frame.
>> Yeah, that's to try and sidestep uh
things like that. And so you need to
have double creativity, right?
Creativity in terms of having being more
efficient but creativity of being sure
that you don't infringe existing
patents.
And so, for example, VVC is
has all the patents of HVC plus new
ones, right? It's while AV2
tries to be as royalty-free as possible.
To what degree does FFmpeg and VLC have
to think about this kind of stuff? We
don't. And one of the reasons why VLC
was in France is that France rejects
software patents.
So, most of those patents
are illegal in France.
Because
I once made the compu- the the calculus
that
if I had to pay all the licensing fee
for VLC, I needed to pay more than 200
euros per user, right? It's the same in
dollars.
Um but most of those patents are invalid
in Europe because those are called It's
basically mathematical patents or idea
patents, and they are not valid in
Europe.
Uh let me just at a high level, just out
of curiosity. So, the meme online and
the interwebs on X and Twitter and so
on.
And my own uh friends in Europe
uh
the the sense is that Europe is not
friendly to entrepreneurship.
They overregulate, there's too much
bureaucracy, and so on.
Is Is there any anything positive to
say? Is there hope for entrepreneurship
in the future of Europe? Is Europe over
from a tech perspective? Just just look
at the two of us, right? It is It's
notable that There's two people from the
European continent on this podcast
talking about video.
It's fair to say the community is
weighted heavily. What you probably
don't see yet is that there is a new
generation of entrepreneurs in Europe,
and mostly in France. UK has done its
since a long time because, well, it's
more it's more Anglo-Saxon type of
business, look at business. But
especially like what happened in France
and of course sometimes a bit overdone
with everything called French tech. But,
today most of the people who come on the
market wants to create a startups. 15
years ago, it wasn't the case. Everyone
wanted to work on big companies because
when you failed in France for example 20
years ago, 15 years ago,
and you destroy your company, which is
normal for startup, right? You you you
were not allowed to create a new
company, right? There was a lot of
stigma. This stigma is gone.
There is so many things happening on AI
in France and so on, right? So, there is
sure over-regulations. I
I know that, right? I mean I don't know
>> [laughter]
>> but
it has some good things also.
>> But, I mean is there some paralyzing
aspects? You know, if I look at at the
case of somebody I've
become close with, Paulo Durov,
you know, he was
uh
blamed directly by the French government
for the kind of things
his quote platform was hosting.
I could see the same kind of stuff.
Basically, it's just as an example, VLC
being blamed for the kind of videos that
people are watching.
>> right? Like we had we got like we
we had issues like like I mean is that
that's the pressure that people worry
about because if you have to think about
that kind of stuff when you're kind of
just obsessed about
>> don't think about it and that's
that's okay, right? Like
>> But, what if they come in? What if what
if they show up and There is no office.
VideoLan doesn't have office.
>> this was happening with Paulo, they
arrested him, right? So, they'll arrest
him for particular videos or or
particular content that's being shared
on the platform.
>> Sure, I don't have any platform.
Everything is on the client side.
Yeah, but they they can still arrest
you. On what ground? I'm not sharing
anything. I'm not The content doesn't go
through my my stuff.
>> For sure, but there's still lawyer fees.
That's the problem.
>> Yes, that's correct. Paperwork. So, like
actually, if you had infinite trillions
of dollars,
uh you would win
uh easily because you're on the right
side, but the thing is there is a degree
to which they suffocate you with
paperwork. That's That's the downside of
bureaucracy, through paperwork, through
process. Yes.
>> the Kafkaesque thing. You have to to to
realize that one of the good things, for
example, um in in in in in in in France
or
most of Europe is that the the
answering to a court order does not make
you bankrupt, right? It's not like in
the US where it can actually bankrupt
you, right? This is There is the way the
law system work is that
like
I I receive lawyers' letters every week,
right? And I can tell you that the cost
of lawyer [snorts] fees for VideoLAN is
less than $10,000 per year, right?
Right? So, that's not really scary. They
mean so with power they intelligence
agencies tried to like say, "Can you put
a back door in VLC?"
>> Yes, two of them. What What did you say?
No. Well, I was [laughter] a lot less
polite. I see I see you uh yeah, yeah.
You're basically saying hell no. Like if
we had to compromise our software, we
would shut it down. This is clear. And
what's the definition of compromise,
like allowing a government to do a back
door? There is no code that gets into
VLC that we don't control.
And the way we compile VLC, you would
call me completely paranoid.
Like
we compile on boxes that are offline
where we start by compiling the
compiler. We do everything offline on on
on places that have never been connected
to the internet. Uh we the way we do
signing there is double signature.
Um
especially because, for example, we've
seen and we believe it's a it's a
governmental agency that is not from
uh the Western world to try to push a
fake binary into our own servers
and that scared us a lot. And VideoLAN
is
open source. How can you kill it?
Like I move to where, right? I move to
Malta, I move to
I don't know Cayman Islands and I change
the domain name and I I start again,
right? Like
VLC is a tool.
It's a tool that is going to help people
doing things. We're not a platform
and for patents, well, I'm sorry, but
most of the patents like you shouldn't
be able to patent math and matrices.
Like this is wrong. Does VLC ever like
censor the kind of videos it can play
and not based on the content of the
video? No, never. We never do that.
Because like
VLC is completely offline. It doesn't
talk to any server. So we don't know
anything that you're using the software
for. So again, there's no government
that can say
you know, like the French government
come in and say we don't want uh I think
anime is destructive to society. We
don't want any anime and not allowed to
be No, they cannot they cannot do that.
And also what they tried is to say,
"Hey, I want to know if that person
watched that type of video." And the
answer is like, "No idea." So no on that
too. So for surveillance, no. No, no,
because the only infrastructure we have
is a downloading infrastructure. There
is no telemetry in VLC. It would be
difficult cuz of the international
nature.
It would be difficult for you to
incorporate that code because there
would be someone in the UK and someone
in Germany and someone in in the US as
part of VideoLAN who'd be able to see
that. It would be extremely difficult.
>> The only thing that we can do which
happen is like we had the issue we had
the case with some police in the US who
said, "We have a murder case, right? And
the file is destructed or doesn't play
in that version of VLC. Could you help
us, right?" We never have access to the
video. It's like a normal support,
right? Oh, it's really about playing the
file. Yes, and like I remember in the
middle of the Afghan war, right? I
received an email from someone in the
army, right? I don't remember the
grades, right? It was just like, we have
a big issue with the latest version of
VLC because it doesn't play correctly
the file on an RTSP server that we have
where there is all the
the movies. And he says, VLC is very
important for the moral on the troop on
the ground, right? Because at night I
think it might be boring, right? So they
have a collection of videos to watch or
movies over there, right? And and of
course I did an update and I broke some
support of RTSP, right? So I gave them
another version just for them, right?
Because it was important. And because
VLC is completely open source, I think
it is allowed on the US Army laptops,
right? Because they I guess someone in
in the in the US military actually
looked at it and say, well, okay, this
is okay, right? And the way we document
how we process, that was okay, right? So
the only way we we we work with
authorities is to help them
doing support. That's amazing. That's
really That's amazing story, yeah. We
don't see anything happening on how
people use VLC and this is strong. Do
you feel the stress of this? So first of
all, millions of people using it. Second
of all,
military using it,
maybe sometimes pressure from
governments. Does that Does that
That's all This is a small team, right?
Yeah. How big is VLC like the core
contributor How many? Six, eight.
But and and and everything legally is
only me.
Everything that is legal is only me.
You know how stressed about this? I used
to stress about that a lot. Yeah. But
the thing is
we're doing what we can for everyone,
for the greater good. We We work that we
make some extremely complex technology
easy for everyone. We a tool and uh
every tool is going to be used for great
things and for bad things, right? You
you cannot blame a tool, uh I think. Um
and and this is like very important for
us. Um I used to be a lot in a lot of
stress. I'm not anymore, right? What's
the secret to your zen? I mean, over and
over in the chats I've had
with you
uh in the in the conversation today
about every even tense topic, you're
very zen. What's the uh what's the
source of zen?
I I have a a way
of um
thinking about what is the worst-case
scenario, always.
Right? And the answer is
at the end, if I take like like a chess
player, right? In the end, am I dead?
Yes or no?
Right? And And I do that nonstop, right?
And that's also how I do
my my startups, right? Is that I'm here
to get something right. What is the
worst case? It got to bankrupt. That's
life. A company lives, a company dies.
That's okay, right? Like And so my my
moral way is always like, am I dying in
the end? Am I hurting someone? If I'm
this answer is no, then too bad, right?
Like, oh, some lawyers are not going to
be unhappy. What are they going to do?
Take all the money of VideoLAN. Wow,
they're going to have 50 grand. Amazing,
right? What are they going to do with
that? The code The source code is out
there. It's unstoppable.
Also because what we do is good and it's
done for everyone.
That's beautiful. Uh Guerin, you you
said that there's an active archiving uh
preservation community. I think that's
super fascinating. You wrote that
they're stretching budget, but they see
the extreme importance of FFmpeg as a
Rosetta Stone so that multimedia can be
played a thousand years from now. I
mean, that's a beautiful way to see
FFmpeg VLC as a tool for preserving
visual knowledge. Yes, so so one of the
coolest communities um in open source
multimedia uh mainly led by someone
called Dave Rice. I'll give him a
shout-out, I think from um City
University of New York is the archiving
community. They've done
so much stuff that they they value that
they value open source. One because yes,
they lack budgets, but two, they see the
fact that
archiving video is important for the
world.
And but being able to play that is a big
problem. Um famously in the UK, there
was a something called the the New
Doomsday Book, and they they archived
lots of stuff on BBC microcomputers. And
within 10 to 15 years, no one had the
right software to play that.
I think it was 20 years or something
like that. And someone had to go and
reverse engineer this. And that was like
20 years, imagine that in a thousand
years.
I think one of the the great things
about FFmpeg is it's written in C. C is
the closest to mathematics you're
probably going to get, the closest to
logic.
>> You just thinking in 1,000 years, we'd
still have C compilers? Yes, we have
languages that exist that haven't
changed too much. We have mathematic
mathematical notation that exists. Um it
will be like Latin. C will be like
Latin. It will be a thing that you learn
from the past, but it will still be
usable in certain contexts.
Um so the archiving community are really
great practically. They they again,
limited funds. They funded the
development of the FFV1 codec. So that's
a lossless codec of for
So that the archiving community is
really scared about the act of
compression losing things. And this
could This is They have a fair point in
this, you know. Yeah. If they compress
too hard, it could change the
view of the material. There could be
something slightly different here and
there. So they're really concerned about
things need to be not just compressed
well, but lossless, and be fast. And And
so they worked with FFmpeg to develop a
whole new codec designed for fast
software-based encoding.
They're really concerned about
resilient. So they if they're storing on
tapes or other hard disks, I lose some
bits, I need to recover quickly. I can't
lose a whole go up because I've lost the
bit.
Something like that.
So, they're really great bunch of
people. They funded GPU encoding in
FFmpeg to make FFV1 encode faster. And
And it's really about
preserving the world's multimedia
heritage in a way that's
that's usable. And there's there's a lot
of great teams in a lot of archival
groups across the world who who've
chosen FFmpeg and FFV1
as their archiving solution.
And they can really provide us also
super specialist advice. They can
explain
Ah, in the 1950s, colorimetry was done
like this on this certain type of tape.
And so, there is a this special case
that you need to handle. And you'll
never get this anywhere else. You see,
they know things on video that we don't.
>> Yes. Like every time I talk to with a
data
>> They were They were right.
>> or or the people from the British uh
British film
>> group, it's just like every time I'm
it's just learn something new. And I've
been doing video for 20 years. They They
have especially on colorimetry and and
colors. Storage, these other things.
>> I mean, they have a deep deep
appreciation of the content itself, of
the video itself. And like especially
when you're thinking of lossless,
they're terrified of losing something
essential about the thing. And in so
doing, they're deeply understanding the
thing that is to be preserved, which you
sometimes might not be thinking about
when you're obsessing about the actual
technology of the encoding and so on.
And when you enter the habit hole of
film scanners, right? So, you take those
Uh-huh. those things to make to
digitalize, it's like a huge topic that
like would take another
5 hours of podcast just on that topic.
film. And there's a lot of film that
needs to be archived. Film is degrading.
It's maybe not stored in the right
environment. The other thing is they can
What they also do is because it's open
source, they give this away their
workflows to countries who can't afford
to have archiving institutions where
archiving is done by volunteers, it's
done
by other things. They go and teach, you
know, in India, they teach children to
do to do FFmpeg commands.
They're really great. They're really
uh they're really the model community,
the model ethos of what we're trying to
achieve for that they are
such a great bunch of people, so
interested in participating and being
part of something much bigger because
they realize the work they're doing
in a thousand years is going to tell a
lot.
You know, in in a thousand years we may
be drowning in AI slop. This stuff needs
to be important and I know I got well,
what was the what was life like? Yeah,
it feels like capturing the 20th century
in the 21st century is essential because
it was like a transition point where we
went from scarcity
of data to slop. Yeah. Oceans of slop.
And that transition point is good to
archive. Yeah. People don't realize we
are losing today a ton of films. There
is a ton of things from the 30s, from
the 40s, and the 50s that were
there is no value.
>> And tape 70s and 80s, there's tape and
there's not enough tape heads in the
world to read all the tapes.
>> all so they have to decide what they
want to archive and throw away the rest
of the tapes.
There's huge moral hazard, I guess, for
want of a better phrase around this
topic because
this is a digital record of human
history and they have to make decisions.
But and there's digital stewardship, I
suppose, for want of I made that phrase
up, it's not a real phrase. Um
to make sure the world can have this
information in in something that's
playable by everybody, not
playable on
some device that well doesn't exist
anymore.
And then there's like realistically
speaking, there's a needle in a haystack
where there's a lot of value in in
archiving all that footage and then over
time finding the gems that we don't know
are there.
Hey, there was something in that corner
that we just didn't know.
And that that would have been compressed
away because of some little thing. Oh,
wow, there's something there and that's
They made sure that it's lossless. They
can prove
mathematically that it's lossless. They
can
run different trade-offs for if there's
bit flip up, they lose a bit a single
bit flips, I can make sure that I only
lose a portion of a given frame. We can
do error recover They can do error
recovery on previous frames. They can do
all sorts of different things.
Do you think VLC and FFmpeg will be here
100 years from now?
FFmpeg, yes. Yep, FFmpeg, yes. VLC,
maybe. What's the future of What What
Where is Where is FFmpeg going? Where is
VLC going? Like in the next If you think
about like 5 years, 10 years, 20 years.
5 years, 10 years is easy. The question
is after that, right?
Um the question is do we arrive at
something called holograms, right? Yeah,
so will VLC and FFmpeg expand to
whatever
Yes. multimedia Yes. So multimedia might
become Sorry for the pothead expansion
of topic, but you know, um
if you look at something like Neuralink
with brain-computer interfaces,
it's very possible that we start to
consume what multimedia means is
whatever
codec, whatever data that our brain
wants to consume through the
brain-computer interfaces. That's one.
Then virtual reality, of course. You
will have VLC for Neuralink. And you
have You'll have FFmpeg-I input format
human brain. Yeah, there's going to be
codecs for the brain.
>> Sure, 100%.
Of course. Yeah, I mean
Today there is like there are new codecs
for for example what we call point
cloud, right? Or volumetric videos,
right? There is a ton of research on
what we call RGBD, right? The codecs for
depths that is useful for robotics and
for 3D things. The return of codex for
compression of 3D elements, compression
for astronomy. Uh for example, on VLC we
also have already a VR and XR version of
VLC. And also on Kaiber, right? We
talked about Kaiber. On Kaiber we also
would like to do streaming of XR content
on for the glasses who cannot have
enough power or inside the Apple Vision
or the Quest. Um so we already work on
uh streaming 3D XR interactive, low
latency. There is something called
volumetric video, point cloud videos. So
it's not stopping. And yes, at some
point it will manage 3D data inside VLC
and FFmpeg, right? It's obvious. So
that's where it is moving. Like the
community is open. Not everyone in the
community sees that, but like as Kihan
and I we are we we are entrepreneurs, we
know where it's going. We we see that,
right? So I suppose that there is a
tension probably inside FFmpeg is like
Hey, listen.
Folks, we're really good at doing video
and audio.
So like why expand? Like let's do the
thing we're really good at doing. In
order to answer that question, we need
to answer the definition of what is
multimedia.
>> Yeah. And a multimedia
is a digital representation
of several streams for the human senses.
And we will do that, right? So imagine
there is now a way to not have a mic,
but have a odor sensor and and a
diffuser of odors. Mhm. It will get into
FFmpeg.
>> demuxer Yes. Yes.
Of course your demuxer has a new track
type that is basically odors, right? And
you already have
>> Smell, touch.
>> audio you'll have a left and right nose
track, you'll have a left and right
audio pads. It's easy. Yes. Of course.
[laughter] The stereo smell.
>> Stereo smell, yeah. So in VLC for
example, we already have a plug-in for
haptic. It's mostly for the what we call
4D cinemas, right? You know those ones
on hydraulic I don't know how you say
that.
Hydraulic
>> Hydraulic arms, hydraulic
And everything is moving. Like you have
in theme parks, right? And there is a
data feed synchronized where which is
basically transporting this information.
>> there yet a standard for
>> There are many standards, right?
This is You make me so happy. And so,
of course, like we have a plug-in which
is not in the normal version of VLC that
is basically transporting those type of
movements, which is physical movements,
which is haptic movements, right?
It is a human sense, so it will get in.
That's such an exciting future. What was
it?
I mean, it's a small community of
developers.
How do you pull that off?
Like if you're a contributor to FFmpeg
or VLC, it feels stressful. Like it it's
just looking at Twitter.
It's like it's it's a huge amount of
work
to make it work on all these different
operating systems. An incredible effort.
>> No, see it in the other direction. We
are not
the contributors. We are the
maintainers.
Right? So, we maintain for everyone,
meaning that
for example, every year there is around
150 people who contribute to VLC and
maybe 300 on FFmpeg, right?
Our goal as a small team is to get all
the contribution
in.
So, if there is more usage, there will
be more contributions, and those people
will do the right modules, the new
formats, and so on. We care about the
architecture of VLC, the architecture of
FFmpeg, right? Now, we're doing things
in in VLC, which is a special audio,
right? We did the demo not not long ago.
There was
changes
needed on the architecture, and we did
the first special audio module. When
it's going to add the second one, it's
going to be easy. Or the third one, it's
going to be easy, right? Our goal and
this going to be the same for others or
haptic, right? We need to work the
architecture so that modules can be
added to add future capabilities. So,
yes, we are going we are multimedia
framework so that's not just audio and
video. It's everything that is timed
and
represents
something that you can sense. And if
it's brainwave, it's going to be
brainwave. I think that's inevitable,
sorry. I I love this so many fronts
because so FFmpeg and VLC are
pushing
companies and pushing the world to
standardize. So, for example, to
standardize brainwaves but also
standardize
it's it would push like I hope Neuralink
comes up with a standard for
for multimedia
via brain-computer interfaces
or for robots with haptic. By
experience, what happens is always the
same, right?
You start it's a new topic that is like
five different standards
because everyone starts to do this. The
hype goes down because every time the
hype goes down, then people start say,
"Well, you know what? We need to do a
standard." People because two or three
companies, usually not the leader but
the two or three followers, do a
standard.
And then we implement the standard and
and then it's the end of the curve. It
starts to be more popular. And then the
leader is kind of pressured into it
because they it's better to do a
standard. Example, 3D audio, right?
Yeah, six or seven years ago was
everything about 3D. You got you had the
cardboard on Android. You had two
two audio formats. They all dead, right?
And now it's coming back with actual use
cases and we learn from the mistakes of
the past standard. So,
it will be the same everywhere. And not
try to avoid closed. I
saw somewhere you didn't have too many
nice things to say about Dolby.
No, I don't. Um
>> What is Can you educate uh me on why
where they went What what What did they
do bad that made you mad?
It's used to be an amazing
company doing tons of great things with
amazing engineers. They defined what
sound was. Mhm. And now it's mostly like
lawyers and licensing things. Oh, so
they're Yeah, it's a they're they're
closing stuff off.
>> They're trying to make more money.
>> they don't innovate as much as they did
and so on. It's a bit like I'm sorry to
say, right? Like HP, right?
>> [laughter]
>> That's true.
Oh, since we talked about Twitter a
bunch in a bunch of different contexts,
do you have a do you have a favorite
your or least favorite most embarrassing
tweet
on either VideoLAN or FFmpeg Twitters?
The two my two favorites are "Talk is
cheap" sent patches. I think that that
embodies a lot of the
stuff doesn't get As we've talked about,
stuff doesn't get built unless someone
does it. It doesn't just appear from the
ether.
Uh the other one that I like is um
FFmpeg, "Nothing is beyond our reach."
I think that comes from a US military
satellite patch where I think they they
invented some kind of um
monitoring system that could see the
whole world and this was released.
>> Wasn't there something where FFmpeg was
running on a rover on Mars or something?
>> Yeah, so FFmpeg is used by the Mars
rover, uh the Mars 2020 rover, to
compress uh pictures. Um they really
wanted um They wrote a paper about it um
they would really want to use as much
commercial off-the-shelf technology as
possible. Um FFmpeg runs on Mars, so we
are we are a multi-planetary open source
library.
>> Nice.
>> Um
>> [laughter]
>> Very often we've seen um
uh tweets for people using um
VLC in weird places.
Uh a lot of the people doing Formula 1s
are in all the paddocks. They use VLC to
play the live feed. Uh we've seen uh the
European Space Agency, we've seen SpaceX
like monitoring the launches with with
VLC and like this like fills you with
joy, right? I've seen a particle
accelerator. Oh, yeah, yeah. We had one
of the most amazing thing that I went
for was to go to the CERN at the LHC
because they were using VLC to monitor
all the captors on the ring because the
ring is 27 km.
And so they had some analog cameras and
they were using some of the capture
cards to go to analog to VLC so VLC
could stream on their multicast network
for the whole CERN to access to that.
Um and like I visited that in 2010 with
Laurent and and and
like we fixed their issue in an hour or
something like that, right? Because it
was some parameters
maybe not well documented at the time.
And he said, "Okay, for the whole day,
what do you want to do?" And we visited
everything. Like things were with
antimatter and and and and colliders and
so on. And that was like one of the most
amazing day of my my physic background.
Yeah, [snorts] it's used like
everywhere.
Uh any any tweets
uh carrying your regret?
And Twitter regret? Or is it like that
Well, how's the French song go? Regret
nothing.
Yes, that's very important for me,
right?
Don't regret anything. No, it's it's
because regrets are a tax on your mind,
right? So, learn from your mistakes, but
don't regret. Because
you've done it. So, except if you have
a time machine to go back in time,
don't regret, right? It's going to just
tax your brain. Learn from your mistake,
sure. Don't regret.
It's like it reminds me it's beautiful
to tax on your brain. Reminds me of the
Johnny Depp quote I saw
where he he saying, "Hate, you know, I
don't hate. That's hate is a very
expensive emotion.
Are [laughter] you comparing me to
Johnny Depp? Because that would be our
first one.
Well, gentlemen, like I said, I'm
internally grateful for the the software
that the two of you and the bigger
community have been part of building
with FFmpeg and VLC and everything else.
I'm eternally grateful for the spicy
tweets. Never stop. And I'm grateful
that you would talk with me today and
give me this
sexy hat.
I feel like a wizard. I feel special.
Um and I feel special to get a chance to
talk and celebrate the piece of software
that brought me so much joy over the
years. So, thank you for everything and
thank you for talking today. Thank you
for having me.
>> Thank you so much.
Thanks for listening to this
conversation with Jean-Baptiste Kempf
and Kieran Kunhya.
To support this podcast, please check
out our sponsors in the description,
where you can also find links to contact
me, ask questions, give feedback, and so
on. And now, let me leave you with some
words from the legendary Linus Torvalds.
Most good programmers do programming not
because they expect to get paid or get
adulation by the public, but because it
is fun to program.
Thank you for listening, and hope to see
you