Mailing List Archive

Brent Busby posted on Wed, 18 Feb 2015 22:19:37 -0600 as excerpted:

> With all the arguing I see in the forums lately about libav versus
> ffmpeg, I thought I'd ask an ffmpeg question of a different nature:
>
> Upstream, the ffmpeg people are releasing 2.5 as "stable." Some people
> (who I'm not going to argue with, since I don't really have a position
> on it myself) say the ffmpeg developers are reckless. However, I notice
> that most other distros are at least shipping 2.2 (perhaps with lots of
> distro patches to fix problems?).
>
> Gentoo's stable ffmpeg is currently 1.2.6, a fully maintained (i.e., not
> defunct or deprecated) branch with ffmpeg upstream, apparently
> maintained for really conservative users.
>
> All of this has me wondering...should I unmask? Both 2.2 and 2.5 are
> available in Portage as ~amd64 ebuilds. Is anyone here doing this? Does
> it unleash the hounds of hell (or the UNIX equivalent, lots of
> unpleasant segfaults and codec problems)? I'm mostly wanting better
> Bluray/WMV3/VC-1 support, but I don't know how that stands between the
> various 1.2/2.2/2.5 branches.
>
> From talking to people who don't run Gentoo, I've found that it has a
> reputation for being bleeding-edge, but at times, I've found to the
> contraty that it can actually sometimes be overcautious, making it hard
> to tell if you're missing out on things other distros are enjoying
> because your upgrades are masked. Sometimes, package versions will stay
> masked for months or years just because nobody got around to marking
> them stable for amd64 and not because of any actual bugs.
>
> Anybody running ffmpeg 2.x without issues? If so, which one...2.2 or
> 2.5?

[.Adding this note after I wrote the below. I think it ended up reading
harsher than I intended. I know people choose stable for a reason and I
really do respect that. Those people simply aren't me, nor that reason
mine... and that certainly comes out in the below. But no personal, or
even whole-group, offense intended. It's just not me. But it's your
machine, not mine, and gentoo wouldn't be gentoo if it didn't respect
your ultimate control of your machine, neither would I be me in the same
case. So, umm... Read the below with that in mind. =:^) ]

I think what you actually want to know (which isn't what you asked), is
if anyone running _sta(b)le_ amd64, is running ffmpeg 2.x without issues.

Because people running ~amd64, including me, if they're current (I am),
are running ffmpeg-2.5.4.

And in general, I've not seen issues.

However, that's because the various other apps also in ~amd64 have in
general already been updated to work with the newer ffmpeg.

Which is the problem with stale^h^hble amd64, and sta(b)le gentoo in
general. The newer ffmpeg can't be unmasked to sta(b)le until pretty
much everything else in sta(b)le has been updated to work with it as well.

And in fact, whenever there's something that has gotten as far behind on
stable as ffmpeg has, in particular, for stuff like gcc, it's very likely
the same general problem. On gentoo, for packages like gcc in
particular, even ~amd64 (and ~arch in general) is generally quite behind,
because before it's unmasked to ~arch, they want to ensure that all other
packages (at the same ~arch) level have been patched to build with it.
Which means it takes "forever" to unmask even to ~arch, because of all
those other packages that have to be either updated first, or patched to
build with the new gcc. Then when all that is done and it hits ~arch,
the process starts over for sta(b)le; all those patched packages have to
be sta(b)le keyworded before gcc itself can be sta(b)le keyworded.

And yes, sometimes that does mean "stable" is "stale", no two ways about
it. But it's a choice you make...

But at least gentoo does make it real easy to package.keyword specific
packages if you like, so you can be sta(b)le on most things while
choosing to try arch or even masked versions if you dare.

If you like you can do an equery depends ffmpeg, and see which packages
that you actually have installed depend on it. You can then research
each one to see if the version you currently have merged can function
with the newer ffmpeg, and if not, you can of course package.keyword it
~arch at the same time.

With a bit of luck all the packages you have installed are already
updated and it'll "just work" (perhaps with a rebuild of some of them)
for you. If you're not that lucky, but still somewhat lucky, they've at
least been updated with blockers or version ranges, so if you go to
install the newer ffmpeg, portage will tell you which packages you have
to keyword-unmask in ordered to proceed.

Of course you also risk that they've not been updated yet, and simply
quit working with no explanation, until you figure it out and unmask them
so you get the newer version of them too.

But at least with an equery depends ffmpeg, you can see how many packages
you are risking, and decide whether it's worth the hassle from there, or
if it's too much to risk/hassle and you prefer to wait for the full
stable update after all.

Of course another alternative is to "Dear Interwebs" the solution. You
can post your equery results here and see if there's enough other people
on sta(b)le but running a newer/package.keyworded ffmpeg with those
packages as well, to compare notes. =:^)

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

On Thu, 19 Feb 2015, Duncan wrote:

> [.Adding this note after I wrote the below. I think it ended up
> reading harsher than I intended. I know people choose stable for a
> reason and I really do respect that. Those people simply aren't me,
> nor that reason mine... and that certainly comes out in the below.
> But no personal, or even whole-group, offense intended. It's just not
> me. But it's your machine, not mine, and gentoo wouldn't be gentoo if
> it didn't respect your ultimate control of your machine, neither would
> I be me in the same case. So, umm... Read the below with that in
> mind. =:^) ]

