7 ms·

Michael is just amazing. I once had a bug with ffmpeg which he helped me pin down on IRC and then produced a patch for it immediately. I was disappointed of ho

by zimbatm 11y ago

Michael is just amazing. I once had a bug with ffmpeg which he helped me pin down on IRC and then produced a patch for it immediately. I was disappointed of how aggressive the libav guys where during the fork. They changed the content of ffmpeg.org (which they had legitimate access to) to claim that libav was now the new name of the project. Then they replaced the ffmpeg package in Debian with their own version. It's entirely possible to maintain both packages in Debian with the alternatives framework. This whole false dichotomy and calling ffmpeg the fork is not helpful in my opinion. So I'm glad that ffmpeg is getting it's package back. Forks are good and should stand on their own merit instead of doing politics like that.

camperman 11y ago
When I was told that ffmpeg was deprecated by libav, I immediately checked whether this was the truth. It wasn't. Bye bye libav - forever. Don't ever lie to your end users.
- plorkyeran 11y ago
  The libav version of the command line tool named "ffmpeg" was in fact deprecated and has since been removed entirely. The message was confusing due to that there are several different things named "ffmpeg", but it was not untrue.
  - lukaslalinsky 11y ago
    I always thought the message was intentionally confusing.
    - baldfat 11y ago
      It was untrue. It was a fork and they acted like ffmpeg was no longer being developed. To me this was a horrible way to fork something.
      - acpmasquerade 11y ago
        This was what similar happened in our case as well. My fellow developer had convinced me that FFmpeg development was stopped libav was the successor. So, its time we need to study few more and determine what is better for a production, consumer centric application.
  - dtech 11y ago
    An earlier version of the message stated that development on ffmpeg had stopped. How can you interpret this in any other way than an effort to spread FUD about ffmpeg by libav?...
  - camperman 11y ago
    You're right but I was unaware of the fork. I installed Ubuntu 14.04 on my workstation, ran ffmpeg to do something and got a message which said: "This program is not developed anymore and is only provided for compatibility. Use avconv instead." Five minutes googling and I realized there had been a (somewhat acrimonious) fork. So my interpretation was quite natural: the libav developers and/or the Ubuntu maintainers were being dicks to the original project. If they really wanted to be clear they could have said something like: "This is a deprecated wrapper around avconv, part of libav. It is not part of the ffmpeg project. See <url> for details." How hard would that have been?
    - jsprogrammer 11y ago
      >How hard would that have been? Probably pretty rough on the ego.
    - mandelbulb 11y ago
      This. Ubuntu was the main reason why people assumed ffmpeg became deprecated, in other words libav just got more vocal PR/support. Gentoo initially followed the mainstream but changed the default flag to ffmpeg a few months ago.
    - roghummal 11y ago
      It's something in between. "The ffmpeg program is only provided for script compatibility and will be removed in a future release. It has been deprecated in the Libav project to allow for incompatible command line syntax improvements in its replacement called avconv (see Changelog for details). Please use avconv instead."
      - kierank 11y ago
        I won't take a position on this but the message you quote is a revised version that was put in place many years later after numerous user complaints about confusion.
        roghummal 11y ago
_delirium 11y ago
> It's entirely possible to maintain both packages in Debian with the alternatives framework. The Debian security team vetoed this option, which is why the recent discussion was choosing between, 1) bring back ffmpeg and remove libav, or 2) keep libav and do not bring back ffmpeg (option 1 was chosen). They don't want to support security patches for both, and for all combinations of software that might use either one.
- listic 11y ago
  > The Debian security team vetoed this option On what grounds?
  - _delirium 11y ago
    The high frequency of security issues in both packages makes it a significant burden to support both of them simultaneously: https://lists.debian.org/debian-devel/2014/02/msg00668.html https://lists.debian.org/debian-devel/2014/02/msg00668.html There appear to also be issues with frequent soname bumps: https://lists.debian.org/debian-devel/2014/02/msg00651.html https://lists.debian.org/debian-devel/2014/02/msg00651.html
  - deleted 11y ago
    [deleted]
  - davidgerard 11y ago
    This is answered in the article this post is about.
- zimbatm 11y ago
  Good point. Reality is more fine-grained than the account of my own perception. Do you know if contrib packages are also getting security updates ? If no then why didn't they just move the ffmpeg package there. To me it felt like the really wanted the ffmpeg package to be virtual and pointing to libav.
  - yrro 11y ago
Daviey 11y ago
> It's entirely possible to maintain both packages in Debian with the alternatives framework. It isn't quite as simple as this when we are talking about libraries... Which one is used by other packages to build against? Whichever is used, has to become the runtime dependency.
- davmre 11y ago
  Replacing runtime dependencies is doable for dynamically linked libraries as long as they provide the same ABI, e.g., you can swap out BLAS implementations in this way. Obviously static linking is a different story.
  - ploxiln 11y ago
    They don't provide the same ABI (just mostly the same API), and in fact they have "so bumps" all the time, which means they break ABI compatibility with themselves all the time and need to increment the shared library major number.
