for work on Nvidia embedded Jetson solution , i switch off MINIMP4_TRANSCODE_SPS_ID and fix compilation.

• offset is good on uint64.
• 40Go / 2hours for a MP4 file but unreadable.

So, i cant make a readable files with more than 4Go ... Beyond that , in MediaInfo , isTruncated status become TRUE and the file is unreadable into VLC/Mplayer.

I forgot something in code ?

Is it possible to take h265/x265/hvec file and aac files to make up an mp4? From my understanding the example only puts h264 into mp4 yes? What will it take to make to make the h265 and aac files mux into an mp4 using this library? Most of the muxers don't actually include h265 as a supported format in the muxer, any resources you can point me to on that please. Thank you.

Steps to reproduce:

1. Enable ENABLE_AUDIO in minimp4_test.c. Change resolution to 240x160.
2. Build minimp4_test with fdk-aac-2.0.1.
3. Download stream.h264 and stream.pcm from https://github.com/lieff/minirtmp.
4. Run following tests: ./minimp4_x86 -m stream.h264 stream.mp4 ./minimp4_x86 -m -s stream.h264 stream-s.mp4 ./minimp4_x86 -m -f stream.h264 stream-f.mp4
5. stream.mp4 and stream-s.mp4 are playable with audio. stream-f.mp4 is not playable.

Can you help to take a look? Thanks! stream-f.mp4.zip

i mux .265 file to an mp4 file ffmpeg cannot parse it

cl minimp4_test.c
ffmpeg -i 1.jpg 1.265
minimp4_test.exe 1.265 1.mp4
ffmpeg -i 1.mp4

export:

[AVBSFContext @ 0000016c771221c0] No start code is found.
1.mp4: could not find codec parameters
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '1.mp4':
  Metadata:
    major_brand     : mp42
    minor_version   : 0
    compatible_brands: mp42isom
  Duration: 00:00:00.03, bitrate: N/A
    Stream #0:0(und): Video: hevc (hvc1 / 0x31637668), none, 352x288, 56174 kb/s, 30 fps, 30 tbr, 90k tbn (default)
    Metadata:
      handler_name    : VideoHandler

Optionally Add TFDT to TRAF, so that the resulting fMP4 is compatible with https://www.w3.org/TR/mse-byte-stream-format-isobmff/ and can be played from a SourceBuffer in MediaSource.

The change is made to change nothing by default, and be enabled with a simple flag.

Resulting fMP4 played successfully with MediaSource on:

• Safari
• Firefox
• Chrome
• Edge

I'm using this library to mux a H.264 bitstream that contains type 9 NAL units (Access unit delimiter) before each full frame.

According to Wikipedia, the Unit Access Delimiter is used as a basic prefix NAL unit to aid in interpreting frames:

A set of NAL units in a specified form is referred to as an access unit. The decoding of each access unit results in one decoded picture. Each access unit contains a set of VCL NAL units that together compose a primary coded picture. It may also be prefixed with an access unit delimiter to aid in locating the start of the access unit.

The code on master will return an error if it encounters an AUD, whereas it seems to work fine by skipping over the NAL unit. I think this is because it's an optional 'helper' unit that the library does not depend on to correctly interpret the stream.

The code I've experimented with essentially changes a return err statement to instead continue parsing other NAL units in the buffer:

2343| if (9 == payload_type)
2344|     return err; /* access unit delimiter */

2343| if (9 == payload_type)
2344|     continue; /* access unit delimiter */

It would be nice not to have to maintain a long lived fork, so I'm submitting this as a way of opening discussion to solutions for handling such streams (as are produced by the built-in Windows H.264 Encoder). More than happy to contribute code.

