enzo1982 / mp4v2 Goto Github PK

View Code? Open in Web Editor NEW

129.0 129.0 49.0 3.11 MB

Reviving the MP4v2 project...

Home Page: https://mp4v2.org

License: Other

M4 0.75% C 13.99% C++ 83.63% Python 0.89% CMake 0.74%

audio mp4 video

mp4v2's People

Contributors

Stargazers

Watchers

mp4v2's Issues

Support informational comment tags in mp4v2 chapters.txt format

I did not find a specification for the chapters.txt format, mp4v2 generates and makes use of.

One problem with the chapters.txt format is, that there is no hint for the total duration of a file, because it contains only the start of a chapter, not the duration or ending. Example:

00:00:00.000 chapter 1
00:00:00.500 chapter 2
00:00:01.000 chapter 3

The file could have a total duration 1.5 seconds but also 3.5 seconds or even 1 hour. While comments in the file are already ignored, I tried to use these to support this feature.

# total-length 00:00:01.500
00:00:00.000 chapter 1
00:00:00.500 chapter 2
00:00:01.000 chapter 3

It would be also possible, to mark these special comments with an extra # and a key-value-pair separated by =

## total-duration=00:00:01.500
00:00:00.000 chapter 1
00:00:00.500 chapter 2
00:00:01.000 chapter 3

Maybe a more specified approach would be better, what do you think?

Memory Leak in mp4file_io

I found a memory leak error in mp4file_io.cpp:409 and mp4file_io.cpp:354; it seems that the data buffer allocated to store the string is not properly deallocated.

Environment

OS: Ubuntu 18.04.6 LTS
Compiler: gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)

Compilation

autoreconf -i
CC=gcc CXX=g++ CFLAGS='-fsanitize=address -g' CXXFLAGS='-fsanitize=address -g' ./configure
make -j32

Command Line

./mp4info poc_1.mp4

./mp4info poc_2.mp4

POC

poc.zip

Report for POC_1

==6031==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 32 byte(s) in 1 object(s) allocated from:
    #0 0x7fda4cd07b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
    #1 0x7fda4c6b94ac in mp4v2::impl::MP4Malloc(unsigned long) src/mp4util.h:63
    #2 0x7fda4c745dd4 in mp4v2::impl::MP4File::ReadCountedString(unsigned char, bool, unsigned char) src/mp4file_io.cpp:409
    #3 0x7fda4c74d451 in mp4v2::impl::MP4StringProperty::Read(mp4v2::impl::MP4File&, unsigned int) src/mp4property.cpp:436
    #4 0x7fda4c709cc1 in mp4v2::impl::MP4Atom::ReadProperties(unsigned int, unsigned int) src/mp4atom.cpp:383
    #5 0x7fda4c709056 in mp4v2::impl::MP4Atom::Read() src/mp4atom.cpp:237
    #6 0x7fda4c708ab9 in mp4v2::impl::MP4Atom::ReadAtom(mp4v2::impl::MP4File&, mp4v2::impl::MP4Atom*) src/mp4atom.cpp:202
    #7 0x7fda4c70a770 in mp4v2::impl::MP4Atom::ReadChildAtoms() src/mp4atom.cpp:435
    #8 0x7fda4c70907b in mp4v2::impl::MP4Atom::Read() src/mp4atom.cpp:241
    #9 0x7fda4c71a98f in mp4v2::impl::MP4File::ReadFromFile() src/mp4file.cpp:457
    #10 0x7fda4c717417 in mp4v2::impl::MP4File::Read(char const*, MP4FileProvider_s const*, MP4IOCallbacks_s const*, void*) src/mp4file.cpp:101
    #11 0x7fda4c6f33e6 in MP4ReadProvider src/mp4.cpp:105
    #12 0x7fda4c6f3389 in MP4Read src/mp4.cpp:92
    #13 0x7fda4c7493f8 in MP4FileInfo src/mp4info.cpp:621
    #14 0x5618d819197d in main util/mp4info.cpp:77
    #15 0x7fda4bbbec86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)

SUMMARY: AddressSanitizer: 32 byte(s) leaked in 1 allocation(s).

Report for POC_2

==6046==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 256 byte(s) in 1 object(s) allocated from:
    #0 0x7f4ade7c5f30 in realloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdef30)
    #1 0x7f4ade1737d9 in mp4v2::impl::MP4Realloc(void*, unsigned int) src/mp4util.h:87
    #2 0x7f4ade203918 in mp4v2::impl::MP4File::ReadString() src/mp4file_io.cpp:354
    #3 0x7f4ade20b562 in mp4v2::impl::MP4StringProperty::Read(mp4v2::impl::MP4File&, unsigned int) src/mp4property.cpp:443
    #4 0x7f4ade1c7cc1 in mp4v2::impl::MP4Atom::ReadProperties(unsigned int, unsigned int) src/mp4atom.cpp:383
    #5 0x7f4ade182132 in mp4v2::impl::MP4HdlrAtom::Read() src/atom_hdlr.cpp:79
    #6 0x7f4ade1c6ab9 in mp4v2::impl::MP4Atom::ReadAtom(mp4v2::impl::MP4File&, mp4v2::impl::MP4Atom*) src/mp4atom.cpp:202
    #7 0x7f4ade1c8770 in mp4v2::impl::MP4Atom::ReadChildAtoms() src/mp4atom.cpp:435
    #8 0x7f4ade1c707b in mp4v2::impl::MP4Atom::Read() src/mp4atom.cpp:241
    #9 0x7f4ade1c6ab9 in mp4v2::impl::MP4Atom::ReadAtom(mp4v2::impl::MP4File&, mp4v2::impl::MP4Atom*) src/mp4atom.cpp:202
    #10 0x7f4ade1c8770 in mp4v2::impl::MP4Atom::ReadChildAtoms() src/mp4atom.cpp:435
    #11 0x7f4ade1c707b in mp4v2::impl::MP4Atom::Read() src/mp4atom.cpp:241
    #12 0x7f4ade1c6ab9 in mp4v2::impl::MP4Atom::ReadAtom(mp4v2::impl::MP4File&, mp4v2::impl::MP4Atom*) src/mp4atom.cpp:202
    #13 0x7f4ade1c8770 in mp4v2::impl::MP4Atom::ReadChildAtoms() src/mp4atom.cpp:435
    #14 0x7f4ade1c707b in mp4v2::impl::MP4Atom::Read() src/mp4atom.cpp:241
    #15 0x7f4ade1c6ab9 in mp4v2::impl::MP4Atom::ReadAtom(mp4v2::impl::MP4File&, mp4v2::impl::MP4Atom*) src/mp4atom.cpp:202
    #16 0x7f4ade1c8770 in mp4v2::impl::MP4Atom::ReadChildAtoms() src/mp4atom.cpp:435
    #17 0x7f4ade1c707b in mp4v2::impl::MP4Atom::Read() src/mp4atom.cpp:241
    #18 0x7f4ade1d898f in mp4v2::impl::MP4File::ReadFromFile() src/mp4file.cpp:457
    #19 0x7f4ade1d5417 in mp4v2::impl::MP4File::Read(char const*, MP4FileProvider_s const*, MP4IOCallbacks_s const*, void*) src/mp4file.cpp:101
    #20 0x7f4ade1b13e6 in MP4ReadProvider src/mp4.cpp:105
    #21 0x7f4ade1b1389 in MP4Read src/mp4.cpp:92
    #22 0x7f4ade2073f8 in MP4FileInfo src/mp4info.cpp:621
    #23 0x55c425fe597d in main util/mp4info.cpp:77
    #24 0x7f4add67cc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)

SUMMARY: AddressSanitizer: 256 byte(s) leaked in 1 allocation(s).

nextTrackId not set when file has invalid nextTrackid

When a file has nextTrackid that is in use the it is not changed after adding a new track

mp4v2/src/mp4file.cpp

Lines 2977 to 2988 in 86b5aaf

 // we need to search for a track id 

 for (trackId = 1; trackId <= 0xFFFF; trackId++) { 

 try { 

 (void)FindTrackIndex(trackId); 

 // KEEP LOOKING, this trackId is in use 

 } 

 catch (Exception* x) { 

 // OK, this trackId is not in use, proceed 

 delete x; 

 return trackId; 

 } 

 }

MP4V2_USE_STATIC_LIB should be defined in CMake when building static library for MSVC

Building the static library for MSVC fails with a number of DLL related errors, e.g:

error C2491: 'mp4v2::platform::io::FileSystem::DIR_SEPARATOR': definition of dllimport static data member not allowed

It also emits a number of similar warnings, e.g:

warning C4273: 'mp4v2::platform::io::FileSystem::exists': inconsistent dll linkage

This can be resolved by explicitly defining MP4V2_USE_STATIC_LIB in CMake when adding the target. This definition is already added explicitly in the Visual Studio project files currently checked in.

Heap-buffer-overflow mp4v2/src/mp4.cpp:519:33 in MP4GetVideoProfileLevel

project address

https://github.com/enzo1982/mp4v2

info

OS：Ubuntu20.04 TLS

Build: cmake . && make

mp4info - MP4v2 2.1.2

Poc

https://github.com/z1r00/fuzz_vuln/blob/main/mp4v2/heap-buffer-overflow/MP4GetVideoProfileLevel/id:000000%2Csig:06%2Csrc:000758%2Ctime:1159607%2Cexecs:323115%2Cop:havoc%2Crep:8

ASAN Info

./mp4info id:000000,sig:06,src:000758,time:1159607,execs:323115,op:havoc,rep:8

mp4v2/mp4info version 2.1.2
mp4v2_fuzzing/mp4info_out/fuzzer1/crashes/id:000000,sig:06,src:000758,time:1159607,execs:323115,op:havoc,rep:8:
ReadAtom: "mp4v2_fuzzing/mp4info_out/fuzzer1/crashes/id:000000,sig:06,src:000758,time:1159607,execs:323115,op:havoc,rep:8": atom type �ods is suspect
Read: "mp4v2_fuzzing/mp4info_out/fuzzer1/crashes/id:000000,sig:06,src:000758,time:1159607,execs:323115,op:havoc,rep:8": Mandatory descriptor 0x06 missing
ReadAtom: "mp4v2_fuzzing/mp4info_out/fuzzer1/crashes/id:000000,sig:06,src:000758,time:1159607,execs:323115,op:havoc,rep:8": invalid atom size, extends outside parent atom - skipping to end of "hinf" "dmax" 8458446 vs 4584
ReadAtom: "mp4v2_fuzzing/mp4info_out/fuzzer1/crashes/id:000000,sig:06,src:000758,time:1159607,execs:323115,op:havoc,rep:8": invalid atom size, extends outside parent atom - skipping to end of "stbl" "" 1953728578 vs 9686
ReadAtom: "mp4v2_fuzzing/mp4info_out/fuzzer1/crashes/id:000000,sig:06,src:000758,time:1159607,execs:323115,op:havoc,rep:8": atom type  is suspect
ReadChildAtoms: "mp4v2_fuzzing/mp4info_out/fuzzer1/crashes/id:000000,sig:06,src:000758,time:1159607,execs:323115,op:havoc,rep:8": In atom stbl missing child atom stsc
ReadAtom: "mp4v2_fuzzing/mp4info_out/fuzzer1/crashes/id:000000,sig:06,src:000758,time:1159607,execs:323115,op:havoc,rep:8": invalid atom size, extends outside parent atom - skipping to end of "moov" "�Ѱ>" 4026601461 vs 11495
ReadAtom: "mp4v2_fuzzing/mp4info_out/fuzzer1/crashes/id:000000,sig:06,src:000758,time:1159607,execs:323115,op:havoc,rep:8": atom type �Ѱ> is suspect
ReadAtom: "mp4v2_fuzzing/mp4info_out/fuzzer1/crashes/id:000000,sig:06,src:000758,time:1159607,execs:323115,op:havoc,rep:8": invalid atom size, extends outside parent atom - skipping to end of "" "miso" 829005910 vs 11597
MP4Track: invalid track (/home/z1r0/fuzzing/mp4v2/src/mp4track.cpp,239)
FindIntegerProperty: no such property - moov.iods.visualProfileLevelId (/home/z1r0/fuzzing/mp4v2/src/mp4file.cpp,831)
=================================================================
==168994==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000006190 at pc 0x7f0bc7cb947d bp 0x7ffd0e2ca310 sp 0x7ffd0e2ca308
READ of size 4 at 0x602000006190 thread T0
    #0 0x7f0bc7cb947c in MP4GetVideoProfileLevel /home/z1r0/fuzzing/mp4v2/src/mp4.cpp:519:33
    #1 0x7f0bc7d276bc in mp4v2::impl::PrintVideoInfo(void*, unsigned int) /home/z1r0/fuzzing/mp4v2/src/mp4info.cpp:404:20
    #2 0x7f0bc7d276bc in mp4v2::impl::PrintTrackInfo(void*, unsigned int) /home/z1r0/fuzzing/mp4v2/src/mp4info.cpp:543:21
    #3 0x7f0bc7d26889 in MP4Info /home/z1r0/fuzzing/mp4v2/src/mp4info.cpp:596:39
    #4 0x7f0bc7d28b82 in MP4FileInfo /home/z1r0/fuzzing/mp4v2/src/mp4info.cpp:627:18
    #5 0x5560e33e3b41 in main /home/z1r0/fuzzing/mp4v2/util/mp4info.cpp:77:22
    #6 0x7f0bc752e082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16
    #7 0x5560e32b451d in _start (/home/z1r0/fuzzing/mp4v2/mp4info+0x2151d)

0x602000006191 is located 0 bytes after 1-byte region [0x602000006190,0x602000006191)
allocated by thread T0 here:
    #0 0x5560e33991a7 in malloc /home/aep/Downloads/llvm-project-llvmorg-17-init/compiler-rt/lib/asan/asan_malloc_linux.cpp:69:3
    #1 0x7f0bc7c1a3c2 in mp4v2::impl::MP4Malloc(unsigned long) /home/z1r0/fuzzing/mp4v2/./src/mp4util.h:63:15
    #2 0x7f0bc7d0c84f in mp4v2::impl::MP4BytesProperty::GetValue(unsigned char**, unsigned int*, unsigned int) /home/z1r0/fuzzing/mp4v2/src/mp4property.h:479:30
    #3 0x7f0bc7d0c84f in mp4v2::impl::MP4File::GetBytesProperty(char const*, unsigned char**, unsigned int*) /home/z1r0/fuzzing/mp4v2/src/mp4file.cpp:1004:37
    #4 0x7f0bc7d0c84f in mp4v2::impl::MP4File::GetTrackBytesProperty(unsigned int, char const*, unsigned char**, unsigned int*) /home/z1r0/fuzzing/mp4v2/src/mp4file.cpp:3254:5
    #5 0x7f0bc7d11586 in mp4v2::impl::MP4File::GetTrackESConfiguration(unsigned int, unsigned char**, unsigned int*) /home/z1r0/fuzzing/mp4v2/src/mp4file.cpp:3668:9

SUMMARY: AddressSanitizer: heap-buffer-overflow /home/z1r0/fuzzing/mp4v2/src/mp4.cpp:519:33 in MP4GetVideoProfileLevel
Shadow bytes around the buggy address:
  0x602000005f00: fa fa 04 fa fa fa 01 fa fa fa fd fd fa fa 04 fa
  0x602000005f80: fa fa 04 fa fa fa 04 fa fa fa fd fa fa fa 00 00
  0x602000006000: fa fa 00 fa fa fa 04 fa fa fa 00 00 fa fa 00 fa
  0x602000006080: fa fa 04 fa fa fa 00 00 fa fa 00 fa fa fa 04 fa
  0x602000006100: fa fa 00 00 fa fa fd fa fa fa 00 00 fa fa 00 00
=>0x602000006180: fa fa[01]fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x602000006200: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x602000006280: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x602000006300: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x602000006380: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x602000006400: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==168994==ABORTING

Reference

https://github.com/z1r00/fuzz_vuln/blob/main/mp4v2/heap-buffer-overflow/MP4GetVideoProfileLevel/readme.md

Memory Leak in MP4BytesProperty

I found a memory leak error in mp4property.cpp:533; it seems that the value of the member variable count is inconsistent.

Environment

OS: Ubuntu 18.04.6 LTS
Compiler: gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)

Compilation

autoreconf -i
CC=gcc CXX=g++ CFLAGS='-fsanitize=address -g' CXXFLAGS='-fsanitize=address -g' ./configure
make -j32

Command Line

./mp4info poc_BytesProperty.mp4

POC

poc_BytesProperty.mp4.zip

Report

/home/poc/mp4v2/.libs/mp4info version 2.1.2
/home/poc/poc_BytesProperty.mp4:
ReadAtom: "/home/poc/poc_BytesProperty.mp4": invalid atom size, extends outside parent atom - skipping to end of "" "moov" 11495 vs 896
Read: "/home/poc/poc_BytesProperty.mp4": Mandatory descriptor 0x0e missing
Read: "/home/poc/poc_BytesProperty.mp4": Mandatory descriptor 0x0e missing
Read: "/home/poc/poc_BytesProperty.mp4": Mandatory descriptor 0x0e missing
Read: "/home/poc/poc_BytesProperty.mp4": Mandatory descriptor 0x0e missing
Read: "/home/poc/poc_BytesProperty.mp4": Mandatory descriptor 0x0e missing
Read: "/home/poc/poc_BytesProperty.mp4": Mandatory descriptor 0x0e missing
Read: "/home/poc/poc_BytesProperty.mp4": Mandatory descriptor 0x0e missing
Read: "/home/poc/poc_BytesProperty.mp4": Mandatory descriptor 0x0e missing
Read: "/home/poc/poc_BytesProperty.mp4": Mandatory descriptor 0x0e missing
Read: "/home/poc/poc_BytesProperty.mp4": Mandatory descriptor 0x0e missing
Read: "/home/poc/poc_BytesProperty.mp4": Mandatory descriptor 0x0e missing
Read: "/home/poc/poc_BytesProperty.mp4": Mandatory descriptor 0x0e missing
Read: "/home/poc/poc_BytesProperty.mp4": Mandatory descriptor 0x0e missing
Read: "/home/poc/poc_BytesProperty.mp4": Mandatory descriptor 0x0e missing
Read: "/home/poc/poc_BytesProperty.mp4": Mandatory descriptor 0x0e missing
Read: "/home/poc/poc_BytesProperty.mp4": Mandatory descriptor 0x0e missing
Read: "/home/poc/poc_BytesProperty.mp4": Mandatory descriptor 0x0e missing
Read: "/home/poc/poc_BytesProperty.mp4": Descriptor 0x10 has more than one instance
ReadProperties: atom 'iods' is too small; overrun at property:  (src/mp4atom.cpp,392)
/home/poc/mp4v2/.libs/mp4info: can't open /home/poc/poc_BytesProperty.mp4

=================================================================
==13934==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 3 byte(s) in 1 object(s) allocated from:
    #0 0x7f338562db40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
    #1 0x7f3384fdf4ac in mp4v2::impl::MP4Malloc(unsigned long) src/mp4util.h:63
    #2 0x7f3384ff0d89 in mp4v2::impl::MP4Calloc(unsigned long) src/mp4util.h:72
    #3 0x7f338507432f in mp4v2::impl::MP4BytesProperty::MP4BytesProperty(mp4v2::impl::MP4Atom&, char const*, unsigned int, unsigned int) src/mp4property.cpp:533
    #4 0x7f33850945b7 in mp4v2::impl::MP4CreatorDescriptor::MP4CreatorDescriptor(mp4v2::impl::MP4Atom&, unsigned char) src/ocidescriptors.cpp:202
    #5 0x7f3385095061 in mp4v2::impl::CreateOCIDescriptor(mp4v2::impl::MP4Atom&, unsigned char) src/ocidescriptors.cpp:296
    #6 0x7f338500bd3a in mp4v2::impl::MP4DescriptorProperty::CreateDescriptor(mp4v2::impl::MP4Atom&, unsigned char) src/descriptors.cpp:602
    #7 0x7f33850790f5 in mp4v2::impl::MP4DescriptorProperty::AddDescriptor(unsigned char) src/mp4property.cpp:904
    #8 0x7f3385079fa8 in mp4v2::impl::MP4DescriptorProperty::Read(mp4v2::impl::MP4File&, unsigned int) src/mp4property.cpp:1019
    #9 0x7f338503bfbf in mp4v2::impl::MP4Descriptor::ReadProperties(mp4v2::impl::MP4File&, unsigned int, unsigned int) src/mp4descriptor.cpp:122
    #10 0x7f338503b77e in mp4v2::impl::MP4Descriptor::Read(mp4v2::impl::MP4File&) src/mp4descriptor.cpp:80
    #11 0x7f338507a01a in mp4v2::impl::MP4DescriptorProperty::Read(mp4v2::impl::MP4File&, unsigned int) src/mp4property.cpp:1021
    #12 0x7f338502fcc1 in mp4v2::impl::MP4Atom::ReadProperties(unsigned int, unsigned int) src/mp4atom.cpp:383
    #13 0x7f338502f056 in mp4v2::impl::MP4Atom::Read() src/mp4atom.cpp:237
    #14 0x7f338502eab9 in mp4v2::impl::MP4Atom::ReadAtom(mp4v2::impl::MP4File&, mp4v2::impl::MP4Atom*) src/mp4atom.cpp:202
    #15 0x7f3385030770 in mp4v2::impl::MP4Atom::ReadChildAtoms() src/mp4atom.cpp:435
    #16 0x7f338502f07b in mp4v2::impl::MP4Atom::Read() src/mp4atom.cpp:241
    #17 0x7f338502eab9 in mp4v2::impl::MP4Atom::ReadAtom(mp4v2::impl::MP4File&, mp4v2::impl::MP4Atom*) src/mp4atom.cpp:202
    #18 0x7f3385030770 in mp4v2::impl::MP4Atom::ReadChildAtoms() src/mp4atom.cpp:435
    #19 0x7f338502f07b in mp4v2::impl::MP4Atom::Read() src/mp4atom.cpp:241
    #20 0x7f338504098f in mp4v2::impl::MP4File::ReadFromFile() src/mp4file.cpp:457
    #21 0x7f338503d417 in mp4v2::impl::MP4File::Read(char const*, MP4FileProvider_s const*, MP4IOCallbacks_s const*, void*) src/mp4file.cpp:101
    #22 0x7f33850193e6 in MP4ReadProvider src/mp4.cpp:105
    #23 0x7f3385019389 in MP4Read src/mp4.cpp:92
    #24 0x7f338506f3f8 in MP4FileInfo src/mp4info.cpp:621
    #25 0x5597552bf97d in main util/mp4info.cpp:77
    #26 0x7f33844e4c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)

SUMMARY: AddressSanitizer: 3 byte(s) leaked in 1 allocation(s).

Restructure command line utilities to support long options without short form

I came across the issue, that in the command line utilities the whole implementation is based on using options by having a single char as short option and a string as long option is a MUST, which limits the addable options to (readable) ASCII chars, but in fact they are even more limited to a-z A-Z 0-9, since -$ would not be very intuitive. And there are not many available chars for mp4tags left.

Not having to provide a short option for every parameter, so that existing API stuff could be wrapped into the utilities would be great.

So what I basically did in my branch is to take existing API functions and wrap them around a new option to support them to be set via command line and chose any available char instead of one that really made sense.

Here is an example:

#define OPT_SORT_NAME    'f'
#define OPT_SORT_ARTIST   'F'
#define OPT_SORT_ALBUM_ARTIST   'J'
#define OPT_SORT_ALBUM   'k'
#define OPT_SORT_COMPOSER   'K'
#define OPT_SORT_TV_SHOW   'W'

#define OPT_STRING  "r:A:a:b:c:C:d:D:e:E:g:G:H:i:I:j:l:L:m:M:n:N:o:O:p:P:B:R:s:S:t:T:x:X:w:y:z:Z:f:F:J:k:K:W:"

  "  -f, -sortname    STR  Set the sort name\n"
  "  -F, -sortartist  STR  Set the sort artist\n"
  "  -k, -sortalbum   STR  Set the sort album\n"
  "  -W, -sorttvshow  STR  Set the sort tv show\n"
  "  -J, -sortalbumartist STR  Set the sort album artist\n"
  "  -K, -sortcomposer    STR  Set the sort composer\n" 

  { "sortname",    prog::Option::REQUIRED_ARG, 0, OPT_SORT_NAME    },
  { "sortartist",  prog::Option::REQUIRED_ARG, 0, OPT_SORT_ARTIST  },
  { "sortalbum",   prog::Option::REQUIRED_ARG, 0, OPT_SORT_ALBUM   },
  { "sorttvshow",  prog::Option::REQUIRED_ARG, 0, OPT_SORT_TV_SHOW },
  { "sortalbumartist",   prog::Option::REQUIRED_ARG, 0, OPT_SORT_ALBUM_ARTIST },
  { "sortcomposer",      prog::Option::REQUIRED_ARG, 0, OPT_SORT_COMPOSER     },

  case OPT_SORT_NAME:
      MP4TagsSetSortName( mdata, tags[i] );
      break;
  case OPT_SORT_ARTIST:
      MP4TagsSetSortArtist( mdata, tags[i] );
      break;
  case OPT_SORT_ALBUM_ARTIST:
      MP4TagsSetSortAlbumArtist( mdata, tags[i] );
      break;
  case OPT_SORT_ALBUM:
      MP4TagsSetSortAlbum( mdata, tags[i] );
      break;
  case OPT_SORT_COMPOSER:
      MP4TagsSetSortComposer( mdata, tags[i] );
      break;
  case OPT_SORT_TV_SHOW:
      MP4TagsSetSortTVShow( mdata, tags[i] );
      break;

`mp4info` - Wrong duration value?

Hey @enzo1982,

recently I had an issue in m4b-tool, where mp4info reported a wrong duration value (I assume a wrong one, cause the user also reported it as wrong).

> mp4info 001-finished.m4b | grep secs
1       audio   MPEG-4 AAC LC, 213.179 secs, 67 kbps, 22050 Hz
>
> tone dump 001-finished.m4b | grep duration               
│          duration │ 00:03:33.134              │
>