Well, it's mostly stable. I have a rather long package.keywords file
full of things I've allowed ~amd64 on, and I've been careful about which
packages those are. Some are even live ebuilds pulled from GIT.

The main reason I'm running stable is because this machine is used for
audio recording and music production, and I need it to work. I have
quite a bit of experience in chasing down problems, but I'd like to keep
that to a minimum.

And no, I don't want a binary distro. Those have their own problems.

> I think what you actually want to know (which isn't what you asked), is
> if anyone running _sta(b)le_ amd64, is running ffmpeg 2.x without issues.
>
> Because people running ~amd64, including me, if they're current (I am),
> are running ffmpeg-2.5.4.
>
> And in general, I've not seen issues.

Ok, well that's basically what I was wanting to know, since it was the
stability of ffmpeg 2.5 itself I was wondering about.

> However, that's because the various other apps also in ~amd64 have in
> general already been updated to work with the newer ffmpeg.
>
> Which is the problem with stale^h^hble amd64, and sta(b)le gentoo in
> general. The newer ffmpeg can't be unmasked to sta(b)le until pretty
> much everything else in sta(b)le has been updated to work with it as well.

Yes, for that reason, I will very likely end up keeping 1.2 for awhile.
I only unmask when it's possible to do so without a lot of complication.

> And in fact, whenever there's something that has gotten as far behind on
> stable as ffmpeg has, in particular, for stuff like gcc, it's very likely
> the same general problem. On gentoo, for packages like gcc in
> particular, even ~amd64 (and ~arch in general) is generally quite behind,
> because before it's unmasked to ~arch, they want to ensure that all other
> packages (at the same ~arch) level have been patched to build with it.
> Which means it takes "forever" to unmask even to ~arch, because of all
> those other packages that have to be either updated first, or patched to
> build with the new gcc. Then when all that is done and it hits ~arch,
> the process starts over for sta(b)le; all those patched packages have to
> be sta(b)le keyworded before gcc itself can be sta(b)le keyworded.
>
> And yes, sometimes that does mean "stable" is "stale", no two ways about
> it. But it's a choice you make...

I know...and I can wait, if it's going to cause a lot of interdependency
problems with other packages. I've found that stuff does usually make
it to stable eventually, so I don't really have a cow about it.

> But at least gentoo does make it real easy to package.keyword specific
> packages if you like, so you can be sta(b)le on most things while
> choosing to try arch or even masked versions if you dare.

This is one of the biggest reasons I run Gentoo instead of a binary
distro. Debian-based distros have APT-pinning, but it doesn't work
nearly as well, because binary packages have already been compiled
against the libraries they were meant for. You can do your own
backports, but that's even more special treatment to hassle you with.
Most of the time, if you unmask a package on Gentoo, it just compiles
against what you have, and it just works, now, and after future system
upgrades.

> If you like you can do an equery depends ffmpeg, and see which packages
> that you actually have installed depend on it. You can then research
> each one to see if the version you currently have merged can function
> with the newer ffmpeg, and if not, you can of course package.keyword it
> ~arch at the same time.

Mostly I just wondered if anyone could tell me if ffmpeg 2.5 itself is
fundamentally broken in some way. Sounds like it's fine...

--
+ Brent A. Busby + "We've all heard that a million monkeys
+ Sr. UNIX Systems Admin + banging on a million typewriters will
+ University of Chicago + eventually reproduce the entire works of
+ James Franck Institute + Shakespeare. Now, thanks to the Internet,
+ Materials Research Ctr + we know this is not true." -Robert Wilensky

Brent Busby posted on Thu, 19 Feb 2015 01:38:12 -0600 as excerpted:

> Mostly I just wondered if anyone could tell me if ffmpeg 2.5 itself is
> fundamentally broken in some way. Sounds like it's fine...

Yes. What's broken, for both ffmpeg and libav, is that they don't keep
the same API around very long. New versions thus break everything that
depends on them for awhile, until those package in turn are upgraded to
deal with the new API.

Which wouldn't be a big deal if it were only a handful of packages
depending on ffmpeg/libav. But when pretty much every audio/visual
application out there does... it's not just a big deal, it's a *HUGE*
deal.

FWIW, while I'm an ffmpeg user myself, the libav upstream has at least
realized the problem to some extent, and has slowed down the dropping of
older APIs a bit, leaving them around for a version or two even as they
continue to move on with new ones. But I believe that's a fairly new
policy, only the last couple of release series, and it's limited to only
a release series or two in "backward compatibility mode" at once, so it's
still a problem for the slower moving packages depending on it, both
because it's new enough that the slower moving packages haven't had a
chance to absorb it yet, and because it's limited to only a release or
two on a fast-moving base, such that the problem will still exist for the
packages depending on it that are moving slow enough.

This all came out in the gentoo-dev list ffmpeg/libav default
discussion. Truth is, ffmpeg may well be best for ~arch users for
several reasons including more flexibility and best of both worlds
leading edge development policies, but sta(b)le users may actually be
better with libav, at least as this upstream libav policy takes hold,
given that they're at least making /some/ efforts toward API stability
now, which can only help newer versions reach sta(b)le faster.

Which means libav may actually be the better gentoo profile default after
all, despite apparent user preference to ffmpeg, because leading edge
users are more likely to be willing to change the profile default, while
sta(b)le users in general prefer that it "just work" with the least
disturbance, at least after they've done their basic setup.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman