MP4 muxers

[Brazil2]

Originally Posted by FranceBB

MP4Box GUI 0.6.0.6, but it runs on an older version.

MP4-Mux-Tool uses recent versions of MP4Box
https://github.com/jlw4049/MP4-Mux-Tool

[kedautinh12]

Originally Posted by LigH

New uploads (MSYS2, MinGW32 / MinGW64, GCC 13.2):

MP4Box 2.3-DEV-rev937-g69b32cebf-ab-suite

GPAC 2.3-DEV-rev937-g69b32cebf-ab-suite


Another interactive MP4/MKV remux GUI tool: BOX4 (not sure which multiplexers it uses internally)

What's different between of gpac and non-gpac?

[LigH]

Please read:

https://gpac.io/
https://github.com/gpac/gpac/wiki/

In most cases related to (de-)multiplexing MP4 files, MP4Box is all you need, it is already complex enough; GPAC supports even more kinds of media manipulation by building "filter" chains and even trees. Do you remember GraphEdit for DirectShow filter graphs? GPAC is like that ... on steroids, but with a command line interface, and all in one binary.

[SeeMoreDigital]

I've just remembered...

Many years ago I used DVBPortal's MP4Multiplexer/Demultiplexer as well. It used something called mp4creator.exe.

https://www.videohelp.com/software/MP4Muxer

EDIT: Needless to say mp4creator.exe is years out of date and not suitable for todays needs!

[qyot27]

Originally Posted by SeeMoreDigital

I've just remembered...

Many years ago I used DVBPortal's MP4Multiplexer/Demultiplexer as well. It used something called mp4creator.exe.

https://www.videohelp.com/software/MP4Muxer

GStreamer has a particularly nasty bug with AAC streams muxed into MP4 by mp4creator that causes it to stop playing about halfway through the track, as if the file is truncated. libavcodec-based players and even faad can play/decode the entire length without issue, any players using GStreamer can't.

The same file (re)muxed with ffmpeg is totally fine in GStreamer, though. So it specifically has to do with how mp4creator arranges the atoms or something.

[manolito]

https://forum.doom9.org/showthread.p...36#post1998336

I cannot reproduce this issue, probably because my work flow is different.

Short Explanation:
My sources are mostly from YouTube or similar sites downloaded in the MP4 format (avc video in HD and aac audio). I leave the video untouched and manipulate the audio slightly. Then I save the result in the MKV format (simply because my old Xtreamer box likes the MKV format better than MP4).

These files are perfect for my needs, but sometimes a friend asks me for a certain video file. And most of my friends are Apple fan boys and want the files in the MP4 format instead of my MKV files. In these cases I repack the files to the MP4 format using FFMpeg (just change the container, no other changes), and so far I never got any complaints about seeking issues.

After reading Myrsloik's post I got curious and tested some of my MP4 files created from MKV files. And I could not find any seeking issues. MediaInfo reports 2 separate audio streams for the MP4, so the file size is marginally higher, but I could not see any of the problems which Myrsloik points out.

So is this really an FFmpeg issue with MP4 files? Maybe I should mention that my FFmpeg version is from January 2022 (last version which supports the Fraunhofer FDK AAC codec). And I need to use this AAC codec because my Xtreamer box tends to choke on AAC audio files created with FFmpeg.


Can someone enlighten me please? Maybe even uploat an MKV source file which shows this behavior after converting it to MP4 using FFmpeg?

Cheers
manolito

[SeeMoreDigital]

Out of interest...

Are there any MP4 muxers that are able to support .m2ts files that contain 'Dolby TrueHD with an AC3 core', or is the AC3 core always removed?

Cheers

[RBO]

As a GPAC implementor I don't think I have access to any such stream. Don't hesitate to share one if you want us to have a look.

[SeeMoreDigital]

Originally Posted by RBO

As a GPAC implementor I don't think I have access to any such stream. Don't hesitate to share one if you want us to have a look.

Any Blu-ray disc which has been encoded with Dolby TrueHD will offer this provided the Dolby TrueHD audio stream is kept within the .m2ts container and not re-muxed into the .mkv container.

Failing the above... It's possible to add a lossy AC3 stream into any lossless Dolby TrueHD stream using UsEac3To v1.3.3

Failing that failing... I shall also look for a short sample

EDIT: With any luck this link to my Microsoft OneDrive should work: https://1drv.ms/v/s!Aj3f3LPxO1ZSiBGD...083qE?e=SjePZf. Click on the download icon at the top left corner.

[Video Dude]

Originally Posted by manolito

After reading Myrsloik's post I got curious and tested some of my MP4 files created from MKV files. And I could not find any seeking issues. MediaInfo reports 2 separate audio streams for the MP4, so the file size is marginally higher, but I could not see any of the problems which Myrsloik points out.

I also never had any problems with ffmpeg produced mp4 files, which are thousands of files over the years. However, I don't remux mkv, my sources are mp4 and ts. I never had a seek or playback problem in any software or hardware player. I do a lot of editing with VideoReDo with the ffmpeg mp4s and I'm able to scrub and framestep the video (both forward and back) without issue.