static int transcode_nalu(h264_sps_id_patcher_t* h, const unsigned char* src, int nalu_bytes, unsigned char* dst)
{
    int old_id;

    ......

    switch (payload_type)
    {
    .......
    case 8:
    {
        int cb = patch_pps(h, bst, bdt, 0, &old_id);
        int id = find_mem_cache(h->pps_cache, h->pps_bytes, MINIMP4_MAX_PPS, dst + 1, cb);
        if (id == -1)
            return 0;
        h->map_pps[old_id] = id;
        patch_pps(h, bs, bd, id, &old_id);
    }
    ......
}

    typedef struct
    {
        .......
        int map_sps[MINIMP4_MAX_SPS]; // MINIMP4_MAX_SPS equal to 32
        int map_pps[MINIMP4_MAX_SPS];

    } h264_sps_id_patcher_t;

Access to array 'pps' overflow cause by variable 'old_id' can be greater than 32.

Attached test2.264 (640x480) failed on all the 3 modes. But I'm able to do muxing with this bitstream using ffmpeg: $ ffmpeg -framerate 30 -i test2.264 -c copy test2.mp4

test2.264.zip

hi, this is great job. thanks for your code. I want to use this library to play annexb video streams in edge or chrome browser using mediaSource API. can you help me some usecase ,such as file output convert to stream buffer output.

-    int is_hevc = (0 != strstr(argv[1], "265")) || (0 != strstr(argv[i], "hevc"));
+    int is_hevc = (0 != strstr(argv[i], "265")) || (0 != strstr(argv[i], "hevc"));

// Second is optonal duration update at beginning of file in fragmenatation mode. ===> Proofread.

Thanks for the project.

While profiling minimp4 during MP4 encoding, find_start_code showed up as the most expensive function. Specifically, the first while loop searching for an initial zero byte. This is effectively what memchr() does, and glibc includes an optimized version of this method. Switching to memchr() showed a performance improvement in this method.

Hi @lieff .if you're open for paid consulting work in relation to this lib,please contact me via my email which you can find at my Github profile page.

when i am trying to convert H265 file to mp4 file i am seeing half image as gray in entire video. Please sagest what changes i need to do to solve this issue its not working for any mode and when i am converting it from ffmpeg its working fine. please help me.

Should fix issue #25 - I'm not sure where in the spec this is defined, but I've found references that state in MP4 files, the SLConfigDescriptor is required, and needs to be set to 2, see http://gpac.sourceforge.net/tutorial/bifs_part3.htm

Use case - generating fragmented MP4s for HLS streaming requires creating an initialization segment with decoder-specific config (the moov box). Manual flush allows writing out the moov box before adding samples.

Similar with write offset - after writing the moov box, one wants to write media segments that begin with a moof box and have 1 or more mdat boxes. This adds a method for overwriting the write offset, in case the library user wants to treat MP4E_mux_t as an opaque type.

These are actually 3 commits. The first fixes warnings (mainly signedness comparisons and unused stuff). The second adds MP4D_nearest_sync_frame which lets you find the nearest key/sync frame given any frame in the video stream. This is useful when implementing random access functionality and you want to start on a key frame. The third commit stores avc1 codec information. The WebCodecs API requires a valid codec string. To build this string you need the three bytes from the AVCDecoderConfigurationRecord. Maybe in the future we could also add a function to generate this string. :)

Please let me know if this ok or I should submit separate PRs.

Hi folks,

An interesting crash was found while fuzz testing of the minimp4_x86 binary which can be triggered via a malformed 264 file. Although this malformed file only crashes the program as-is, it could potentially be crafted further and create a security issue where these kinds of files would be able compromise the process's memory through taking advantage of affordances given by memory corruption. It's recommend to harden the code to prevent these kinds of bugs as it could greatly mitigate such this issue and even future bugs.

Repro crash.264.txt

$ minimp4_x86 crash.264 test.mp4
Segmentation fault (core dumped)

$ gdb -q minimp4_x86
Reading symbols from minimp4_x86...
(No debugging symbols found in minimp4_x86)

(gdb) r crash.264 test.mp4
Starting program: minimp4_x86 crash.264 test.mp4

Program received signal SIGBUS, Bus error.
0x0000555555558cac in patch_pps ()

(gdb) bt
#0  0x0000555555558cac in patch_pps ()
#1  0x0000555555555dd1 in main ()

(gdb) i r
rax            0x6510              25872
rbx            0x7fffffffcf70      140737488342896
rcx            0xfffffff8          4294967288
rdx            0xc204e00           203443712
rsi            0x1                 1
rdi            0x7fffffffcfb0      140737488342960
rbp            0x7fffffffd040      0x7fffffffd040
rsp            0x7fffffffcec8      0x7fffffffcec8
r8             0x2511              9489
r9             0x555555563679      93824992294521
r10            0x1                 1
r11            0x0                 0
r12            0x7fffffffcf6c      140737488342892
r13            0x37                55
r14            0x1926              6438
r15            0x555555563670      93824992294512
rip            0x555555558cac      0x555555558cac <patch_pps+44>
eflags         0x10206             [ PF IF RF ]
cs             0x33                51
ss             0x2b                43
ds             0x0                 0
es             0x0                 0
fs             0x0                 0
gs             0x0                 0

(gdb) x/i $rip
=> 0x555555558cac <patch_pps+44>:	mov    0xd80(%rbp,%rax,4),%r8d

(gdb) exploitable
Description: Access violation
Short description: AccessViolation (21/22)
Hash: 7bfba3fa9abe7b60a7e8004b251c9358.7bfba3fa9abe7b60a7e8004b251c9358
Exploitability Classification: UNKNOWN
Explanation: The target crashed due to an access violation but there is not enough additional information available to determine exploitability.