News:

--

Main Menu

Merged MP4 file slow to load

Started by bobdeyoung, January 05, 2021, 05:24:32 PM

Previous topic - Next topic

bobdeyoung

Versioon 2.7.6, 64 bit Windows 10 Pro

I have merged two MP4 files together using the settings seen in the attached screenshot. Both MP4 files are encoded the same, only the content is different between them. The merging process completed normally however when I try and open the merged MP4 file in VLC, it takes much longer to open than a similarly sized MP4 file and also if I use MediaInfo to view the output file, it also takes a long time to load. I don't have this issue when opening up other large MP4 files in either VLC or MediaInfo. I have noticed in MediaInfo that the "Codec ID" of the merged file is "qt 0000.02 (qt )" , which is a Quicktime codec, whereas the source files used in the merge have a Codec ID is "mp42 (mp42/isom/avc1)". Could the fact that the merged file is encoded using Quicktime be causing the slow opening issue?

By the way, I tried changing the Output Format setting to Mkv Muxer and that output file opens quickly.

Thanks in advance for any comments or suggestions.

eumagga0x2a

The MP4 muxer in 2.7.6 was silently switching to MOV muxing mode when input was incompatible with MP4 (e.g. LPCM audio), producing MOV files with .mp4 as extension. MOV muxing mode was moved out of the MP4 muxer into a dedicated MOV muxer in August 2020.

I believe that the issue* with MOV files created by Avidemux you experience was fixed just a few days ago, please update to the latest nightly build (210104 or newer) --> https://avidemux.org/nightly/win64/

*) The 'chan' atom not written due to channel layout not set.

eumagga0x2a

Meanwhile, I was able to test on Windows 10 and on Windows 7 and can confirm that a QuickTime file ~ 1 hour in duration with LPCM audio makes Windows Explorer, Windows Media Player as well as the video player app which comes with Windows 10 hang for minutes. VLC was able to load and to seek in the file quickly.

No issues whatsoever with the same file on macOS using Finder and QuickTime and on Linux using Nautilus and VLC. All tests were carried out with the file copied to local storage.

Looks like an old bug in some multimedia framework in Windows.