Originally Posted by manolito

Can someone enlighten me please? Maybe even uploat an MKV source file which shows this behavior after converting it to MP4 using FFmpeg?

I think the test files can be found here
https://forum.doom9.org/showthread.p...36#post1992736

[manolito]

Thanks Video Dude for confirming my findings...

I did try the test files from your link, but they were not too helpful. Mostly the source mkv files were already broken, so it was no surprise that the resulting MP4 files were broken as well. The scenario which Myrsloik describes is different:

His mkv cource file has no search issues, but the MP4 file he gets after converting the source to MP4 using FFmpeg does have thouse search issues. And I cannot reproduce this problem, at least not for my source files (AVC video and AAC audio).

Maybe this is different for other source formats, so it would be nice if Myrsloyk or someone else could provide a link to a short MKV clip which has no problems, but which after converting it to MP4 using FFmpeg does show these issues.


Thanks again and cheers
manolito

[qyot27]

Originally Posted by qyot27

GStreamer has a particularly nasty bug with AAC streams muxed into MP4 by mp4creator that causes it to stop playing about halfway through the track, as if the file is truncated. libavcodec-based players and even faad can play/decode the entire length without issue, any players using GStreamer can't.

The same file (re)muxed with ffmpeg is totally fine in GStreamer, though. So it specifically has to do with how mp4creator arranges the atoms or something.

...And not even two months later, FFmpeg started hitting the exact same issue as GStreamer on a fresh install of Ubuntu 24.04 with FFmpeg and mpv from git. mp4creator-muxed files are truncated halfway through, but the same file played back on an older (2022) build of mpv on Windows has the entire length. 24.04 repository versions of faad and mediainfo also both report the correct length.

But considering I am far more comfortable bisecting FFmpeg than I would be trying to do that with the relevant plugin for GStreamer, I was able to find the commit that causes the issue. The thing that doesn't make any sense is that that commit would have been present in the version of FFmpeg and mpv I was using on 23.10 just a couple days ago...where the issue wasn't happening. So I have to investigate further - my fear(?) is that while that commit may be the source of the issue for FFmpeg, it may have only been exposed and triggered because of a change in some other low-level part of the OS or even in GCC (which I suspect because trying to bisect the issue on 24.04 exhibited the same problem even with old versions between that commit and HEAD, which again, makes no sense when it didn't do this a couple months ago on 23.10).

EDIT: It seems to be a *bit* more nuanced than that. mpv had a couple of workarounds for FFmpeg's support of MP4 advanced editlists that was removed back in January. My build of mpv must have predated that, because reverting the removal commit only from mpv and not from FFmpeg allowed the file to work the way it was intended. So yeah, some of these commits in FFmpeg do affect the default behavior when consuming mp4creator-muxed files, but FFmpeg does have an -ignore_editlists option that controls that behavior which breaks these files, and setting that option to 'true' allows FFmpeg to see the correct length and decode the file as intended. On mpv's side, that same option can be passed through --demuxer-lavf-o to achieve the same thing (although I don't know what setting that unconditionally would do as far as video playback is concerned), so no commit reverting is necessary. I hope this is the last time I have to say anything about this.

[LigH]

New uploads (MSYS2, MinGW32 / MinGW64, GCC 14.1):

MP4Box 2.5-DEV-rev461-ge2250d68-ab-suite

GPAC 2.5-DEV-rev461-ge2250d68-ab-suite

[FranceBB]

Originally Posted by LigH

New uploads (MSYS2, MinGW32 / MinGW64, GCC 14.1):

MP4Box 2.5-DEV-rev461-ge2250d68-ab-suite

GPAC 2.5-DEV-rev461-ge2250d68-ab-suite

Uh, I completely missed the fact that you were releasing standalone MP4Box builds. Up until now I've had to "extract" them from GPAC. I don't particularly care about GPAC, but I'll take a new build of MP4Box any day. Thank you!

[LigH]

forwards the to the MABS maintainers

[filler56789]

Originally Posted by LigH

New uploads (MSYS2, MinGW32 / MinGW64, GCC 14.1):

MP4Box 2.5-DEV-rev461-ge2250d68-ab-suite

GPAC 2.5-DEV-rev461-ge2250d68-ab-suite

for the fresh binaries.
Within some days, I will check whether the newest MP4Box finally started supporting VC-1 video and DTS audio

Very-unlikely, I know, but anyway, it's always good to bash the GPAC devilopers

[LigH]

New uploads (MSYS2, MinGW32 / MinGW64, GCC 14.2.0):

MP4Box 2.5-DEV-rev503-g25797108-ab-suite

GPAC 2.5-DEV-rev503-g25797108-ab-suite

[FranceBB]

Thanks for the new MP4Box build, as usual.

[LigH]

New uploads (MSYS2, MinGW32 / MinGW64, GCC 14.2):

MP4Box 2.5-DEV-rev816-g1bc97198-ab-suite

GPAC 2.5-DEV-rev816-g1bc97198-ab-suite

[FranceBB]

Oh, a new version of MP4Box, nice.
Time to update everything.
Thank you as always.