Re: ffmpeg vs. libav
Quoting The Wanderer (wanderer@fastmail.fm):
> On 07/08/2015 at 02:38 PM, David Wright wrote:
>
> > Quoting Nicolas George (george@nsup.org):
>
> > and to summarise the release notes:
> >
> > Debian wheezy [...]: ffmpeg has been replaced by [...]
> > (libav-tools). It provides [...] and prepares an upgrade path for
> > existing application packages. installation of packages from
> > third-party repositories should not be necessary.
> >
> > So if Debian has moved forward from ffmpeg to libav, then using
> > ffmpeg is "going back", unless you mean something else by those two
> > words.
>
> The error here is in thinking of the move from FFmpeg to libav as being
> "forward". "Back" is not the opposite of "forward" in all senses; the
> full opposite of "forward" would be "backward".
Let's skip that.
> The switch from FFmpeg to libav was more of a move sideways, from one
> fork of a project (the original) to another. Switching from the latter
> to the former is a move "back" only in the sense of going to a place
> we've been before; it's not a move "backward" in the sense of going from
> newer/better to older/worse.
>
> When the switch from FFmpeg to libav was made, the people who decided to
> make it did believe that it would be a move forward, and that the libav
> fork would be a better option as development continued than the original
> FFmpeg was or would continue to be.
>
> As the discussion in the thread which I linked to has concluded, this
> does not appear to have held true in practice. With what we now know
> about both projects and with the benefit of hindsight about their
> development and adoption, it therefore makes sense to switch back to
> FFmpeg, specifically because that is not a move backward.
I would agree with all this. But the words emitted by wheezy's ffmpeg,
even now, but particularly as they were, can give the Debian user (and
gave me in 2013) the impression that ffmpeg->libav was an improvement,
an upgrade, a move away from "crippled multimedia support".
Paragraph 2.3.5 (quoted) may not say that (and a lawyer would shred this
argument) but, after reading ffmpeg's words, that's a reasonable
interpretation of2.3.5. (That *is* my opinion.)
> > BTW, the OP didn't say "getting stuck" but "stuck going back". Stuck
> > has the sense of "to fail to proceed or advance" and it often
> > expresses an emotion of defeat at the prospect.
>
> It can have that sense, but its core sense is more basic, and that's not
> how I read it in this case.
>
> In this case, I interpret "stuck going back to ffmpeg" not as meaning
> "having to go back to older and presumably worse" but as meaning
> something more like "having to put in the extra work to get the better
> option which used to be easily available". Again, "back" in a sense of
> "to a place where we've been before" rather than a sense of "to
> something older and presumably worse".
Agreed. Back in 2013, I put away "man ffmpeg" (currently 4291 lines)
and got out "man avconv" (4255 lines on wheezy, but now 7142 lines).
Much of it is incomprehensible to me. A "differences" document might
have been useful.
Having been led to believe that avconv was "better", I would not have
been best pleased with being "stuck going back" if avconv wasn't
working for me.
Cheers,
David.
Reply to: