A new MP4v2 fork with a commitment to long-term maintenance

[enzo1982]

Hi all,

I just published my own fork of the MP4v2 library in an attempt to revive this project that has been abandoned since 2015. I would like to take on the task of bringing the code up to date by integrating fixes and improvements and commit to long term maintenance of the library.

This fork integrates lots of fixes from various sources and adds some additional ones, including build system updates and fixes for two CVEs (CVE-2018-17235 and CVE-2018-17236).

It also adds new callback based APIs for reading and creating MP4 files, replacing the MP4CreateProvider[Ex] calls added after the 2.0.0 release that would have broken the ABI (see my extended commit message for details). This makes this fork completely API and ABI backwards compatible with the previous official release, MP4v2 2.0.0.

I created an initial roadmap for this fork which you can find on mp4v2.org. I would like to keep the initial release from this fork limited to mainly issue fixes an minor improvements. New features will be added after that.

I would like to invite everyone to a discussion here ahead of tagging a first update release (the plan is to have an initial MP4v2 2.1.0 release in about two weeks) and encourage you to report issues and submit pull requests.

If you prefer to contact me directly, feel free to write to [email protected].

Robert

[enzo1982]

Pinging some users who have maintained their own patches on top of the old MP4v2 code and/or have recently contributed to other forks such as the one maintained by TechSmith:

@bsantos, @galad87, @ptc-lfruehstueck, @sandreas, @sergiomb2, @bergert, @ffontaine, @AlexGuo1998, @mkuron

I'd like to invite you to join the discussion of my attempt to revive the MP4v2 project. And of course you are welcome to report issues and submit pull request here.

[enzo1982]

Finally, @dchengTSC, thank you for maintaining the fork of MP4v2 at TechSmith. It has been a valuable resource in the past years as place for users to report issues and propose patches after the closing down of Google Code and the abandonment of the original MP4v2 project.

I invite you to consider rebasing your fork onto this one. Most of the issues you worked around in your tree are fixed here and you would benefit from future fixes and improvements in this tree, allowing you to focus on the additions you made to support TechSmith specific atoms etc.

Feel free to join the discussion here or contact me directly via email.

[dchengTSC]

This is great! Thank you for taking on the task of maintaining this. We are happy to hand this off to you and eventually archive our fork of mp4v2, although it will take us some time to migrate and check for regressions.

To that end, I've made a PR that cleans up the CMakeLists.txt a bit. We've recently switched to using mp4v2 through CMake, so I made a quick attempt at integrating your latest code and have some CMakeLists.txt suggestions: #5

[enzo1982]

Thank you for joining the discussion and for your PR, which I just merged. It's great that you are considering migrating to this fork. Much appreciated!

Feel free to open more PRs or issues if you find anything to fix or improve.

[galad87]

Thanks you for this new fork and for effort in maintaining this library.

My fork has got many additions (a complete iTunes-style metadata implementation, H.265, ALAC, AV1, Dolby Vision, HDR10 metadata, WebVTT, titl track name atom and possibly more), unfortunately the work on it was a bit messy, just enough to use it in Subler, and I don't have the time to port these changes to your fork at the moment. But I am ready to switch to this fork if someone integrates all these changes.

On the other hands, in my opinion one improvement mp4v2 really needs is the ability to automatically switch to the required 64bit atoms when writing a file larger than 4GB.

[enzo1982]

My fork has got many additions (a complete iTunes-style metadata implementation, H.265, ALAC, AV1, Dolby Vision, HDR10 metadata, WebVTT, titl track name atom and possibly more),

Yes, I saw that and definitely want to integrate most or all of that into this fork after the initial release. Yours is probably the fork with the most feature additions around. Nice work!

Your public fork has all of those additions in a single commit, though. Do you happen to have a repository with the individual commits you could give me access to or send me a copy of? Or maybe it's available somewhere already and I just didn't find it? That might make it much easier to separate the individual features.

On the other hands, in my opinion one improvement mp4v2 really needs is the ability to automatically switch to the required 64bit atoms when writing a file larger than 4GB.

Yes, that also came to my mind already. Maybe this is something I can include in the initial release. I figure for mdat, MP4v2 could simply create a new atom when the previous one exceeds 4 GB, or alternatively reserve space before it to be able to switch the header to 64 bit and move it back by 8 bytes if needed. stco would have to be replaced by co64, but its only written at the end anyway, so no big issue. Similar for the few other atoms that can have 32 or 64 bit properties.

[galad87]

Your public fork has all of those additions in a single commit, though. Do you happen to have a repository with the individual commits you could give me access to or send me a copy of? Or maybe it's available somewhere already and I just didn't find it? That might make it much easier to separate the individual features.

That's one of the reasons it's a mess. 😅

[enzo1982]

Just released v2.1.0. I didn't have time to get the automatic 64 bit switching into this release, but definitely plan to add it in a future one. I will add a feature request issue for this.

[ffontaine]

Thanks for this release, this is really great.
I'll update buildroot with this new release and report any issue.
I would however advise to use another version than 2.1.0 as it was already used by TechSmith back in 2014:
https://github.com/TechSmith/mp4v2/releases/tag/2.1.0.
This will definitely create misunderstanding. 2.1.0 is for example already referenced in https://release-monitoring.org/project/98413.
Perhaps, you could bump to 6.x or use 2.2.0?

[enzo1982]

Thank you for joining the discussion!

I'd really like to stick to 2.x version numbers here. There is nothing in this 2.1 release that justifies a major version bump, let alone jumping four major versions ahead.

