Update libmp4v2

[and.damore@…]

libmp4v2 has moved from a  single man effort to a  googlecode project,

I upgraded Portfile to 2.0-20090110 as per attached file, notice that headers changed from mp4.h to mp4v2.h so programs relying on old version of the library have probably to be patched.

[devans@…]

Thanks for this report. Will investigate impact on dependent ports.

Currently at least the following ports depend on libmp4v2

faac
mpeg4ip
cmus +aac
easytag +mp4
easytag-devel +mp4

Adding maintainers of dependent ports to CC for their information and comments

[anonymous]

Milestone Port Enhancements deleted

[cedric.luthi@…]

Cc Me!

[cedric.luthi@…]

In #19142, anddam said:

We could create a new port for libmp4v2 like libmp4v2-2 or mp4v2 as it is the actual project name. Or we could just leave it at 1.5 as there's no point in upgrading a library that noone is using anyway, but this kind of discussion should rather be done in #19141.

I'm in favor of a new port named mp4v2. I don't agree that there is no point in upgrading: the new mp4v2 on googlecode includes some new tools, such as mp4chaps which does not exist in version 1.5.

As mentioned, headers are not a problem, version 1.5 installs only /opt/local/include/mp4.h and version 2.0 installs /opt/local/include/mp4v2/mp4v2.h

As both versions are installing /opt/local/lib/libmp4v2.dylib there might be problems if version 2.0 is not backward compatible.

[cedric.luthi@…]

For mp4v2 version 2.0-20090515, using epoch

[and.damore@…]

iirc some functions name in 2.0 changed so this could break compatibility, or so I was told from faac's maintainer.

[devans@…]

Yes, initial testing shows several incompatibilities. I am against yet another version of this port as we have enough cases of problems caused by conflicts between multiple versions of ports on the system. As it is now we already have two versions (mpeg4ip and libmp4v2) that have been massaged so they do not conflict.

There are a number of important audio/multimedia applications that depend on libmp4v2 so I propose not to commit this sort of port until it can be tested and shown to not break any of those. faac is an important example.

So I guess I'm voting for "if it's not broke don't fix it" until we can guarantee that no existing ports will be broken and there is some positive benefit to a change. The most direct evidence of this would be for upstream developers to adopt this version as a dependency, so if you feel strongly, I advise that you lobby them to switch or at least support this new version in addition to the old.

Another approach would be to commit this as libmp4v2-devel with the understanding (as with all devel ports) that it conflicts with libmp4v2 and may or may not work. Maintainers of dependents of libmp4v2 could modify their dependencies using a path rather than port if they desire to allow either to satisfy their dependency but with the current port being the default until any bugs are ironed out. This would allow those that want to try it to do so but not interfere with functionality of the currently installed dependent ports for the general user.

I'd like to see some input from the maintainers of the dependent ports involved (cc'd) as to their feelings about this.

[cedric.luthi@…]

For mp4v2 version 1.9.0 (inaugural release)

[cedric.luthi@…]

The mp4v2 project has now released a stable 1.9.0 version. So I change my mind and I think we should update the libmp4v2 port to version 1.9.0 and change its name to mp4v2 instead of yet another mp4v2 port which would be indeed too much confusing and overlapping.
On the mp4v2 page is written Users interested in backward-compatible API with MPEGIP/libmp4v2 should use this release. :-)

Here are the port that depends on libmp4v2

$ port echo depends:libmp4v2
aacgain
amarok
amarok-devel
easytag
faac
mpeg4ip

Let's take them one by one and see what are the problems.

aacgain

aacgain is actually using an embedded version of libmp4v2. This is how the final aacgain executable is built:
/usr/bin/g++-4.0 -O2 -o aacgain aacgain.o decoder.o MP4MetaFile.o syntax.o -Wl,-bind_at_load -L/opt/local/lib ../faad2/libfaad/.libs/libfaad.a -lm ../mpeg4ip/lib/mp4v2/.libs/libmp4v2.a ../mp3gain/mpglibDBL/.libs/libmpglib.a ../mp3gain/.libs/libmp3gain.a

We can remove the depends_lib lib:libmp4v2:libmp4v2 from the Portfile, aacgain will work exactly the same.

