Announcement

Collapse
No announcement yet.

The FFmpeg vs. Libav War Continues In Debian Land

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by Akka View Post
    I get the impression most project that use ffmpeg or libav is recommending ffmpeg. The most famous user that only used libav was mplayer2. Now mplayer2 is gone and replaced with MPV and I get the impression MPV is recommending the user to use ffmpeg over libav.
    What I know about ffmpeg is this not surprising. The ffmpeg people must have been patching every known patch into their code as well as twisted APIs around just to keep everything together and for exactly this kind of outcome - to overcome the libav fork.

    While this kind of effort is amusing to watch and positive to the users of ffmpeg, who get both branches in one if you so will, do I stay sceptic. It is as if a kid is trying to build a tower with all its bricks just to see how high it can go before it all collapses. And I have been there, done it and also had to clean up the mess afterwards. It is a fun experience, but I do not need to take part in it again.

    I can understand what the libav people are doing and I do not need every new feature that has come up somewhere. There is always something new somewhere and people are making the mistake to forget this and only to measure the two projects by who is ahead of the other, when they are both running behind trends. And while not every new trend is also the best trend does the competition between the projects create a fall sense of what is needed and people start to believe they need ffmpeg, because they need the latest features. I then begin to think about what I do not need.

    Comment


    • #22
      Originally posted by Scimmia View Post
      The leader made a decision not to make wholesale changes to absolutely everything related to development. That's what leaders are for, making these decisions. Governing by committee is a losing proposition all around.

      One. One root distribution made the change, that's all, and that's only because the Debian maintainer was one of the butt-hurt devs.

      Maintainers are wise to look at the problems that the change will cause and not make a change based on emotions.
      Sorry, but I just do not see it that way.

      Comment


      • #23
        Originally posted by kaprikawn View Post
        What do the other major distros use out of interest, FFmpeg or libav?
        Fedora doesn't ship ffmpeg due to legal issues (patents)
        RPMFusion ships ffmpeg.

        Comment


        • #24
          Originally posted by zxy_thf View Post
          Fedora doesn't ship ffmpeg due to legal issues (patents)
          RPMFusion ships ffmpeg.
          Gentoo and OpenSuSE switched to libav as well if I am not mistake.

          Comment


          • #25
            As a Debian user, I use Marillat's debmultimedia repo to restore ffmpeg. It has just worked better for me when using the CLI utility, Handbrake, mpv, etc.
            I do understand why the Libav devs decided to fork, but personal sympathies aside, I'm just going to use the alternative that works better for me.

            Opposition brings concord. Out of discord comes the fairest harmony. -- Heraclitus
            It's funny that this (automatic?) signature showed up in one of Niedermayer's replies.

            Comment


            • #26
              Originally posted by sdack View Post
              What I know about ffmpeg is this not surprising. The ffmpeg people must have been patching every known patch into their code as well as twisted APIs around just to keep everything together and for exactly this kind of outcome - to overcome the libav fork.

              While this kind of effort is amusing to watch and positive to the users of ffmpeg, who get both branches in one if you so will, do I stay sceptic. It is as if a kid is trying to build a tower with all its bricks just to see how high it can go before it all collapses. And I have been there, done it and also had to clean up the mess afterwards. It is a fun experience, but I do not need to take part in it again.

              I can understand what the libav people are doing and I do not need every new feature that has come up somewhere. There is always something new somewhere and people are making the mistake to forget this and only to measure the two projects by who is ahead of the other, when they are both running behind trends. And while not every new trend is also the best trend does the competition between the projects create a fall sense of what is needed and people start to believe they need ffmpeg, because they need the latest features. I then begin to think about what I do not need.
              Actually, as a developer, it's painful simply because libav has never been well distributed. When they broke ABI with FFmpeg, trying to maintain bridge code constantly broke two of my sandbox applications, almost with every update.

              People are not judging the two based on feature scale either. There's a certain amount of functionality and stability about FFmpeg that is not currently there in libav. I've not personally experienced this but others certainly have.

              I'm also pretty sure you didn't read the original posts about why the fork happened. There was very little technical reasoning behind any of it, if any at all. While the fork did cause some things to happen, when you look at it in general, none of it has been big enough to justify breaking ABI or forking from a technical standpoint.

              Also, remember one side has been at least trying to maintain a layer for compatibility with the other, while the other plain and jane doesn't give a fuck.

              Comment


              • #27
                I like to use ffmpeg because I like to be on the bleeding edge. Also there's been a few times where ffmpeg would throw in an almost completely broken implementation of a decoder, have libav take it and try to make it functional, and then they ignore the ffmpeg patch that fixes it. It actually resulted in a very broken implementation in libav for a while, because everyone had to review everything before applying it. (if I remember correctly)

                The thing about ffmpeg is it seems to break and fix itself fast enough that for the most part no one (unless they're like me and running the latest unstable) we get a lot more features that are stable enough for the average person to use.

                Comment


                • #28
                  Originally posted by profoundWHALE View Post

                  The thing about ffmpeg is it seems to break and fix itself fast enough that for the most part no one (unless they're like me and running the latest unstable) notices. In the end, we get a lot more features that are stable enough for the average person to use.
                  That was weird, a chunk of text disappeared.

                  Comment


                  • #29
                    Originally posted by discordian View Post
                    [...]To me, hte sheer size of ffmpeg is its problem - just dont use it unless its for media players. "Standard" stuff like JPEG and PNG should never be handled by it, and a plain OS shouldnt depend on ffmpeg for that reason.
                    Actually ffmpeg isn't that large, routines such as the fft are shared between codecs. It's just that there was a time when every company wanted their own audio and video codec and ffmpeg supports nearly all of them. Remember Real Video? Remember Sorensen?

                    Comment


                    • #30
                      Originally posted by computerquip View Post
                      Actually, as a developer, it's painful simply because libav has never been well distributed. When they broke ABI with FFmpeg, trying to maintain bridge code constantly broke two of my sandbox applications, almost with every update.

                      People are not judging the two based on feature scale either. There's a certain amount of functionality and stability about FFmpeg that is not currently there in libav. I've not personally experienced this but others certainly have.

                      I'm also pretty sure you didn't read the original posts about why the fork happened. There was very little technical reasoning behind any of it, if any at all. While the fork did cause some things to happen, when you look at it in general, none of it has been big enough to justify breaking ABI or forking from a technical standpoint.

                      Also, remember one side has been at least trying to maintain a layer for compatibility with the other, while the other plain and jane doesn't give a fuck.
                      No, of course not. I did not want to read any of it. But I was there and reasons were given, and these were obvious. You do not have to read every flame and troll to know what is going on. The code was lingering in an alpha state for a long time with more and more people depending on ffmpeg while the project kept sucking up codecs from all around without giving much thought to stability, sanity and security. The consent of the leadership was that as long as it compiles and runs is it not broken. It was as if everyone was waiting for something to happen, either for somebody to cheekily announce version 1.0, or to get serious and to start cleaning up the mess before moving out of alpha, and then suddenly no fucks were given and shit hit the fan.

                      And why would you expect anyone to care when the leaders never cared for any of it in the first place? What would be the point of it? The libav project could not make a change had they kept doing it in the same way. Nor can you blame them for it. We are not living in the stone age of software development any more.

                      Comment

                      Working...
                      X