Bug 620531 - update libmp4v2 to version 2.0.0
Summary: update libmp4v2 to version 2.0.0
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: libmp4v2 (Show other bugs)
(Show other bugs)
Version: 20
Hardware: All Linux
low
medium
Target Milestone: ---
Assignee: Matthias Saou
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-08-02 19:07 UTC by François Kooman
Modified: 2015-04-29 11:16 UTC (History)
10 users (show)

Fixed In Version: libmp4v2-2.0.0-2.el7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-01-28 21:45:35 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
spec file for mp4v2 2.0.0 (3.31 KB, text/x-rpm-spec)
2012-06-17 00:54 UTC, hdfssk
no flags Details
mp4v2 2.0.0 support for easytag (15.53 KB, patch)
2012-06-17 00:56 UTC, hdfssk
no flags Details | Diff
spec file for easytag 2.1.7 with mp4v2 2.0.0 support (8.67 KB, text/x-rpm-spec)
2012-06-17 01:02 UTC, hdfssk
no flags Details
more updates, now include some documentation files into package (3.50 KB, text/plain)
2014-03-01 04:37 UTC, Avi Alkalay
no flags Details

Description François Kooman 2010-08-02 19:07:18 UTC
Description of problem:

libmp4v2 is currently at 1.5.0.1 while 1.9.1 is already available for over a year.


Version-Release number of selected component (if applicable):

libmp4v2-1.5.0.1-10.fc12.i686

Comment 1 François Kooman 2010-08-02 19:56:03 UTC
Update suggestion:

SPEC: http://fkooman.fedorapeople.org/libmp4v2/libmp4v2.spec
SRPM: http://fkooman.fedorapeople.org/libmp4v2/libmp4v2-1.9.1-1.fc13.src.rpm

This will probably require a rebuild and possibly modification of at least:

$ repoquery --repoid=fedora --repoid=updates --whatrequires libmp4v2
libmp4v2-0:1.5.0.1-10.fc12.i686
easytag-0:2.1.6-2.fc13.i686
easytag-0:2.1.6-5.fc13.i686
gtkpod-0:0.99.14-4.fc13.i686
kid3-0:1.4-1.fc13.i686
libmp4v2-devel-0:1.5.0.1-10.fc12.i686
libtunepimp-0:0.5.3-16.fc12.i686
mediatomb-0:0.12.1-1.fc13.i686


$ rpmlint libmp4v2.spec
0 packages and 1 specfiles checked; 0 errors, 0 warnings.
$ rpmlint ../RPMS/i686/libmp4v2-*
libmp4v2.i686: W: no-manual-page-for-binary mp4tags
libmp4v2.i686: W: no-manual-page-for-binary mp4extract
libmp4v2.i686: W: no-manual-page-for-binary mp4trackdump
libmp4v2.i686: W: no-manual-page-for-binary mp4chaps
libmp4v2.i686: W: no-manual-page-for-binary mp4info
libmp4v2-devel.i686: W: no-documentation
3 packages and 0 specfiles checked; 0 errors, 6 warnings.
$ rpmlint ../SRPMS/libmp4v2-1.9.1-1.fc13.src.rpm 
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

Comment 2 "FeRD" (Frank Dana) 2010-12-27 17:41:47 UTC
Having just looked into this, I suspect a move to 1.9.1 or later (mp4v2 is currently working towards a 2.0 release) wouldn't be an easy one. The mp4v2 maintainers made significant changes to their entire public API with the 1.9.1 release that break backwards compatibility, and continue to introduce more as they approach 2.0. See:

http://mp4v2.googlecode.com/svn/doc/trunk/ReleaseNotes.html

In terms of API consumers, I looked at easytag and faac to gauge support.

The easytag source has gotten some recent attention, and while their current trunk still relies on API calls that are deprecated in 1.9.1 and removed in 2.0, there are patches being submitted that address these and other issues. I suspect it's just a matter of time before the code is worked out in terms of mp4v2 support. The recent (semi-official?) work's been going on over in github:

https://github.com/stsquad/easytag

faac is NOT there at all. We're already building off the latest 1.28 source release, which is from 2009-02-02. So we'd have to look elsewhere for patches to bring it up to mp4v2 1.9.1/2.0 compatibility, assuming anyone's done the work.

Comment 3 Matthias Saou 2012-02-08 16:18:43 UTC
Easytag has sort of resumed development, so I'm looking at updating it. The latest git code seems to include the changes mentioned above, since I now get :

checking for MP4 file support... checking mp4v2/mp4v2.h usability... no
checking mp4v2/mp4v2.h presence... no
checking for mp4v2/mp4v2.h... no
checking for MP4GetTrackMediaDataName in -lmp4v2... yes
checking for MP4/AAC file support... no
***
*** Warning: MP4 file support disabled
*** (Install libmp4v2 >= 1.9.0 to enable it)
***

Does anyone happen to know the status of all this? The latest stable libmp4v2 release is still 1.9.1 from July 2009, so if everything can easily be rebuilt against it for now even if it has some deprecated stuff still used by other packages, that would be fine for me.

Comment 4 Ville Skyttä 2012-05-31 18:44:54 UTC
Looks like 2.0.0 was released a little over a week ago.

Comment 5 hdfssk 2012-06-17 00:54:39 UTC
Created attachment 592368 [details]
spec file for mp4v2 2.0.0

I’ve successfully used this spec file to build a libmp4v2-2.0.0 rpm...

Comment 6 hdfssk 2012-06-17 00:56:56 UTC
Created attachment 592369 [details]
mp4v2 2.0.0 support for easytag

...used this patch to build easytag 2.1.7 with mp4v2 2.0.0 support...

Comment 7 hdfssk 2012-06-17 01:02:10 UTC
Created attachment 592370 [details]
spec file for easytag 2.1.7 with mp4v2 2.0.0 support

...and built an easytag 2.1.7 RPM with mp4v2 2.0.0 support using the existing easytag-2.1.7-1.fc16.src.rpm, the previous patch, and this spec file. Hope some of you find it useful!

Also: easytag’s trunk includes some mp4v2 support, but has problems with cover art, so I’ve sent this patch upstream.