amarok and amarok-devel

I could not test amarok because it failed to install (because of kdepimlibs4), even after applying the patch of #19494:

CMake Error at /opt/local/share/apps/cmake/modules/FindKDE4Internal.cmake:1141 (message):
  ERROR: the installed kdelibs version 4.2.00 is too old, at least version
  4.2.2 is required

easytag

easytag is using libmp4v2, but updating to version 1.9.0 is very easy, see attached easytag-mp4v2.patch

faac

As pointed in #19142, mp4 support is not actually built in faac. This is because the configure.in file is bugged: it does not do MY_DEFINE(HAVE_LIBMP4V2) when Building with external mp4v2 which result in no mp4 support at all. Updating to mp4v2 1.9.0 would thus not impact faac.

mpeg4ip

If I understood correctly libmp4v2 is a subset of mpeg4ip, which has been discontinued. mpeg4ip requires libmp4v2 because libmp4v2 installs newer version of the same mp4 tools and libs. mpeg4ip is not actually built on top of libmp4v2, so updating to version 1.9.0 would not impact mpeg4ip.

---

How does a port renaming work? Should we do a pre-fetch { return -code error } in libmp4v2 as in the ethereal port? Is there some other way to achieve it?

[cedric.luthi@…]

Now, amarok does not depend on libmp4v2 anymore and gtkpod depends on libmp4v2. gtkpod handle both the old (#include <mp4.h>) and new (#include <mp4v2/mp4v2.h>) mp4v2 library. So we are now completely safe to upgrade to mp4v2 1.9.0 IMHO.

[cedric.luthi@…]

Any comments?

[and.damore@…]

Cedric has done a great job briefing eventual dependencies issues, and now it seems safe to proceed.

I vote for a mp4v2 port and changing dependencies in dependent portfiles.

[cedric.luthi@…]

Anybody else interested in getting a mp4v2 port?

[cedric.luthi@…]

Cool, I just read there is now a replaced_by portfile option in MacPorts 1.8. I think it would be a good thing to use for libmp4v2 → mp4v2.

[cedric.luthi@…]

For mp4v2 version 1.9.1

[snc@…]

New port committed in r55758. Old ports stubbed in r55759 and r55760.

 Easytag patch still needs done. I'll do this after lunch if no one else takes care of it.

[snc@…]

Changes made to easytag in r55775.

Does this bring complete all the changes?

[cedric.luthi@…]

You should also remove

configure.args  --without-mp4v2  
depends_lib     lib:libmp4v2:libmp4v2

from the faac port. As discussed in #19142, mp4 support was never built into faac.

[cedric.luthi@…]

Oh and you should also remove

depends_lib lib:libmp4v2:libmp4v2

in the aacgain port. See comment 7.

[raimue@…]

Changed libmp4v2 dependency of aacgain, easytag, faac, gtkpod to mp4v2 in r56688.

[cedric.luthi@…]

Please also remove the mp4v2 dependency in the faac port until #19142 is fixed.

[jmr@…]

So, why was mpeg4ip stubbed out again when it was specifically brought back at the request of a user who wanted mp4creator (#17651)?

[rmsfisher@…]

GTKPod does not work properly with the new mp4v2. GTKPod had preliminary support for a few functions in an early version of the fork but will not build against the currently-ported version because of major syntax changes.

This whole fiasco stems from the developers of a single upstream project (HandBrake) tiring of the limitations of a widely-used shared library; by rewriting that library in a fashion that broke backwards-compatibility those developers made their project much more of a fork rather than an upgrade.

I would suggest we resurrect mpeg4ip/libmp4v2, but only if it could be done in a way that ensures mutual exclusivity with mp4v2.

[snc@…]

Just throw in "conflicts PORT"

[raimue@…]

As this is now sitting here for 9 months without updates, is this still an issue at all?

[and.damore@…]

Seems that everything has been updated, libmp4v2 is 1.5.0 and mp4v2 is 1.9.1 so rmsfisher request should be satisfied, dependencies has been updated in r56688, mpeg4ip has been restored as jmr requested. Closing ticket as the initial issue is solved.