Continuing the version numbers where TechSmith left off would also not reflect what's in this fork, as this does not integrate all the changes from their tree (e.g. their custom tsc2 atom type or the MP4GetTrackAtomData API) and is generally backwards compatible with MP4v2 2.0.0, but not with TSC-MP4v2 5.0.1.

The TechSmith fork was intended to be a place for them to publish their internally adopted MP4v2 code, not a replacement for the abandoned upstream project. And apparently most integrators realized this and stayed on 2.0.0 plus custom patches.

I realize that for those who didn't there may initially be some confusion about this new project's version numbering, but that can hopefully be sorted out quickly.

[sandreas]

This is an awesome commitment. Thank you. My project (https://github.com/sandreas/m4b-tool/) heavily relies on mp4v2 command line utils (like mp4tags and mp4chaps), but the techsmith fork did not implement all the features, I'd like to have, so I tried to use some of the already present pull requests and some basic research to add these.

If you don't mind I will open some issues today containing the stuff, I came across in the last months...

[enzo1982]

Thank you for joining the discussion! I'm sure we can add the features you need here. See my comments in issues #2 and #3 for a start.

If you don't mind I will open some issues today containing the stuff, I came across in the last months...

Sure, if you have more, feel free to open issues and PRs.

[bergert]

Hello Robert, Below my patches - I am using mp4tags in my personal video-workflow solution. If you can implement my patches I can test and build (and code-sign) macOS binaries. I in the middle of moving from x64 to M1 (several times faster than my MacPro/Xeon). I have committed my fixes to mp4tags: bergert/mp4v2@4ff544d <bergert/mp4v2@4ff544d> It would be good if you can incorporate these: <mp4tags>I discovered and fixed issues with tags which are not parsed correctly, several tags missing, and parsing: I find these tags appearing, as regular tags, not as part of an ILST. I am just a hobby-programmer- making small changes. I stopped, when the solution was workable for my test cases, and was not possible to invest more time (remove unused code, cleanup) or do more testing. Greuese nach Hamburg, Thomas

…

On Feb 13, 2022, at 1:58 PM, Robert Kausch ***@***.***> wrote: Thank you for joining the discussion! I'm sure we can add the features you need here. See my comments in issues #2 <#2> and #3 <#3> for a start. If you don't mind I will open some issues today containing the stuff, I came across in the last months... Sure, if you have more, feel free to open issues and PRs. — Reply to this email directly, view it on GitHub <#1 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADSJIIE5K4X6XB476EKERMLU26THPANCNFSM5OHGP6GA>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.

[enzo1982]

Hi Thomas, thank you for joining the discussion!

I will have a closer look at the proposed changes soon. We can certainly integrate some of them, but I need to do some additional research on MP4 metadata first.

Some of your atoms are defined by 3GPP standards (e.g. auth, dscp, kywd, titl) and I would prefer to add all of them (there are more, defined in 3GPP TS 26.244) at once. These atoms should be stored directly under udta.

At least one (clfn) appears to come from Final Cut Pro and there are also more atoms introduced by that program, so it would be nice to add support for all of them at once too.

I still need to try and make sense of some of the other atoms. Some might just stem from random tools writing invalid/non-standard tags. In such a case, those should not be added here in order to not promote the use of them. But I'll need to take a closer look to figure that out.

I'm gonna leave this for after the initial 2.1.0 release as I would like to keep that one mostly limited to issue fixes. Additions like these new tags will then be included in a 2.2.0 release a few months after the initial one (but can of course be added here much earlier).

[sergiomb2]

Hi, Enzo , I'm very well impressed with your work .
your repo and my repo have common commits [1], so I could verify that you applied all security patches that I have , etc .
one question why you drop all man 3 files doc/*.3 ? any particularl reason ?

[1]
git merge-base origin/master enzo1982/main
cc17ffe

[enzo1982]

Hi Sergio, thanks for joining the discussion!

Yes, all commits up to cc17ffe are imported from the original mp4v2 project. Those have the same hashes as the ones automatically exported by Google Code Exporter in mp4v2/mp4v2, so it's easily verified that they are the same.

The API man pages still stemmed from the original MPEG4IP project and were completely outdated. They had never been updated when APIs were added, changed or removed. All the new APIs were documented with Doxygen comments instead.

So to clean this up and unify the documentation, I moved all the still relevant man page content to Doxygen comments in the header files, revising and updating it in the process. The Doxygen output including the previous man page content is available at https://mp4v2.org/api/.

In theory it's possible to generate man pages with Doxygen too, but the output is not very user friendly. All functions belonging to a module are documented in a single man page and pages for individual functions are mere links to the respective module page. There are tools like doxy2man, though, that claim to produce better output. So if anyone thinks there really should be man pages, that may be worth giving a try.

[sergiomb2]

OK , thank you for clarification , I'm ok with dropping man pages, It was just curiosity and it is a good reason .
So my repo is already completely merged .

[bsantos]

Hi, many thanks for giving some love to this library :)

I see that you have applied the fixes I had, which is great. I will update my fork to yours. Unfortunately I don't have much time to spend on this, but I will slowly update my fork and submit pull requests for some missing atoms.

Cheers

[enzo1982]

Hi, thanks for joining the discussion!

Yes, I merged some of the fixes from your fork into this one. Thank you for publishing those! I also saw your additions for the lpcm atom etc. I'll start adding features after cutting an initial 2.1.0 release and will merge your PR then.

It's great that there's still so much interest in this library and that everyone is coming here. That's what I was hoping for.

[ptc-jhoerner]

Hi,

what is the status of this project now, is it still being actively maintained?

Cheers,
Jiri

Jiri Hörner
Principal Software Engineer, Vuforia

[email protected]

vuforia.com