perlgeek 11y ago
> It's entirely possible to maintain both packages in Debian with the alternatives framework. It is, but it is also a big maintenance burden, in particular for the security team.

by zimbatm 11y ago

camperman 11y ago

When I was told that ffmpeg was deprecated by libav, I immediately checked whether this was the truth. It wasn't. Bye bye libav - forever. Don't ever lie to your end users.

plorkyeran 11y ago
The libav version of the command line tool named "ffmpeg" was in fact deprecated and has since been removed entirely. The message was confusing due to that there are several different things named "ffmpeg", but it was not untrue.
- lukaslalinsky 11y ago
  I always thought the message was intentionally confusing.
  - baldfat 11y ago
    It was untrue. It was a fork and they acted like ffmpeg was no longer being developed. To me this was a horrible way to fork something.
    - acpmasquerade 11y ago
      This was what similar happened in our case as well. My fellow developer had convinced me that FFmpeg development was stopped libav was the successor. So, its time we need to study few more and determine what is better for a production, consumer centric application.
- dtech 11y ago
  An earlier version of the message stated that development on ffmpeg had stopped. How can you interpret this in any other way than an effort to spread FUD about ffmpeg by libav?...
- camperman 11y ago
  You're right but I was unaware of the fork. I installed Ubuntu 14.04 on my workstation, ran ffmpeg to do something and got a message which said: "This program is not developed anymore and is only provided for compatibility. Use avconv instead." Five minutes googling and I realized there had been a (somewhat acrimonious) fork. So my interpretation was quite natural: the libav developers and/or the Ubuntu maintainers were being dicks to the original project. If they really wanted to be clear they could have said something like: "This is a deprecated wrapper around avconv, part of libav. It is not part of the ffmpeg project. See <url> for details." How hard would that have been?
  - jsprogrammer 11y ago
    >How hard would that have been? Probably pretty rough on the ego.
  - mandelbulb 11y ago
    This. Ubuntu was the main reason why people assumed ffmpeg became deprecated, in other words libav just got more vocal PR/support. Gentoo initially followed the mainstream but changed the default flag to ffmpeg a few months ago.
  - roghummal 11y ago
    It's something in between. "The ffmpeg program is only provided for script compatibility and will be removed in a future release. It has been deprecated in the Libav project to allow for incompatible command line syntax improvements in its replacement called avconv (see Changelog for details). Please use avconv instead."
    - kierank 11y ago
      I won't take a position on this but the message you quote is a revised version that was put in place many years later after numerous user complaints about confusion.
      - roghummal 11y ago

_delirium 11y ago

> It's entirely possible to maintain both packages in Debian with the alternatives framework. The Debian security team vetoed this option, which is why the recent discussion was choosing between, 1) bring back ffmpeg and remove libav, or 2) keep libav and do not bring back ffmpeg (option 1 was chosen). They don't want to support security patches for both, and for all combinations of software that might use either one.

listic 11y ago
> The Debian security team vetoed this option On what grounds?
- _delirium 11y ago
  The high frequency of security issues in both packages makes it a significant burden to support both of them simultaneously: https://lists.debian.org/debian-devel/2014/02/msg00668.html https://lists.debian.org/debian-devel/2014/02/msg00668.html There appear to also be issues with frequent soname bumps: https://lists.debian.org/debian-devel/2014/02/msg00651.html https://lists.debian.org/debian-devel/2014/02/msg00651.html
- deleted 11y ago
  [deleted]
- davidgerard 11y ago
  This is answered in the article this post is about.
zimbatm 11y ago
Good point. Reality is more fine-grained than the account of my own perception. Do you know if contrib packages are also getting security updates ? If no then why didn't they just move the ffmpeg package there. To me it felt like the really wanted the ffmpeg package to be virtual and pointing to libav.
- yrro 11y ago

Daviey 11y ago

> It's entirely possible to maintain both packages in Debian with the alternatives framework. It isn't quite as simple as this when we are talking about libraries... Which one is used by other packages to build against? Whichever is used, has to become the runtime dependency.

davmre 11y ago
Replacing runtime dependencies is doable for dynamically linked libraries as long as they provide the same ABI, e.g., you can swap out BLAS implementations in this way. Obviously static linking is a different story.
- ploxiln 11y ago
  They don't provide the same ABI (just mostly the same API), and in fact they have "so bumps" all the time, which means they break ABI compatibility with themselves all the time and need to increment the shared library major number.

perlgeek 11y ago

> It's entirely possible to maintain both packages in Debian with the alternatives framework. It is, but it is also a big maintenance burden, in particular for the security team.