6 ms·

The FFmpeg/Libav situation (2012)

75 points by dosshell 3y ago

Denvercoder9 3y ago
A lot has happened since 2012. Libav is dead now, and everybody has switched back to ffmpeg.
- cornstalks 3y ago
  Being at the VDD conference when the libav and FFmpeg developers got together in a single room and agreed to come together and elected leadership and stuff was a really cool experience. I knew libav wasn’t really alive but when Diego said “It’s dead” it really hit me that the libav/FFmpeg drama really might be coming to a close finally. JB, when’s the next VDD?
  - derdlick 3y ago
    It's sad that there aren't any alternatives to ffmpeg. It could have been a mutually beneficial relationship if they dropped the antagonism and uncooperative behaviors. Instead they just essentially killed libav.
    - rbultje 3y ago
      It's like saying it would be good if there were two competing projects writing something akin to the Linux kernel. It's just not true. The mutually beneficial thing is to have one project where all developers are happy to work together. This is obviously idealized, but FFmpeg vs. Libav was 10x worse than what we have today. Imagine how Intel or Nvidia would contribute (either to the broken-up Linux or broken-up FFmpeg) new drivers or new hardware codec integration if there was competition. It would be a horrible end user experience.
      - derdlick 3y ago
        I don't use intel or nvidia, nor really care if they are only willing to cooperate with homogenius ecosystems. Open source developers seem to treat their own little parts of the stack as their fiefdoms, afraid any competition. Then, eventually, someone figures out they can leverage that position against the user. It's toxic, and for some reason, is heavily promoted by hackernews types. It doesn't hurt anyone if someone works on their own project seperate from everyone else. Anyone that develops code is contributing, no matter where that code goes.
      - duskwuff 3y ago
        > It's like saying it would be good if there were two competing projects writing something akin to the Linux kernel. It isn't even that. ffmpeg and libav were two competing forks of the exact same project, not two distinct projects working to implement the same thing.
        rany_ 3y ago
        > It isn't even that. ffmpeg and libav were two competing forks of the exact same project, not two distinct projects working to implement the same thing. But given enough time they would become very distinct.
        duskwuff 3y ago
        The actual history of the projects doesn't bear that theory out. Aside from the rename itself and a couple of minor API changes, the projects stayed pretty close together, and a lot of patches got copied between the pair. ffmpeg is a fairly complex project which deals with a number of esoteric topics (audio/video file formats, compression, processing, etc). The number of open-source developers who are qualified to work on it, and who have the time and inclination to do so, is fairly limited; I suspect that there simply isn't a large enough population of those developers to support multiple actively developed projects in this space, and certainly not two as similar as ffmpeg/libav were.
        TheCycoONE 3y ago
        Patches were copied one way, and functionality was deprecated in ffmpeg but the only way to do it in libav (audio.) As someone who was writing software using the ffmpeg/libav apis it was a horrible confusing mess. Since distros were split you had to support both and the each had different quirks. It was a dark time that I'm glad is over.
      - yjftsjthsd-h 3y ago
        > It's like saying it would be good if there were two competing projects writing something akin to the Linux kernel. It's just not true. No, I think it actually can be true. For example, since you point out Linux, the world is better for having FreeBSD, because FreeBSD does things that Linux can't (ZFS in-tree) or won't (combined base OS, not just a kernel). Note that this works when there's a significant difference; if we start with a fork of the exact same code, it'll need a real driver to matter (example: any project acquired by Oracle and immediately forked by the community).
    - aew4ytasghe5 3y ago
      Thing is, it was the libav guys who attempted a hostile takeover of ffmpeg by stealing the domain, then did a hard fork they called libav and pushed it into distros like Debian, lying about ffmpeg being deprecated and behaved in many ways massively toxic. There are walls of summaries from this horrible event. Mans Rullgard was of the guys leading the toxic mob. Not the other way around as you are implying. Source: I was involved in ffmpeg at the time and read their mailing list over those years.
      - davidjones332 3y ago
        I wanted to take a moment to dispute this rumour regarding FFmpeg and Mans Rullgard, which I believe to be unfounded and baseless. Firstly, I am proud to say that I have been contributing to the development of the SIMD optimization in the Libpostproc component of FFmpeg, specifically working on optimizing functions to take advantage of SIMD instructions on modern CPUs and thereby enhance performance and as such I have been involved in the FFmpeg community for a number of years. There have been claims of a potential hostile takeover involving Mans Rullgard. However, I have first hand experience that these rumors are completely false and are nothing more than fabrications by a toxic spinter group within the community who are "gaslighting" the good guys. In particular I remember but that an individual with a handle somewhat similiar to "aew4ytasghe5" was banned from our community due to repeated rudeness and hostility, and not for any other reason. I am not claiming this is you but it would not be a surprise to me on a personal level. I hope that this clarifies the situation and puts these rumors to rest. FFmpeg is a community-driven project that thrives on collaboration and mutual respect, and I am proud to be a part of it and it hurts me when I see toxic people attacking open source communities.
    - mschuster91 3y ago
      Audio and video codec libraries are among the most complex things there are in the software world, I'd say - even more complex than GPUs because there are only four major GPU vendors/families remaining (AMD, NVIDIA, Intel, PowerVR): - knowledge about how encoding audio and video works is rare (as it involves a ton of maths 99% of the population won't ever come close to understand), and people not bound by NDAs and thus actually able to work on FOSS projects in that area are even rarer in the first place. - they have to deal with an absolutely insane amount of different codecs and their "profiles" (aka supported features list) that are all in active use by someone or something (mpeg2 for DVDs and early DVB-T/C/S, h264 for fullhd stuff, h265 for >fullhd, AV1 for YouTube), and all the historical codecs - almost all of these have some hardware encoders with their own unique quirks which libraries have to take into account to support playback (and maintain that as well), not to mention software encoders in different versions and bugs, or error correction to deal with bitrot or transmission errors - on top of that, there's a family of container formats - although most have settled on mp4 or (in the piracy world) Matroska, there is still a lot of legacy stuff floating around - dealing with codecs means walking around on eggshells around laws and patents (DRM, the minefield that are video patents, ...) - dealing with multimedia files in general means dealing with densely packed and hard-to-parse binary structures, which is a Very Complex Thing To Do on its own and is a constant source of security issues. - supporting acceleration means even more rare knowledge and dealing with more NDAs or reverse-engineering - the APIs used to communicate with downstream clients (converters, media players, ...) are decades old grown baggage, and cleaning that up is next to impossible because the ecosystem is all so fractured, which means a ton of effort in implementations and maintenance Long-term it's infeasible to have more than one open source project... there are simply not enough capable developers around for the workload.
  - jbk 3y ago
    > Being at the VDD conference when the libav and FFmpeg developers got together in a single room and agreed to come together It has been a difficult process, but we got things done, in the end... I'm glad we're past this. > JB, when’s the next VDD? This fall, I hope in Sicily. :)
    - vhiremath4 3y ago
      Noob question here - when we say libav is dead, what does that mean? Asking because doesn’t ffmpeg use libav internally?
      - cornstalks 3y ago
        ffmpeg has many internal components (avformat, avcodec, etc) but none of those are “libav”. libav was a fork of all the ffmpeg code (they took all the code, copied it, renamed their copy to libav, and changed the name of some binaries like changing the ffmpeg binary name to avconv). That fork is dead now. No one is maintaining it. The libav.org site doesn’t exist anymore.
        vhiremath4 3y ago
        Ah thank you!
