ffmpeg: Update to 0.10

[ocroquette@…]

Seamless upgrade to ffmpeg 0.10

[ranauei@…]

Moved to sha256/rmd160, removed unnecessary configure parameters and other fixes

[ryandesign@…]

As in #32594, the reason we weren't updating ffmpeg was that all programs using ffmpeg need to be tested for compatibility with this new version.

[ocroquette@…]

Makes sense, but on the other end, the ffmpeg version currently in MacPorts is really outdated, and many people out there care only about ffmpeg, not about the other tools based on it. Is there no technical solution to this ? Is it possible for instance to have a separate port for the 2 different scenarios ?

[markus.doits@…]

Cc Me!

[markus.doits@…]

imo, the port simply should be updated. If things break with other programs, it is time to fix them there. There is no other solution to have a clean and up to date macports economy.

Of course, when things break, there will be some annoyance. But if it breaks for a lot of people, there will be someone to fix it (if there's no active maintainer).

Another idea: an intermediate port "ffmpeg-new" could be introduced, which "provides ffmpeg". I don't know if such thing exists for macports, but if a user wants to install something that depends on "ffmepg", but has installed the port "ffmpeg-new" which "provides ffmpeg", it should mark the dependency "ffmpeg" as satisfied.

Users and maintainers could then be urged to use "ffmpeg-new" to build new ports and old ports should be tested and be updated to compile with "ffmpeg-new" (maybe having a variant +ffmpeg_new to explicitly depend on "ffmpeg-new" on the meantime). After some not so long deadline (max 3 months?), announced clearly for everyone, the old legacy port ffmpeg is simply updated to 0.10 and "ffmpeg-new" is removed. Maintainers had time to test and update their ports.

And users using "ffmpeg-new" (who do this on purpose and know there will be other broken ports) will see if their other installed ports break, and file a bug for them. With this way, some errors can be catched before ffmpeg is updated "for the public".

Third idea: provide a "ffmpeg-new" port with renamed binaries and libraries etc. (or installed with another prefix), that does not interfere with the legacy ffmpeg. So both things can be installed together, old ports can continue to depend on "ffmpeg", new ports can depend and compile with "ffmpeg-new" (or continue to use the legacy ffmpeg). This looks like the easiest solution.

All approaches require a quite amount of work, but this comes from lagging behind several versions. Updates should be published fast. At least, if macports wants to provide up to date software (which I assume it wants, right?).

[abarnert@…]

Isn't there already an ffmpeg-devel port that can be used for this purpose, instead of creating an ffmpeg-new?

It's apparently at 20111104 right now, which is pre-0.9, but I don't think there would be objections to updating it the way there are to the main port. Once you've got that done, you can start looking at adding a +ffmpeg-devel variant to a couple ports that depend on ffmpeg to demonstrate that it works, and then people will probably be more receptive to updating the main port sooner rather than later.

[abarnert@…]

By the way, after applying this patch, I can build x86_64 only, but I can't build universal (Lion 10.7.2 with Xcode 4.2): I got a "Ran out of registers during register allocation!" fatal error during i386 libavcodec/h264_cabac.o. I'll attach the build log.

[abarnert@…]

+universal i386 build failure after patching with Portfile2.diff

[abarnert@…]

Another i386 build failure even after restoring apple-gcc-4.2 (after reading #30137).

[abarnert@…]

More data:

After applying Portfile2.diff, then restoring apple-gcc-4.2 (removed by the patch), the i386 build still failed (see ffmpeg-3.log). Adding "--disable-mmx --disable-mmx2 --disable-sse --disable-ssse3 --disable-amd3dnow --disable-amd3dnowext" to the "lappend merger_configure_args(i386)" line, which should have an equivalent effect to the no_mmx variant of ffmpeg-devel but only for i386, got me farther, but it still failed, and at this point, I give up.

But meanwhile, updating the ffmpeg-devel patch by just bumping the date, git-branch, and checksum to match the 0.10 tag worked with no other changes (and without using the no_mmx variant).

Plus, it looks like you don't need a new variant to get your second idea: many ports already depend on "path:lib/libavcodec.dylib:ffmpeg", which can be supplied by either ffmpeg or ffmpeg-devel, but defaults to ffmpeg if it needs to pull one in. So, that's already there. And at least one of them works even after bumping ffmpeg-devel to the 0.10 tag.

So, I'd suggest withdrawing this patch and instead submitting a patch to update ffmpeg-devel, and there's your second idea done.

[macports@…]

An update to ffmpeg-devel would be great. Abarnert, would you be willing to create a ticket/patch for that, as you already made the changes locally and tried it out?

[ryandesign@…]

Has duplicate #33581.

[starpause@…]

+1, current ffmpeg is out of date and not only that, it segfaults on my machine doing h264 encodes... VERY broken! so i'm currently using this binary (good instructions on the page for rolling your own as well): ​http://www.osxexperts.net/ffmpeg/ffmpegexperts.html

[ryandesign@…]

Has duplicate #35702.

[christian.frisson@…]

Working ffmpeg 0.10.4 working on OSX 10.6.8 32-bit XCode 3.2.6

[christian.frisson@…]

I have been using ffmpeg 0.10.4 for some time into my MacPorts installation, using a local Portfile (just ​attached).

Tested with MacPorts 2.1.2 forced to i386 on 10.6.8 with Xcode 3.2.6 (gcc 4.2.1).

[ryandesign@…]

Superseded by #36693.