Opened 13 years ago

Closed 12 years ago

#33048 closed update (duplicate)

ffmpeg: Update to 0.10

Reported by: ocroquette (Olivier Croquette) Owned by: dbevans (David B. Evans)
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 (5)

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

Download all attachments as: .zip

Change History (19)

Changed 13 years ago by ocroquette (Olivier Croquette)

Attachment: Portfile.diff added

Changed 13 years ago by ranauei@…

Attachment: Portfile2.diff added

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

comment:1 Changed 13 years ago by ryandesign (Ryan Carsten Schmidt)

Keywords: haspatch added
Owner: changed from macports-tickets@… to devans@…
Type: enhancementupdate

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 13 years ago by ryandesign (Ryan Carsten Schmidt)

Summary: Update ffmpeg to 0.10ffmpeg: Update to 0.10

comment:3 Changed 13 years ago by ocroquette (Olivier Croquette)

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 13 years ago by markus.doits@…

Cc: markus.doits@… added

Cc Me!

comment:5 Changed 13 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 13 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 13 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 13 years ago by abarnert@…

Attachment: ffmpeg-2.log added

+universal i386 build failure after patching with Portfile2.diff

Changed 13 years ago by abarnert@…

Attachment: ffmpeg-3.log added

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

comment:8 Changed 13 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 13 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 13 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: dargo@… added

Has duplicate #33581.

comment:11 Changed 12 years 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 12 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: keybounce@… added

Has duplicate #35702.

Changed 12 years ago by ChristianFrisson (Christian Frisson)

Attachment: Portfile added

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

comment:13 Changed 12 years ago by ChristianFrisson (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 12 years ago by ryandesign (Ryan Carsten Schmidt)

Resolution: duplicate
Status: newclosed

Superseded by #36693.

Note: See TracTickets for help on using tickets.