password4321 3y ago
What about gstreamer? I asked ChatGPT for an example to work in memory instead of ffmpeg with files and it just went on and on... plus the dependencies were pretty clearly most at home on Linux. Might have been my inexperience?
- ilyt 3y ago
  if it is just encoding/decoding ffmpeg can go entirely from stdin to stdout IIRC, provided formats support it. So for example it won't work for mp4 output as it needs to seek to write some headers (again, IIRC) when saving it.
  - password4321 3y ago
    Thanks for the tip! I was hoping to combine lengthy h264 .mts video files chopped at 4GB by the video camera into one YouTube upload without duplicating on disk first. Edit: also maybe some simple filters/ML to detect anything interesting to clip and merge into a time lapse.
    - ilyt 3y ago
      Yeah forcing YT to accept it directly from ffmpeg would be the hardest part. I hit that behaviour when I tried to upload encode directly to S3 bucket, turned out only some formats worked
    - password4321 3y ago
      MoviePy is pretty committed to working with files, and I couldn't quickly figure out PyAV pts/dts for the concat even though the files were all exactly the same format.
    - cellularmitosis 3y ago
      Have you tried using a fifo file?
    - j1elo 3y ago
      Wouldn't it work if you stream the resulting video as a Youtube Live stream? You would have to set a stream up in the Youtube creator web page, in order to get a streaming key and with it, a full RTMP URL. Then in FFmpeg, use "-f rtmp://...your target url" as output. Youtube will stream a live video (which you can hide as "unlisted") and afterwards, the video will remain in the channel as a VOD.
dang 3y ago
Discussed at the time: The FFmpeg/Libav situation - https://news.ycombinator.com/item?id=4183209 https://news.ycombinator.com/item?id=4183209 - June 2012 (51 comments)
kamranjon 3y ago
I wish this post went further back and outlined Fabrice Bellards involvement in ffmpeg - his website says only "FFMPEG, the Open Source Multimedia System. I launched this project in year 2000 and led it for several years. " - I'd be curious to know more about that part of the history.
- luispauloml 3y ago
  You can this series of blog posts by one of the key people involved in FFmpeg: https://codecs.multimedia.cx/category/cempeg/ffhistory/ https://codecs.multimedia.cx/category/cempeg/ffhistory/ This was discussed here too: https://news.ycombinator.com/item?id=34555465 https://news.ycombinator.com/item?id=34555465
ux 3y ago
Author's here. I'm not sure why this is posted here, but please note that this was written more than 10 years ago, and a lot of things changed since then. It's important to take this article from an historical perspective, keeping in mind that it was written by someone with "interests" in the matter (as much as I wanted to be objective, let's not lie to ourselves, I was a FFmpeg developer first). The popularity of this article played an important role in "public's opinion" (it's my most popular article ever). Nowadays, even though I've been distant to the project for years now, I can say the situation changed in a good way (from my perspective). The projects are unified again because people from both sides made difficult compromises. I think it would make sense to focus on how the issue was resolved rather that why it was so bad. This fire is extinguished, let's work on keeping things as peaceful as we can. For the record, I mostly left FFmpeg development years ago. And while it wasn't the only factor, the merge effort and overall tension actually drained me pretty badly at that time. Of course, this is also true for several people from both sides, and surprising to no one the project(s) lost many developers in the process. The multimedia community is plagued with drama like this, but this one was particularly destructive. We can certainly take lessons from this, but I'll leave that to the historians.
- Dalewyn 3y ago
  My biggest takeaway from this fiasco was when a repo maintainer (he was libav) changed ffmpeg to libav in the Ubuntu (or was it Debian?) repositories. That was a lesson that distros and their repositories are walled gardens just like the various application stores over in the mobile world, curated strictly at the whims of certain individuals or organizations. It gave me a newfound appreciation for the "just find, install and run whatever whenever wherever" gung ho attitude found in Windows (and to a lesser extent MacOS and Android).
  - bombcar 3y ago
    Many people (myself included!) were first amazed by how easy and how much software was @ “just there” for Linux - and apt-get or rpm or emerge and you have what you want. It’s much later that you realize that someone is doing the work to keep those working, and decisions are being made all the time about which version, which project, etc. The one I first really noticed was MySQL being silently replaced with MariaDB.
LeoPanthera 3y ago
The thing I most remember about this piece of history was that Debian, if you told it to install ffmpeg, barfed a message which said "ffmpeg is deprecated, you should switch to avconv". I knew that wasn't true, and it was pretty insulting to be so brazenly lied to like that. It degraded my opinion of the Debian distro several notches. (Also, remember when the version of the Bitcoin client in the Debian repo contained hardcoded addresses of several gambling sites which it prevented you from sending to? I think it was pretty clear that Debian maintainers had a lot of power, and sometimes abused that power.) (Edit: It seems my memory is faulty, and this "modified" version of the bitcoin client was distributed with Gentoo, not Debian: https://www.coindesk.com/markets/2014/10/17/the-blacklist-debate-when-is-it-ok-to-meddle-with-bitcoins-code/ https://www.coindesk.com/markets/2014/10/17/the-blacklist-de... )
junon 3y ago
Anecdotally, libav/ffmpeg have the worst API I've ever had the displeasure of using. Getting anything working falls firmly in the realm of masochism.
- jbaber 3y ago
  My only helpful use of chatGPT was "How do I shrink this video and make a thumbnail using ffmpeg..." with some specifics. Definitely flags in there I'd never think of.
  - junon 3y ago
    It's not even the CLI. I'm talking about the C API. It's nearly unnavigable.

75 points by dosshell 3y ago

Denvercoder9 3y ago

A lot has happened since 2012. Libav is dead now, and everybody has switched back to ffmpeg.

cornstalks 3y ago
Being at the VDD conference when the libav and FFmpeg developers got together in a single room and agreed to come together and elected leadership and stuff was a really cool experience. I knew libav wasn’t really alive but when Diego said “It’s dead” it really hit me that the libav/FFmpeg drama really might be coming to a close finally. JB, when’s the next VDD?
- derdlick 3y ago
  It's sad that there aren't any alternatives to ffmpeg. It could have been a mutually beneficial relationship if they dropped the antagonism and uncooperative behaviors. Instead they just essentially killed libav.
  - rbultje 3y ago
    It's like saying it would be good if there were two competing projects writing something akin to the Linux kernel. It's just not true. The mutually beneficial thing is to have one project where all developers are happy to work together. This is obviously idealized, but FFmpeg vs. Libav was 10x worse than what we have today. Imagine how Intel or Nvidia would contribute (either to the broken-up Linux or broken-up FFmpeg) new drivers or new hardware codec integration if there was competition. It would be a horrible end user experience.
    - derdlick 3y ago
      I don't use intel or nvidia, nor really care if they are only willing to cooperate with homogenius ecosystems. Open source developers seem to treat their own little parts of the stack as their fiefdoms, afraid any competition. Then, eventually, someone figures out they can leverage that position against the user. It's toxic, and for some reason, is heavily promoted by hackernews types. It doesn't hurt anyone if someone works on their own project seperate from everyone else. Anyone that develops code is contributing, no matter where that code goes.
    - duskwuff 3y ago
      > It's like saying it would be good if there were two competing projects writing something akin to the Linux kernel. It isn't even that. ffmpeg and libav were two competing forks of the exact same project, not two distinct projects working to implement the same thing.
      - rany_ 3y ago
        > It isn't even that. ffmpeg and libav were two competing forks of the exact same project, not two distinct projects working to implement the same thing. But given enough time they would become very distinct.
        duskwuff 3y ago
        The actual history of the projects doesn't bear that theory out. Aside from the rename itself and a couple of minor API changes, the projects stayed pretty close together, and a lot of patches got copied between the pair. ffmpeg is a fairly complex project which deals with a number of esoteric topics (audio/video file formats, compression, processing, etc). The number of open-source developers who are qualified to work on it, and who have the time and inclination to do so, is fairly limited; I suspect that there simply isn't a large enough population of those developers to support multiple actively developed projects in this space, and certainly not two as similar as ffmpeg/libav were.
        TheCycoONE 3y ago
        Patches were copied one way, and functionality was deprecated in ffmpeg but the only way to do it in libav (audio.) As someone who was writing software using the ffmpeg/libav apis it was a horrible confusing mess. Since distros were split you had to support both and the each had different quirks. It was a dark time that I'm glad is over.
    - yjftsjthsd-h 3y ago
      > It's like saying it would be good if there were two competing projects writing something akin to the Linux kernel. It's just not true. No, I think it actually can be true. For example, since you point out Linux, the world is better for having FreeBSD, because FreeBSD does things that Linux can't (ZFS in-tree) or won't (combined base OS, not just a kernel). Note that this works when there's a significant difference; if we start with a fork of the exact same code, it'll need a real driver to matter (example: any project acquired by Oracle and immediately forked by the community).
  - aew4ytasghe5 3y ago
    Thing is, it was the libav guys who attempted a hostile takeover of ffmpeg by stealing the domain, then did a hard fork they called libav and pushed it into distros like Debian, lying about ffmpeg being deprecated and behaved in many ways massively toxic. There are walls of summaries from this horrible event. Mans Rullgard was of the guys leading the toxic mob. Not the other way around as you are implying. Source: I was involved in ffmpeg at the time and read their mailing list over those years.
    - davidjones332 3y ago
      I wanted to take a moment to dispute this rumour regarding FFmpeg and Mans Rullgard, which I believe to be unfounded and baseless. Firstly, I am proud to say that I have been contributing to the development of the SIMD optimization in the Libpostproc component of FFmpeg, specifically working on optimizing functions to take advantage of SIMD instructions on modern CPUs and thereby enhance performance and as such I have been involved in the FFmpeg community for a number of years. There have been claims of a potential hostile takeover involving Mans Rullgard. However, I have first hand experience that these rumors are completely false and are nothing more than fabrications by a toxic spinter group within the community who are "gaslighting" the good guys. In particular I remember but that an individual with a handle somewhat similiar to "aew4ytasghe5" was banned from our community due to repeated rudeness and hostility, and not for any other reason. I am not claiming this is you but it would not be a surprise to me on a personal level. I hope that this clarifies the situation and puts these rumors to rest. FFmpeg is a community-driven project that thrives on collaboration and mutual respect, and I am proud to be a part of it and it hurts me when I see toxic people attacking open source communities.
  - mschuster91 3y ago
    Audio and video codec libraries are among the most complex things there are in the software world, I'd say - even more complex than GPUs because there are only four major GPU vendors/families remaining (AMD, NVIDIA, Intel, PowerVR): - knowledge about how encoding audio and video works is rare (as it involves a ton of maths 99% of the population won't ever come close to understand), and people not bound by NDAs and thus actually able to work on FOSS projects in that area are even rarer in the first place. - they have to deal with an absolutely insane amount of different codecs and their "profiles" (aka supported features list) that are all in active use by someone or something (mpeg2 for DVDs and early DVB-T/C/S, h264 for fullhd stuff, h265 for >fullhd, AV1 for YouTube), and all the historical codecs - almost all of these have some hardware encoders with their own unique quirks which libraries have to take into account to support playback (and maintain that as well), not to mention software encoders in different versions and bugs, or error correction to deal with bitrot or transmission errors - on top of that, there's a family of container formats - although most have settled on mp4 or (in the piracy world) Matroska, there is still a lot of legacy stuff floating around - dealing with codecs means walking around on eggshells around laws and patents (DRM, the minefield that are video patents, ...) - dealing with multimedia files in general means dealing with densely packed and hard-to-parse binary structures, which is a Very Complex Thing To Do on its own and is a constant source of security issues. - supporting acceleration means even more rare knowledge and dealing with more NDAs or reverse-engineering - the APIs used to communicate with downstream clients (converters, media players, ...) are decades old grown baggage, and cleaning that up is next to impossible because the ecosystem is all so fractured, which means a ton of effort in implementations and maintenance Long-term it's infeasible to have more than one open source project... there are simply not enough capable developers around for the workload.
- jbk 3y ago
  > Being at the VDD conference when the libav and FFmpeg developers got together in a single room and agreed to come together It has been a difficult process, but we got things done, in the end... I'm glad we're past this. > JB, when’s the next VDD? This fall, I hope in Sicily. :)
  - vhiremath4 3y ago
    Noob question here - when we say libav is dead, what does that mean? Asking because doesn’t ffmpeg use libav internally?
    - cornstalks 3y ago
      ffmpeg has many internal components (avformat, avcodec, etc) but none of those are “libav”. libav was a fork of all the ffmpeg code (they took all the code, copied it, renamed their copy to libav, and changed the name of some binaries like changing the ffmpeg binary name to avconv). That fork is dead now. No one is maintaining it. The libav.org site doesn’t exist anymore.
      - vhiremath4 3y ago
        Ah thank you!

password4321 3y ago

What about gstreamer? I asked ChatGPT for an example to work in memory instead of ffmpeg with files and it just went on and on... plus the dependencies were pretty clearly most at home on Linux. Might have been my inexperience?

ilyt 3y ago
if it is just encoding/decoding ffmpeg can go entirely from stdin to stdout IIRC, provided formats support it. So for example it won't work for mp4 output as it needs to seek to write some headers (again, IIRC) when saving it.
- password4321 3y ago
  Thanks for the tip! I was hoping to combine lengthy h264 .mts video files chopped at 4GB by the video camera into one YouTube upload without duplicating on disk first. Edit: also maybe some simple filters/ML to detect anything interesting to clip and merge into a time lapse.
  - ilyt 3y ago
    Yeah forcing YT to accept it directly from ffmpeg would be the hardest part. I hit that behaviour when I tried to upload encode directly to S3 bucket, turned out only some formats worked
  - password4321 3y ago
    MoviePy is pretty committed to working with files, and I couldn't quickly figure out PyAV pts/dts for the concat even though the files were all exactly the same format.
  - cellularmitosis 3y ago
    Have you tried using a fifo file?
  - j1elo 3y ago
    Wouldn't it work if you stream the resulting video as a Youtube Live stream? You would have to set a stream up in the Youtube creator web page, in order to get a streaming key and with it, a full RTMP URL. Then in FFmpeg, use "-f rtmp://...your target url" as output. Youtube will stream a live video (which you can hide as "unlisted") and afterwards, the video will remain in the channel as a VOD.