mp4info - 213179ms
tone - 213134ms

The shift is only 45ms, but it is summing up to a greater value when using multiple files.

This is the first time ever that mp4info is wrong about the duration of a file, so I wonder, what the problem is. Surely, you cannot reproduce this without the files, but unfortunately, they can't be shared publicly. So let me know when you have the time to care about this - I'll invite you to a private repository to share one of the files with you, so that you can reproduce the problem.

Automatically switch to 64 bit atoms when writing large files

This came up in the initial discussion of this fork: #1 (comment)

I.e. there should be an option to make MP4v2 automatically switch to 64 bit atoms (e.g. co64 instead of stco) when writing large files. That way, applications creating MP4 files do not have to figure out upfront whether the output file will have to use 64 bit mode.

Support for HEVC video tracks

Thank you for reviving mp4v2 and Looking forward to your early support for the Hevc version

optimize option causes file seeks

on a file created with ffmpeg +faststart: no stream level seek

after: mp4chaps -Q -z -c file.m4b
mpv -v file.m4b

[file] stream level seek from 9008064 to 10035944
[file] stream level seek from 10167016 to 11084349
[file] stream level seek from 11215421 to 27858534
[file] stream level seek from 27989606 to 40439182
[file] stream level seek from 40570254 to 54068525
[file] stream level seek from 54199597 to 79229879
[file] stream level seek from 79360951 to 99149198
[file] stream level seek from 99280270 to 125359467
[file] stream level seek from 125490539 to 147375359
[file] stream level seek from 147506431 to 167293594
[file] stream level seek from 167424666 to 197696661
[file] stream level seek from 197827733 to 221809244
[file] stream level seek from 221940316 to 248018732
[file] stream level seek from 248149804 to 261647056
[file] stream level seek from 261778128 to 279470226
[file] stream level seek from 279601298 to 289954147
[file] stream level seek from 290085219 to 300437685
[file] stream level seek from 300568757 to 316163013
[file] stream level seek from 316294085 to 336082906
[file] stream level seek from 336213978 to 347614988
[file] stream level seek from 347746060 to 361244261
[file] stream level seek from 361375333 to 379065464
[file] stream level seek from 379196536 to 387452404
[file] stream level seek from 387583476 to 400033096
[file] stream level seek from 400164168 to 416807524
[file] stream level seek from 416938596 to 444065553
[file] stream level seek from 444196625 to 457694285
[file] stream level seek from 457825357 to 471323266
[file] stream level seek from 471454338 to 487049284
[file] stream level seek from 487180356 to 502774753
[file] stream level seek from 502905825 to 511162368
[file] stream level seek from 511293440 to 534227119
[file] stream level seek from 534358191 to 547856455
[file] stream level seek from 547987527 to 562534223
[file] stream level seek from 562665295 to 574066807
[file] stream level seek from 574197879 to 590840529
[file] stream level seek from 590971601 to 608662831
[file] stream level seek from 608793903 to 623339239
[file] stream level seek from 623470311 to 634872091
[file] stream level seek from 635003163 to 649549270
[file] stream level seek from 649680342 to 663177550
[file] stream level seek from 663308622 to 677855370
[file] stream level seek from 677986442 to 697775345
[file] stream level seek from 697906417 to 708259166
[file] stream level seek from 708390238 to 720839513
[file] stream level seek from 720970585 to 730274415
[file] stream level seek from 730405487 to 740757648
[file] stream level seek from 740888720 to 764871034
[file] stream level seek from 765002106 to 780596717
[file] stream level seek from 780727789 to 795274512
[file] stream level seek from 795405584 to 801565278
[file] stream level seek from 801696350 to 809952318
[file] stream level seek from 810083390 to 811000876
[file] stream level seek from 811131948 to 8987551

Seek issue with VS2022

There's a problem with file seeking with VS2022 (possibly others) when the library is built in it's default configuration (v2.1.1). The problem appears to be related to this code within file_win32.cpp