Comment 8 Emilio Scalise 2012-10-22 16:50:30 UTC
any update on this issue?
I updated to fc17 and got no working mp4 support on easytag.. :(

Comment 9 Fedora End Of Life 2013-04-03 18:47:11 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

Comment 10 Avi Alkalay 2014-02-25 10:16:21 UTC
I've build it with hdfssk's new spec file from comment #5, RPMs are here:

http://avi.alkalay.net/software/libmp4v2/

The easytag-2.1.9-2.fc20.x86_64 package from Fedora 20 updates lives well with this libmp4v2-2.0.0-1.fc20.x86_64 build and I was able to read and write tags to M4A files using this easytag version.

I guess nothing else is needed to push libmp4v2-2.0.0 at least to updates-testing. Although I have a Git commit permission, I'm not sure about the steps to update a package not owned by me.

What are the next steps ?

Thank you in advance.

Comment 11 Emilio Scalise 2014-02-25 14:17:07 UTC
Is it possible to adapt your package to coexist with libmp4v2-1.5.0?

That would make possible to use both easytag with new lib, and old packages like faac that need libmp4v2 1.5.0...

In theory, since library is called libmp4v2.so.2 instead of libmp4v2.so.0, that could be possible.

Thanks!

Comment 12 Avi Alkalay 2014-02-25 16:00:03 UTC
(In reply to Emilio Scalise from comment #11)
> Is it possible to adapt your package to coexist with libmp4v2-1.5.0?

I think this will make the world a bit dirty with no need. FAAC and FAAD should be patched after the updated libmp4v2. RPMFusion (the source of FAAC and FAAD) depends on and follows Fedora, not the opposite.

I don't even think they have to be patched at all, only recompiled. I was supposed to test this latter today and will keep you posted here.

Comment 13 "FeRD" (Frank Dana) 2014-02-26 16:46:56 UTC
While I would be shocked if faac can easily be made to work with libmp4v2 2.0 (as far as I know it's still received no development since 2009, and relies on API calls that no longer exist in current libmp4v2), I think a slight twist on Emilio's suggestion could be a workable solution:

1. Fedora updates libmp4v2 to a build of 2.0.0
2. rpmfusion takes what had been Fedora's 1.5.0 and repackages it as libmp4v2-compat, built to coexist with the official libmp4v2 2.0.0 package
3. They begin disting that package, and rebuild whatever packages require legacy libmp4v2 to depend on it instead of the upstream libmp4v2

This is precisely the route they've taken in the past with other libraries. For instance, ffmpeg-compat-0.6.7 is currently present in their repo to support a few packages that haven't kept up with ffmpeg changes. (Looks like maybe just audacity-freeworld and transcode, actually.)

Comment 14 "FeRD" (Frank Dana) 2014-02-26 17:13:33 UTC
Opened an rpmfusion bug to ping them on this issue.

https://bugzilla.rpmfusion.org/show_bug.cgi?id=3188

Comment 15 "FeRD" (Frank Dana) 2014-02-27 11:03:59 UTC
Avi, Nicolas Chauvet @ RPMFusion has asked to be apprised of the results when you try building FAAC against libmp4v2-2.0.0. If you could copy https://bugzilla.rpmfusion.org/show_bug.cgi?id=3188 on any updates, I'm sure it'd be greatly appreciated. (Or if you prefer, I'd be happy to take care of relaying the info.)

Comment 16 Avi Alkalay 2014-03-01 04:37:38 UTC
Created attachment 869274 [details]
more updates, now include some documentation files into package

Comment 17 "FeRD" (Frank Dana) 2014-03-04 03:23:09 UTC
I take back what I said! Seems faac can be built against libmp4v2-2.0.0. 

See the rpmfusion bug for details, but basically I found that while the latest faac release (1.28) is hopelessly outdated, the CVS tree in sourceforge has fixes that bring it up to 2.0.0 compatibility.

So, if rpmfusion update faac, there should be no need to preserve the 1.5.x series libmp4v2 anyway. (I believe faac is the only remaining consumer.)

Comment 18 Avi Alkalay 2014-03-04 08:18:48 UTC
(In reply to "FeRD" (Frank Dana) from comment #17)
> I take back what I said! Seems faac can be built against libmp4v2-2.0.0.

That's great news! From my side I'm trying to stop using FAAC in favor of FFMPEG since FAAC declares itself as a not so good quality encoder and FFMPEG is a more generic tool anyway.

So all solved, let's move to the most difficult part of this task: the Fedora process.

Can anybody tell us what are the next step in getting this package updated? Where to submit to git and koji? What flags need to be raised in this bugzilla report? Whom to talk to? I've already submitted new packages to Fedora but I don't know how to deal with updates.

Thank you

Comment 19 "FeRD" (Frank Dana) 2014-03-04 19:41:09 UTC
Flagging as NEEDINFO Matthias, as he's still the listed assignee on this one.

Comment 20 Sergio Monteiro Basto 2014-10-26 02:58:03 UTC
Hi, I can commit on rpmfusion and fix faac in rpmfusion , please update libmp4v2,
even Debian stable have version 2.0.0 [1]

To rebuild faac on Fedora 21 (which not build in this moment), will be more simple if we got mp4v2 updated, I think will be just update faac from cvs sources. 


[1] https://packages.debian.org/source/stable/mp4v2

Comment 21 Sergio Monteiro Basto 2014-10-26 16:26:55 UTC
Hi, Matthias Saou , I had request commit permission on this package to update it.

Comment 22 "FeRD" (Frank Dana) 2014-12-07 07:03:36 UTC
Nicolas @ RPMfusion reports that their faac will be libmp4v2-2.0.0 compatible as of F21 GA (still this coming Tuesday, I believe?). It really seems like time to pull the trigger on this update.

https://bugzilla.rpmfusion.org/show_bug.cgi?id=3188

Sergio, I see your committers request is still pending in the PkgDB, I assume it's just a matter of getting that approved.

Matthias' last commit to this package was back in 2009, since then the only time it's been touched has been during the Mass Rebuild cycles. As he doesn't appear to be reachable as maintainer, do you (or anyone) know if there's someone we can bounce this up the chain to, or some alternate procedure for requesting commit access?

Comment 23 Sergio Monteiro Basto 2015-01-09 04:12:26 UTC
Hi,
Built libmp4v2-2.0.0-1.fc22 

http://koji.fedoraproject.org/koji/packageinfo?packageID=2356

should I move on to F21 ?

Comment 24 Fedora Update System 2015-01-13 00:23:42 UTC
libmp4v2-2.0.0-2.el7 has been submitted as an update for Fedora EPEL 7.
https://admin.fedoraproject.org/updates/libmp4v2-2.0.0-2.el7

Comment 25 Fedora Update System 2015-01-13 22:08:51 UTC
Package libmp4v2-2.0.0-2.el7:
* should fix your issue,
* was pushed to the Fedora EPEL 7 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=epel-testing libmp4v2-2.0.0-2.el7'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-0254/libmp4v2-2.0.0-2.el7
then log in and leave karma (feedback).

Comment 26 "FeRD" (Frank Dana) 2015-01-14 07:24:44 UTC
Thanks, Sergio. My laptop is currently in the throes of the fedup process to take it to F21 Workstation, so that should be complete soon. I'd definitely be interested in testing an updated libmp4v2-2.0.0, if you can push one to F21 updates-testing (or even just provide a koji build).

Comment 27 Fedora Update System 2015-01-28 21:45:35 UTC
libmp4v2-2.0.0-2.el7 has been pushed to the Fedora EPEL 7 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 28 Sergio Monteiro Basto 2015-04-21 14:36:32 UTC
Hi, 
I'm listing package that be affect by update libmp4v2 on Fedora 21 

repoid package
------------------------------
fedora easytag
fedora kid3
fedora libtunepimp
fedora mediatomb
rpmfusion-free mixxx
rpmfusion-free mpd
rpmfusion-free mythmusic
rpmfusion-nonfree faac

libmp4v2-2.0.0 was out in 2012 and from what I see major of package have  m4a disable due a libmp4v2 not updated , can I update it for F21 on updates-testing ?

Comment 29 Sergio Monteiro Basto 2015-04-29 11:16:00 UTC
Hi, I decided not change F21 package is too late , but I will see if we enable m4a on some packages for F22 

Thanks,


Note You need to log in before you can comment on or make changes to this bug.