New Ticket     Tickets     Wiki     Browse Source     Timeline     Roadmap     Ticket Reports     Search

Ticket #33048 (closed update: duplicate)

Opened 2 years ago

Last modified 18 months ago

ffmpeg: Update to 0.10

Reported by: ocroquette@… Owned by: devans@…
Priority: Normal Milestone:
Component: ports Version: 2.0.3
Keywords: haspatch Cc: markus.doits@…, dargo@…, keybounce@…
Port: ffmpeg

Description

Seamless upgrade to ffmpeg 0.10

Attachments

Portfile.diff (736 bytes) - added by ocroquette@… 2 years ago.
Portfile2.diff (11.1 KB) - added by ranauei@… 2 years ago.
Moved to sha256/rmd160, removed unnecessary configure parameters and other fixes
ffmpeg-2.log (379.3 KB) - added by abarnert@… 2 years ago.
+universal i386 build failure after patching with Portfile2.diff
ffmpeg-3.log (265.6 KB) - added by abarnert@… 2 years ago.
Another i386 build failure even after restoring apple-gcc-4.2 (after reading #30137).
Portfile (7.8 KB) - added by christian.frisson@… 19 months ago.
Working ffmpeg 0.10.4 working on OSX 10.6.8 32-bit XCode 3.2.6

Change History

Changed 2 years ago by ocroquette@…

Changed 2 years ago by ranauei@…

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

comment:1 Changed 2 years ago by ryandesign@…

  • Owner changed from macports-tickets@… to devans@…
  • Keywords haspatch added
  • Type changed from enhancement to update

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.

comment:2 Changed 2 years ago by ryandesign@…

  • Summary changed from Update ffmpeg to 0.10 to ffmpeg: Update to 0.10

comment:3 Changed 2 years ago by 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 ?

comment:4 Changed 2 years ago by markus.doits@…

  • Cc markus.doits@… added

Cc Me!

comment:5 Changed 2 years ago by 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?).

comment:6 Changed 2 years ago by 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.

comment:7 Changed 2 years ago by 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.

Changed 2 years ago by abarnert@…

+universal i386 build failure after patching with Portfile2.diff

Changed 2 years ago by abarnert@…

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

comment:8 Changed 2 years ago by 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.

comment:9 Changed 2 years ago by 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?

comment:10 Changed 2 years ago by ryandesign@…

  • Cc dargo@… added

Has duplicate #33581.

comment:11 Changed 22 months ago by 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

comment:12 Changed 20 months ago by ryandesign@…

  • Cc keybounce@… added

Has duplicate #35702.

Changed 19 months ago by christian.frisson@…

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

comment:13 Changed 19 months ago by 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).

comment:14 Changed 18 months ago by ryandesign@…

  • Status changed from new to closed
  • Resolution set to duplicate

Superseded by #36693.

Note: See TracTickets for help on using tickets.