bool
StandardFileProvider::seek( Size pos )
{
#if _WIN32_WINNT >= 0x0600 // Windows Vista or later
    return _fseeki64( _file, pos, SEEK_SET );
#else
    // cause a cache flush before using _fileno routines
    fpos_t fpos;
    if ( fgetpos( _file, &fpos ) || fsetpos( _file, &fpos ) )
        return true;
    return _lseeki64( _fileno( _file ), pos, SEEK_SET ) == -1;
#endif

When I build the library, it generates code for the 'else' part of the conditional. Then for some reason, early on whilst parsing a m4a file, 'fpos' comes back with a negative number. Things seem to work for a bit after this but eventually it throws an assertion error when reading the header.

Setting _WIN32_WINNT to be 0x600 (or higher) such that it uses _fseeki64 seems to "fix" the problem. I'd say this is someting weird with the VS runtime library, I don't see this behaviour with VS2013.

QuickTime chapter track ID increases by 1 on every import

If you import the chapters multiple times it can get big

Does MP4v2 support fmp4 ( with moof box) format?

missing configure script

The configure script is missing, as such cannot build on macOS:

mkdir build
cd build
../configure --libdir=build/_libs --enable-static --disable-shared MP4V2_USE_STATIC_LIB=yes

I use mp4tags for one of my private projects, tag parsing needed fixing. For my workflow, I need to build with static libs - so there are no dependencies - can import a single binary (and no need to install mp4v2 library: macOS security!). Keep in mind, macOS requires all binaries (including dylib) to be code-signed. Installer for shared lib also complicates version updates.

Problem with writing publishing date (`-year`, `-y`)

With the current version 2.1.1 of mp4v2 the -year is not stored correclty in my use case, while my personal fork (https://github.com/sandreas/mp4v2/) works like expected.

The following command does not write the publishing date correctly (rldt atom):

mp4tags  -y '2018/10/30' my-file.m4b

Did something change? Or is it maybe my fault?

Thank you.

Does it support MP4CreateProvider

Additional tag options for mp4tags

Split from #2

@sandreas wrote:

BTW, this should go to a new issue, but if you would like to add some more atoms and parameters, you could refer to:

https://help.mp3tag.de/main_tags.html

https://wiki.hydrogenaud.io/index.php?title=Tag_Mapping

Here are some examples for additions, that I thought about integrating:

publisher -> ©pub

bpm -> tmpo

compilation -> cpil

conductor -> ©con

narrator -> ©nrt

movementname -> ©mvn

movement -> ©mvi

movementtotal -> ©mvc

Importing QT chapters adds extra mdat Atom

import qt chapters multiple times: mp4chaps -Q -c file.m4b

result:

Atom mdat @ 8987375 of size: 802529665, ends @ 811517040
Atom mdat @ 811517040 of size: 1767, ends @ 811518807
Atom mdat @ 811518807 of size: 1767, ends @ 811520574
Atom mdat @ 811520574 of size: 1767, ends @ 811522341
Atom mdat @ 811522341 of size: 1767, ends @ 811524108
Atom mdat @ 811524108 of size: 1767, ends @ 811525875
Atom mdat @ 811525875 of size: 1767, ends @ 811527642
Atom mdat @ 811527642 of size: 1767, ends @ 811529409

Heap-buffer-overflow mp4v2/src/mp4.cpp:520:47 in MP4GetVideoProfileLevel

project address

https://github.com/enzo1982/mp4v2

info

OS：Ubuntu20.04 TLS

Build: cmake . && make

mp4info - MP4v2 2.1.2

Poc

https://github.com/z1r00/fuzz_vuln/blob/main/mp4v2/heap-buffer-overflow/MP4GetVideoProfileLevel/id:000008%2Csig:06%2Csrc:000032%2B001084%2Ctime:20947124%2Cexecs:3427746%2Cop:splice%2Crep:2

ASAN Info

./mp4info id:000008,sig:06,src:000032+001084,time:20947124,execs:3427746,op:splice,rep:2

./mp4v2/mp4info version 2.1.2
mp4v2_fuzzing/mp4info_out/fuzzer1/crashes/id:000008,sig:06,src:000032+001084,time:20947124,execs:3427746,op:splice,rep:2:
Read: "mp4v2_fuzzing/mp4info_out/fuzzer1/crashes/id:000008,sig:06,src:000032+001084,time:20947124,execs:3427746,op:splice,rep:2": Mandatory descriptor 0x06 missing
ReadAtom: "mp4v2_fuzzing/mp4info_out/fuzzer1/crashes/id:000008,sig:06,src:000032+001084,time:20947124,execs:3427746,op:splice,rep:2": invalid atom size, extends outside parent atom - skipping to end of "" "mdat" 245779 vs 4600
FindIntegerProperty: no such property - moov.iods.visualProfileLevelId (/home/z1r0/fuzzing/mp4v2/src/mp4file.cpp,831)
=================================================================
==3317208==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000004314 at pc 0x7fb2b64ce45c bp 0x7ffde64ce930 sp 0x7ffde64ce928
READ of size 1 at 0x602000004314 thread T0
    #0 0x7fb2b64ce45b in MP4GetVideoProfileLevel /home/z1r0/fuzzing/mp4v2/src/mp4.cpp:520:47
    #1 0x7fb2b653c6bc in mp4v2::impl::PrintVideoInfo(void*, unsigned int) /home/z1r0/fuzzing/mp4v2/src/mp4info.cpp:404:20
    #2 0x7fb2b653c6bc in mp4v2::impl::PrintTrackInfo(void*, unsigned int) /home/z1r0/fuzzing/mp4v2/src/mp4info.cpp:543:21
    #3 0x7fb2b653b889 in MP4Info /home/z1r0/fuzzing/mp4v2/src/mp4info.cpp:596:39
    #4 0x7fb2b653db82 in MP4FileInfo /home/z1r0/fuzzing/mp4v2/src/mp4info.cpp:627:18
    #5 0x5653df466b41 in main /home/z1r0/fuzzing/mp4v2/util/mp4info.cpp:77:22
    #6 0x7fb2b5d43082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16
    #7 0x5653df33751d in _start (/home/z1r0/fuzzing/mp4v2/mp4info+0x2151d)

0x602000004314 is located 0 bytes after 4-byte region [0x602000004310,0x602000004314)
allocated by thread T0 here:
    #0 0x5653df41c1a7 in malloc /home/aep/Downloads/llvm-project-llvmorg-17-init/compiler-rt/lib/asan/asan_malloc_linux.cpp:69:3
    #1 0x7fb2b642f3c2 in mp4v2::impl::MP4Malloc(unsigned long) /home/z1r0/fuzzing/mp4v2/./src/mp4util.h:63:15
    #2 0x7fb2b652184f in mp4v2::impl::MP4BytesProperty::GetValue(unsigned char**, unsigned int*, unsigned int) /home/z1r0/fuzzing/mp4v2/src/mp4property.h:479:30
    #3 0x7fb2b652184f in mp4v2::impl::MP4File::GetBytesProperty(char const*, unsigned char**, unsigned int*) /home/z1r0/fuzzing/mp4v2/src/mp4file.cpp:1004:37
    #4 0x7fb2b652184f in mp4v2::impl::MP4File::GetTrackBytesProperty(unsigned int, char const*, unsigned char**, unsigned int*) /home/z1r0/fuzzing/mp4v2/src/mp4file.cpp:3254:5
    #5 0x7fb2b6526586 in mp4v2::impl::MP4File::GetTrackESConfiguration(unsigned int, unsigned char**, unsigned int*) /home/z1r0/fuzzing/mp4v2/src/mp4file.cpp:3668:9

SUMMARY: AddressSanitizer: heap-buffer-overflow /home/z1r0/fuzzing/mp4v2/src/mp4.cpp:520:47 in MP4GetVideoProfileLevel
Shadow bytes around the buggy address:
  0x602000004080: fa fa fd fd fa fa fd fa fa fa fd fa fa fa fd fa
  0x602000004100: fa fa 01 fa fa fa fd fd fa fa 04 fa fa fa 04 fa
  0x602000004180: fa fa 04 fa fa fa fd fa fa fa 00 00 fa fa 01 fa
  0x602000004200: fa fa fd fd fa fa 04 fa fa fa 04 fa fa fa fd fa
  0x602000004280: fa fa 00 00 fa fa 00 fa fa fa 00 00 fa fa fd fa
=>0x602000004300: fa fa[04]fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x602000004380: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x602000004400: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x602000004480: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x602000004500: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x602000004580: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==3317208==ABORTING

Reference

https://github.com/z1r00/fuzz_vuln/blob/main/mp4v2/heap-buffer-overflow/MP4GetVideoProfileLevel_2/readme.md

Question: playable mp4 file from header and segment

Edit:
I saw that general questions belong in the discussions section and not issues. I have created a discussion there:
#40

When playing back mp4 videos served with progressive http in a browser, it is possible to seek to specific segments and only download that section of the video without getting the rest of the file.
My goal is to prefetch such segments so I can play them back instantly at a later time.
Due to the constraints of my project, they would need to be in the form of playable mp4 files. Eg. 30s segment starting at 15min of a 2h video.
The source videos are encoded with fast start and byte ranges can be fetched from a remote server.
Would it be possible to use mp4v2 to achieve that?
My assumption is that I would read a segment that contains the header. Find the byte range that corresponds to the timestamps. Fetch that segment of the file. Append that to the header. And modify the header to account for these changes.
Is mp4v2 the appropriate tool for the job?
If not, are there any altiernatives?

Changes to MP4V2_PROJECT_build should not trigger rebuild of all objects

MP4V2_PROJECT_build is currently defined in project.h. This is included in mp4v2.h which is then included in many more places. Whenever the project is reconfigured (in my case any time I modify a CMake config), all objects become invalidated and have to be rebuilt again.

MP4V2_PROJECT_build is only used in libutil/Utility.cpp. This variable, since it changes more regularly than all of the other variables in project.h should be moved into a separate header and included only where needed. Currently this would mean that only libutil/Utility.cpp is recompiled when the project is reconfigured.

One option is to add project_build.h.in and include that only in libutil/Utility.cpp. This solves the issue for me locally using CMake.

An extension to this might be to also separate out the version variables, leaving only "static" variables in project.h, and then again only including project_version.h, for example, where those variables are needed.

There has a FPE(Floating Point Exception) in mp4trackdump.cpp:54, function DumpTrack().

mp4v2_trackdump_poc

Project address

https://github.com/enzo1982/mp4v2

POC

Poc file

afl_trackdump

asan_trackdump

Problem

There has a FPE(Floating Point Exception) in mp4trackdump.cpp:54, function DumpTrack(). Attackers cause denial of service through carefully constructed malicious files.

54              msectime /= timescale;

I use gdb debug this bug:

EFLAGS: 0x10246 (carry PARITY adjust ZERO sign trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
   0x427a9e <DumpTrack(void*, unsigned int)+190>:       xor    ecx,ecx
   0x427aa0 <DumpTrack(void*, unsigned int)+192>:       mov    edx,ecx
   0x427aa2 <DumpTrack(void*, unsigned int)+194>:       mov    rdi,QWORD PTR [rbp-0x68]
=> 0x427aa6 <DumpTrack(void*, unsigned int)+198>:       div    rdi
   0x427aa9 <DumpTrack(void*, unsigned int)+201>:       mov    QWORD PTR [rbp-0x38],rax
   0x427aad <DumpTrack(void*, unsigned int)+205>:       cmp    QWORD PTR [rbp-0x38],0x0
   0x427ab2 <DumpTrack(void*, unsigned int)+210>:       jne    0x427aed <DumpTrack(void*, unsigned int)+269>
   0x427ab8 <DumpTrack(void*, unsigned int)+216>:       movabs rax,0x442de8
[------------------------------------stack-------------------------------------]
0000| 0x7fffffffe030 --> 0x0
0008| 0x7fffffffe038 --> 0xf80d10 --> 0xf815a0 --> 0x7ffff7f9ec58 --> 0x7ffff7e2fe60 (<mp4v2::platform::io::File::~File()>:     push   rbp)
0016| 0x7fffffffe040 --> 0x0
0024| 0x7fffffffe048 --> 0x7ffff7ec221c (<MP4ReadProvider(char const*, MP4FileProvider const*)+204>:    mov    rax,QWORD PTR [rbp-0x20])
0032| 0x7fffffffe050 --> 0xf80d10 --> 0xf815a0 --> 0x7ffff7f9ec58 --> 0x7ffff7e2fe60 (<mp4v2::platform::io::File::~File()>:     push   rbp)
0040| 0x7fffffffe058 --> 0x1f7fc9130
0048| 0x7fffffffe060 --> 0x7fffffffe100 --> 0x7fffffffe1f0 --> 0x0
0056| 0x7fffffffe068 --> 0x7ffff7ed2a4e (<MP4FindTrackId(MP4FileHandle, uint16_t, char const*, uint8_t)+158>:   mov    ecx,DWORD PTR [rbp-0x58])
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
Stopped reason: SIGFPE
0x0000000000427aa6 in DumpTrack (mp4file=0xf80d10, tid=0x1) at /root/mp4v2/build/mp4v2/util/mp4trackdump.cpp:54
54              msectime /= timescale;
gdb-peda$ p timescale
$1 = 0x0
gdb-peda$

you can see 'timescale' is 0.It cause the SIGFPE.

ASAN report

(base) ➜  build git:(main) ✗ ./mp4trackdump ../../out1/default/crashes/id:000005,sig:08,src:000166+000357,time:3137250,execs:3545598,op:splice,rep:16

==2100718==ERROR: AddressSanitizer: FPE on unknown address 0x56363644d728 (pc 0x56363644d728 bp 0x7ffd22170500 sp 0x7ffd221704a0 T0)

#0 0x56363644d727 in DumpTrack(void*, unsigned int) (/root/mp4v2/build/mp4v2/build/mp4trackdump+0x2727)
#1 0x56363644e76a in main (/root/mp4v2/build/mp4v2/build/mp4trackdump+0x376a)
#2 0x7f647b7e6082 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24082)
#3 0x56363644d54d in _start (/root/mp4v2/build/mp4v2/build/mp4trackdump+0x254d)

Minimize the code size of the library

Hi everybody.
I need to use the mp4 library to support mp4 recording and demux in local storage (in SDcard) for IPC Camera. Does anyone have any ideas on how to reduce the code size of the library to fit embedded devices?
Thank you very much.
Sorry if I bothered anyone

Compile Error with Ubuntu 22.04LTS

It's worth noting that I switched to cmake and the installation works on Ubuntu 22.04, after installing cmake

! being overly verbose for other users, this part worked
$ sudo apt install cmake
$ cmake
$ make
! tried make install, here but since the installers are trying to move files to root owned folders, it errors out, switching to root.
$ sudo make install

This part did not work prior to using cmake
Without cmake... this is information for the dev

Compile Error when running make on xUbuntu ~ 22.04LTS build
$ uname -a
Linux XUBUNTU 5.15.0-58-generic #64-Ubuntu SMP Thu Jan 5 11:43:13 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Tried local user, tried root user, same outcome each time.

$ ./configure
$ make

trimmed

/bin/bash ./libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I./include -I./include -I. -I. -Wall -Wformat -g -O2 -fvisibility=hidden -c -o src/mp4file.lo src/mp4file.cpp
libtool: compile: g++ -DHAVE_CONFIG_H -I./include -I./include -I. -I. -Wall -Wformat -g -O2 -fvisibility=hidden -c src/mp4file.cpp -fPIC -DPIC -o src/.libs/mp4file.o
src/mp4file.cpp: In member function ‘char* mp4v2::impl::MP4File::MakeTrackEditName(MP4TrackId, MP4EditId, const char*)’:
src/mp4file.cpp:4160:17: warning: ‘.edts.elst.entries[’ directive output may be truncated writing 19 bytes into a region of size between 1 and 1024 [-Wformat-truncation=]
4160 | "%s.edts.elst.entries[%u].%s",
| ^~~~~~~~~~~~~~~~~~~
In file included from /usr/include/stdio.h:894,
from /usr/include/c++/11/cstdio:42,
from /usr/include/c++/11/ext/string_conversions.h:43,
from /usr/include/c++/11/bits/basic_string.h:6608,
from /usr/include/c++/11/string:55,
from /usr/include/c++/11/bits/locale_classes.h:40,
from /usr/include/c++/11/bits/ios_base.h:41,
from /usr/include/c++/11/ios:42,
from /usr/include/c++/11/istream:38,
from /usr/include/c++/11/fstream:38,
from ./libplatform/platform_base.h:6,
from ./libplatform/platform_posix.h:31,
from ./libplatform/platform.h:24,
from ./src/src.h:6,
from ./src/impl.h:6,
from src/mp4file.cpp:31:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:71:35: note: ‘__builtin___snprintf_chk’ output 23 or more bytes (assuming 1046) into a destination of size 1024
71 | return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1,
| ~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
72 | __glibc_objsize (__s), __fmt,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
73 | __va_arg_pack ());
| ~~~~~~~~~~~~~~~~~
/bin/bash ./libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I./include -I./include -I. -I. -Wall -Wformat -g -O2 -fvisibility=hidden -c -o src/mp4file_io.lo src/mp4file_io.cpp
libtool: compile: g++ -DHAVE_CONFIG_H -I./include -I./include -I. -I. -Wall -Wformat -g -O2 -fvisibility=hidden -c src/mp4file_io.cpp -fPIC -DPIC -o src/.libs/mp4file_io.o

Regardless of cmake or configure

I'm still getting errors with libmp4v2.so.2
$ mp4into --help
mp4info: error while loading shared libraries: libmp4v2.so.2: cannot open shared object file: No such file or directory

No OPUS identifier in audioType (MP4AddAudioTrack)

MP4V2_EXPORT
MP4TrackId MP4AddAudioTrack(
    MP4FileHandle hFile,
    uint32_t      timeScale,
    MP4Duration   sampleDuration,
    uint8_t       audioType DEFAULT(MP4_MPEG4_AUDIO_TYPE) );

there seems to be no audioType for OPUS which is understandable since its so new. My thought is this audioType should be the FourCC identifier and not the uint8_t. Would it be acceptable to allow for this reduction in audio identifiers? When I load a mp4 container the track does not contain this uint8_t so I assume its a binding id to the FourCC?

cmake check fails on Ubuntu 18.04

This is the output of cmake on Ubuntu 18.04 with cmake 3.10.2, trying to build git 347dab9:

% cmake ..
-- The C compiler identification is GNU 7.5.0
-- The CXX compiler identification is GNU 7.5.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Looking for include file inttypes.h
-- Looking for include file inttypes.h - found
-- Looking for include file stdint.h
-- Looking for include file stdint.h - found
-- Looking for include file stdio.h
-- Looking for include file stdio.h - found
-- Looking for include file stdlib.h
-- Looking for include file stdlib.h - found
-- Looking for include file string.h
-- Looking for include file string.h - found
-- Looking for include file sys/stat.h
-- Looking for include file sys/stat.h - found
-- Looking for include file sys/types.h
-- Looking for include file sys/types.h - found
-- Looking for include file unistd.h
-- Looking for include file unistd.h - found
-- Looking for stddef.h
-- Looking for stddef.h - found
-- Check size of ((struct stat*)0)->st_size
-- Check size of ((struct stat*)0)->st_size - done
CMake Error at CMakeLists.txt:56 (math):
  math EXPR called with incorrect arguments.


-- Configuring incomplete, errors occurred!
See also "/tmp/mp4v2/build/CMakeFiles/CMakeOutput.log".

It is working fine with cmake 3.16.3 on Ubuntu 20.04.

MP4v2 deletes all audio content when saving M4A files

(Original issue reported for Kid3)

MP4v2 Version: the one used as a plugin in Kid3 3.9.3 (probably MP4v2 v2.1.0 or v2.1.1)
This means that the issue might already be fixed in the latest version.

When I edit the tags of an MP4/M4A file that I downloaded from YouTube using kid3 and save them, all audio content gets stripped away. According to Urs Fleisch’s comment, it must be an issue with libmp4v2metadata.dylib.

Steps to reproduce in Kid3

Open an MP4/M4A audio file
Make any changes in the Tag 2: MP4 section
Press the Save button

Observed result

The file doesn't get corrupted, but the audio length becomes zero-duration and the file size shrinks down to a few bytes to kilobytes, i. e. it will only consist of the tags.

Expected result

MP4 tags are written and the audio is untouched.

Software/OS Versions

macOS Big Sur 11.6
Kid3 3.9.3
MP4v2 unknown version, probably 2.1.0 or 2.1.1

Additional information

With Kid3, I can avoid the problem by using TagLib instead of MP4v2. This raises the question: What is TagLib doing differently where MP4v2 fails?

enhancement: cmake option to install manual pages

Thank you for reviving mp4v2 and also for providing the CMAKE build procedure.

Would you consider adding an enhancement to the CMAKE build procedure to build and install the manual pages?

A common way is to add an option WITH_feature_name and also a BUILD_ALL option which turns on all the other options -- in this case build and install the manual pages as well the library and tools,

	// we need to search for a track id
	for (trackId = 1; trackId <= 0xFFFF; trackId++) {
	try {
	(void)FindTrackIndex(trackId);
	// KEEP LOOKING, this trackId is in use
	}
	catch (Exception* x) {
	// OK, this trackId is not in use, proceed
	delete x;
	return trackId;
	}
	}

enzo1982 / mp4v2 Goto Github PK

mp4v2's People

Contributors

Stargazers

Watchers

Forkers

mp4v2's Issues

Environment

Compilation

Command Line

POC

Report for POC_1

Report for POC_2

Heap-buffer-overflow mp4v2/src/mp4.cpp:519:33 in MP4GetVideoProfileLevel

project address

info

Poc

ASAN Info

Reference

Environment

Compilation

Command Line

POC

Report

Heap-buffer-overflow mp4v2/src/mp4.cpp:520:47 in MP4GetVideoProfileLevel

project address

info

Poc

ASAN Info

Reference

mp4v2_trackdump_poc

Project address

POC

Problem

ASAN report

trimmed

Steps to reproduce in Kid3

Observed result

Expected result

Software/OS Versions

Additional information

Recommend Projects

Recommend Topics

Recommend Org