MP4v2 v2.1.1

[enzo1982]

Changes since the MP4v2 v2.1.0 release:

• Fixed a type mismatch preventing MP4v2 from compiling on 32 bit systems (thanks @ffontaine).

Please also take note of the MP4v2 v2.1.0 changelog listing the changes of this recent major release.

---

This discussion was created from the release MP4v2 v2.1.1.

[bergert]

When I run
mp4track --list
userDataName = Stereotrack[3] id=4

ERROR: track name "Stereotrack" not followed by newline. Tracks with (name ) show correctly: with newline.

A track name printed (userDataName) in module libutil/TrackModifier.cpp
is causing a problem, with the result that the following /n is never printed and the track name and next track[4] id=6 are appended right into the line of the track name. This is a problem, with parsing the output.

As a quick and dirty fix, I have applied this change: so that the track number is always printed on a new line:
out << '\n' << xind << ind << setw( w ) << "userDataName" << "";
track name is not shown

The correct solution is to convert the track name to a string (save length!) so it can be printed.

sorry, my old time C skills are just enough for the fix to never show track name.

[bergert]

I think the string which lacks a string end = /0 char causes an exception and the rest of the routine = output of newline = is never executed. To print the string, you need to check the length and add a string end - or have a special routine to just copy a number of characters to the output?
(apologies, I just see the problem, and substituting for a fixed "" output does arrive at the newline in the code.
The track name display works, newline printed, only if the track name is empty (hence my workaround).

This can be easily reproduced using a number of mp4 files...

[bergert]

If I had a better understanding of Cpp - I would submit a patch: I can see the problem ...

[bergert]

track[1] id=2
type = audio
userDataName = Stereotrack[2] id=3
...
userDataName =
track[3] id=5
...

[enzo1982]

Ok, I was able to reproduce this with a specially crafted file.

The problem occurs when the track name field (udta.name) is null terminated, i.e. the property contains a 0 character. When constructing an std::string from a buffer and passing the buffer size, the constructor does not check for 0 terminators, but includes them in the string data.

Then when writing the output, the 0 terminator is included when printing userDataName and anything that is passed to the output stream after that is discarded, including the newline.

This is fixed in commit d0c8ccc.

[bergert]

confirmed - the track name "Stereo" now prints correctly (with newline).

Thank you very much!

[bergert]

for info:
I managed to compile on OSX; libtool is included with Xcode, so GNU lib tool has to use prefix "g".

export LIBTOOL=glibtool
export LIBTOOLIZE=glibtoolize
autoreconf -i
./configure --enable-static --disable-shared MP4V2_USE_STATIC_LIB=yes
make

confirmed works:
mp4v2-main % otool -L. /mp4track
/mp4v2-main/mp4track:
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1300.23.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.100.3)
(no dylib mp4v2)

This is useful, so I can have mp4v2 (stable) installed, and at the same correctly test a new build without touching with the dylib.
New build = use static library (not old version)

[degarb]

I am looking for the windows binary. The windows binaries online do not work when ran as a batch file. I can run through the console, but that defeats the point of any commandline tool.

[enzo1982]

Binaries are not provided here. You will either have to find a 3rd party source for binaries or compile the code yourself. On Windows, you can use Visual Studio or MSYS2 to compile the code.

Which binaries did you use that didn't work in a batch file?