dang 3y ago

Discussed at the time: The FFmpeg/Libav situation - https://news.ycombinator.com/item?id=4183209 https://news.ycombinator.com/item?id=4183209 - June 2012 (51 comments)

kamranjon 3y ago

I wish this post went further back and outlined Fabrice Bellards involvement in ffmpeg - his website says only "FFMPEG, the Open Source Multimedia System. I launched this project in year 2000 and led it for several years. " - I'd be curious to know more about that part of the history.

luispauloml 3y ago
You can this series of blog posts by one of the key people involved in FFmpeg: https://codecs.multimedia.cx/category/cempeg/ffhistory/ https://codecs.multimedia.cx/category/cempeg/ffhistory/ This was discussed here too: https://news.ycombinator.com/item?id=34555465 https://news.ycombinator.com/item?id=34555465

ux 3y ago

Author's here. I'm not sure why this is posted here, but please note that this was written more than 10 years ago, and a lot of things changed since then. It's important to take this article from an historical perspective, keeping in mind that it was written by someone with "interests" in the matter (as much as I wanted to be objective, let's not lie to ourselves, I was a FFmpeg developer first). The popularity of this article played an important role in "public's opinion" (it's my most popular article ever). Nowadays, even though I've been distant to the project for years now, I can say the situation changed in a good way (from my perspective). The projects are unified again because people from both sides made difficult compromises. I think it would make sense to focus on how the issue was resolved rather that why it was so bad. This fire is extinguished, let's work on keeping things as peaceful as we can. For the record, I mostly left FFmpeg development years ago. And while it wasn't the only factor, the merge effort and overall tension actually drained me pretty badly at that time. Of course, this is also true for several people from both sides, and surprising to no one the project(s) lost many developers in the process. The multimedia community is plagued with drama like this, but this one was particularly destructive. We can certainly take lessons from this, but I'll leave that to the historians.

Dalewyn 3y ago
My biggest takeaway from this fiasco was when a repo maintainer (he was libav) changed ffmpeg to libav in the Ubuntu (or was it Debian?) repositories. That was a lesson that distros and their repositories are walled gardens just like the various application stores over in the mobile world, curated strictly at the whims of certain individuals or organizations. It gave me a newfound appreciation for the "just find, install and run whatever whenever wherever" gung ho attitude found in Windows (and to a lesser extent MacOS and Android).
- bombcar 3y ago
  Many people (myself included!) were first amazed by how easy and how much software was @ “just there” for Linux - and apt-get or rpm or emerge and you have what you want. It’s much later that you realize that someone is doing the work to keep those working, and decisions are being made all the time about which version, which project, etc. The one I first really noticed was MySQL being silently replaced with MariaDB.

LeoPanthera 3y ago

The thing I most remember about this piece of history was that Debian, if you told it to install ffmpeg, barfed a message which said "ffmpeg is deprecated, you should switch to avconv". I knew that wasn't true, and it was pretty insulting to be so brazenly lied to like that. It degraded my opinion of the Debian distro several notches. (Also, remember when the version of the Bitcoin client in the Debian repo contained hardcoded addresses of several gambling sites which it prevented you from sending to? I think it was pretty clear that Debian maintainers had a lot of power, and sometimes abused that power.) (Edit: It seems my memory is faulty, and this "modified" version of the bitcoin client was distributed with Gentoo, not Debian: https://www.coindesk.com/markets/2014/10/17/the-blacklist-debate-when-is-it-ok-to-meddle-with-bitcoins-code/ https://www.coindesk.com/markets/2014/10/17/the-blacklist-de... )

junon 3y ago

Anecdotally, libav/ffmpeg have the worst API I've ever had the displeasure of using. Getting anything working falls firmly in the realm of masochism.

jbaber 3y ago
My only helpful use of chatGPT was "How do I shrink this video and make a thumbnail using ffmpeg..." with some specifics. Definitely flags in there I'd never think of.
- junon 3y ago
  It's not even the CLI. I'm talking about the C API. It's nearly unnavigable.