I can't sponsor, but some notes:

---
%files
%doc COPYING
%defattr(-,root,root,-)
%{_bindir}/*
%{_libdir}/*.so.*
---

Normally - %doc goes below %defattr line

---
%files devel
%doc README TODO INTERNALS API_CHANGES
%doc %{_mandir}/man?/*
%{_includedir}/*.h
%{_libdir}/*.a
%{_libdir}/*.so
---

You nead a defattr line here.
Don't use %doc with %{_mandir} - it isn't necessary.
Don't package the static library (unless you know you need it)

----
I see shared libraries - but don't see ldconfig run in %post or %postun.

Changelog version refers to lvn - it should just be

1.4.1-1

On another note - this package will conflict with faad2 from rpm.livna.org

Thanks an updated version is posted at

http://resare.com/noa/fedora-extras/libmp4v2-1.4.1-2.src.rpm
http://resare.com/noa/fedora-extras/libmp4v2.spec

I know that this conflicts with livna. Including this in extras i part of my
grand plan to get an updated faad2 into livna (newer faad2 lacks the libmp4v2
component)

I'm afraid this is something that will need an ack from someone (legal?) who can
tell if it's acceptable in FE.  FWIW, to me it looks like a "no".  For example,
from http://mpeg4ip.sourceforge.net/faq/index.php

Q: What are the licensing terms associated with this project?
A:  Like most modern codecs, MPEG-4 Video and Audio codecs are almost certainly
subject to patent royalities. This project does not remove any responsiblity or
liability from developers or users of this kit.  [...]

I've sent this message to legal now:

I would like to include libmp4v2 into Fedora Extras. It is a library
that provides an interface to the mp4 container format. Once included it
can be used to provide mp4/aac support to for example easytag.

So, my question to the fedora project is this: can fedora extras accept
the contribution from a legal standpoint? On one hand the libmp4v2
package has no knowledge about the actual audio and video coding
algorithms that are a part of the mpeg 4 standard. That would make it
immune to the patent issues surrounding mpeg4 that I'm aware of. On the
other hand the patent situation with regards to mpeg 4 is unclear at
best.

There is some precedent in the form of the id3lib package, that provides
similiar functionality but is a little bit more narrow in it's scope.

While waiting for a word from the legal gurus, libmp4v2 is available from
rpm.livna.org

FWIW, mpeg4ip 1.5.0.1 has been released.

Is there any effort going on to try and get upstream to officially split out
libmp4v2 from mpeg4ip, so that the whole mess between mpeg4ip and faad2 both
providing it can be fixed? It seems like this is what you're trying to do for
Fedora packages, but it would definitely benefit to other people and
distributions if done upstream directly. 

The effort was nonexistant until five minutes ago when I sent an email to the
upstream maintainer. Thanks for the suggestion. I'll add any new info here.

Removing FE-NEEDSPONSOR as submitter was sponsored in: 
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191592

Any new info?

http://www.redhat.com/archives/fedora-extras-list/2006-September/msg00624.html

Without the codec functionality, and with the id3lib precedence, I think this is
OK. Lifted FE-Legal.

Scratch that. It's demultiplexing (and multiplexing) the mp4 format. This might
be patented, setting back to FE-Legal for a Patent lawyer to check.

Lifted FE-Legal here, after discussion with Max. I cannot find any patents on
multiplexing/demuxing in software.

Great, if we can have this in Extras.

First review steps, the spec file :
- Please don't mix space and tab identing in spec files (there is one tab).
- I suggest you use %{version} in Source0 line to be sure not to miss an update.
- You should update to your 1.5.0.1 package, I guess...
- Do we want to be shipping the static library? Probably not.
- You should switch to "make install DESTDIR=$RPM_BUILD_ROOT" (it works).

About the build :
- It compiles fine (tested FC6 x86_64), but with quite a few warnings.

About the resulting packages :
I tried to recompile the latest easytag, enabling libmp4v2 support, but the
build failed with this error :

gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic -I/usr/include/gtk-2.0
-I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo
-I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
-I/usr/include/freetype2 -I/usr/include/libpng12 -o easytag about.o ape_tag.o
bar.o browser.o cddb.o charset.o crc32.o dlm.o easytag.o et_core.o flac_header.o
flac_tag.o id3_tag.o misc.o monkeyaudio_header.o mpeg_header.o mp4_header.o
mp4_tag.o musepack_header.o msgbox.o ogg_header.o ogg_tag.o picture.o prefs.o
scan.o setting.o vcedit.o  -L/lib64 -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0
-lgdk_pixbuf-2.0 -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0
-lgmodule-2.0 -ldl -lglib-2.0 libapetag/libapetag.a id3lib/libid3bugfix.a
-lmp4v2 -lz -lstdc++ -lid3 -lFLAC -lvorbisfile -lvorbis -logg -lm
mp4_header.o: In function `getType':
/usr/src/rpm/BUILD/easytag-1.99.13/src/mp4_header.c:125: undefined reference to
`MP4GetTrackMediaDataName'
mp4_header.o: In function `Mp4_Header_Read_File_Info':
/usr/src/rpm/BUILD/easytag-1.99.13/src/mp4_header.c:240: undefined reference to
`MP4GetTrackAudioChannels'
collect2: ld returned 1 exit status

The linking stage seems to be including -lmp4v2 properly, but fails to find
those two functions (using 1.4.1). Do you have any idea why? Would it be a
problem with libmp4v2 or with how easytag tries to use it?

I'm sorry to say that I won't have time to pick this up in reasonable time. I
had some hopes that when my employment situation changed a month ago I would get
some time to contribute to FE, but it seems like being the proud employee of a
two person startup doesn't give that much free time.

Feel free to carry on with the contribution as you see fit Matthias.

OK, I'll pick it up. I've tried the latest 1.5.0.1 which seems to work fine with
all the packages I have over at freshrpms.net, so I'll submit a package of that
version to this bug report once I'm 100% sure all is working (haven't tried
easytag again with that version yet).

At that point, someone will have to reassign the but to themselves in order to
do the formal review, since I can't review a package which will be my own
(obviously).

I will do the review.

Sorry for taking so long...
I've been using this package for over a month now, and all of the multimedia
package I maintain which make use of libmp4v2 rebuild and run fine against it.

Ready for review :
http://ftp.es6.freshrpms.net/tmp/extras/libmp4v2.spec
http://ftp.es6.freshrpms.net/tmp/extras/libmp4v2-1.5.0.1-3.fc6.src.rpm

Since this bug is currently assigned to me, I'll reassign to you :-)

Hey, no problem, I've been busy, too. Review will follow soon.

 1. package meets naming and packaging guidelines.
 2. specfile is properly named, is cleanly written and uses macros consistently.
 3. dist tag is present.
 4. build root is correct, but not the recommended version
    -> please add %(%{__id_u} -n) at the end before importing
 5. license field matches the actual license.
 6. license is open source-compatible (MPL 1.1). License text included in package.

    However, the following file has no license header:
    libmp4v2-1.5.0.1/atom_ohdr.cpp
    Please poke upstream to fix that.

 7. source files match upstream:
    90eb2b0940ebe02ef81b7a60530beaee  libmp4v2-1.5.0.1.tar.bz2
    4b4abb862b079a7e296c891d96faebc9  mklibmp4v2-r51.tar.bz2
 8. latest version is being packaged.
 9. BuildRequires are proper.
10. package builds in mock (fc7/x86_64).
11. rpmlint is silent.
12. final provides and requires are sane:

    libmp4v2 = 1.5.0.1-3.fc7
    =
    /sbin/ldconfig  
    libc.so.6()(64bit)  
    libgcc_s.so.1()(64bit)  
    libm.so.6()(64bit)  
    libmp4v2.so.0()(64bit)  
    libstdc++.so.6()(64bit)  

    libmp4v2-devel = 1.5.0.1-3.fc7
    =
    libmp4v2 = 1.5.0.1-3.fc7
    libmp4v2.so.0()(64bit)  

13. shared libraries are present and ldconfig is called in %post(un).
14. package is not relocatable.
15. owns the directories it creates.
16. doesn't own any directories it shouldn't.
17. no duplicates in %files.
18. file permissions are appropriate.
19. %clean is present.
20. %check is not present, no testsuite.
21. no scriptlets present.
22. code, not content.
23. documentation is small, so no -docs subpackage is necessary.
24. %docs are not necessary for the proper functioning of the package.
25. headers present in -devel package only.
26. no pkgconfig files.
27. no libtool .la droppings.
28. not a GUI app.
29. not a web app.

4. and 6. need work, but are not blockers, so
APPROVED

Why is this still not imported and built?

Or rather, why is this bug not closed, since it has already been built.

Simply because I missed it. Since I'm not the reported or the assignee, it
doesn't appear in my bugzilla front page...

Closing now at last :-)