Crash opening video-only MP4

[FeRD_NYC]

Today while trying to extract a section of video from an MP4, I discovered that avidemux was immediately crashing if it tried to open the file. Initially I encountered this with my installed version of 2.7.1 from the rpmfusion Fedora packages, but the crash is identical (though the traceback shows the expected differences) using the latest AppImage build.

MediaInfo has no trouble identifying the file's format properly, and it plays without incident in VLC. (I ended up extracting part of the video using VLC's Convert functionality, which messed up the start and end times but got me close enough to what I needed.)

The file is, specifically, a downloaded DASH part, the video side (only) of a web stream. I do not have the audio side, as I had no need for it and didn't bother to download it. So, this may be in some way related to a much older report of mine, regarding problems opening DASH parts. However, the error behavior is very different. (In that old report, avidemux 2.6.8 refused to recognize DASH mp4 parts as valid files, so it presumably never got far enough to crash.)

As I said, the video plays fine all the way through in VLC, which recognizes it as having no audio.

MediaInfo also recognizes its structure just fine, and I'll attach both the standard output (vid-info.txt) and excessively verbose --Full output (vid-fullinfo.txt) to this report.

The traceback contents have actually changed some, frustratingly. Earlier the crash was showing a specific location where it occurred. Unfortunately, I lost that output when I was forced to reboot, and now attempting to load the same file produces a traceback with no line number or source file name. I have no explanation for what changed, but again it's true of both the installed and AppImage versions, which previously both showed the same segfault location, and now both show none.

The current traceback, also attached as vid-crash.txt and vid-crash-AppImage.txt:

Code Select Expand


Segfault
at line 0, file ??
ADM_backTrack

MP4Header::indexify(MP4Track*, unsigned int, MPsampleinfo*, unsigned int, unsigned int*)
MP4Header::parseStbl(void*, unsigned int, unsigned int, unsigned int, unsigned int)
MP4Header::parseMdia(void*, unsigned int*, unsigned int, unsigned int)
MP4Header::parseTrack(void*)
MP4Header::lookupMainAtoms(void*)
MP4Header::open(char const*)
ADM_Composer::addFile(char const*)
A_openVideo(char const*)
avidemux3_qt5() [0x494352]
automation()
QMetaObject::activate(QObject*, int, int, void**)
QTimer::timeout(QTimer::QPrivateSignal)
QObject::event(QEvent*)
QApplicationPrivate::notify_helper(QObject*, QEvent*)
QApplication::notify(QObject*, QEvent*)
QCoreApplication::notifyInternal2(QObject*, QEvent*)
QTimerInfoList::activateTimers()

g_main_context_dispatch

g_main_context_iteration
QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>)

QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>)
QCoreApplication::exec()
UI_RunApp()
startAvidemux(int, char**)
main


I'm happy to supply the full file, if necessary. It's only 9.3MB, so email would work fine.

[FeRD_NYC]

As another option to emailing the full file, I sliced off the first 120KB, thinking that might be enough to demonstrate the issue. Sure enough, same exact crashes in both the installed and AppImage builds, while MediaInfo has no trouble identifying, and VLC has no trouble playing, the snipped off file as a 4-second video.

So I'll attach vid_start.mp4 to this reply, along with MediaInfo results for that file in both normal and full forms (vid_start-info.txt, vid_start-fullinfo.txt), and a traceback from the installed version of avidemux (vid_start-crash.txt — though it's literally identical to vid-crash.txt).

[eumagga0x2a]

Thank you, I confirm the crash. Nevertheless, it would be nice to have the complete file. To provide samples, please use WeTransfer, Mega, Dropbox, Google Drive or a similar service.

[FeRD_NYC]

vid.mp4 @ Google Drive

ETA: Though I'm worried Google may be "processing" it. Maybe I should've stuck it inside a .TAR archive.

[eumagga0x2a]

Thank you,

Code Select Expand

sha256sum vid.mp4
53e76505799e59ee26c20f70f9fe6917523c1eed63f4c7d89bb5f0e275141462  vid.mp4

ETA: Though I'm worried Google may be "processing" it. Maybe I should've stuck it inside a .TAR archive.

Google definitely feed everything users upload to Drive to their AI engine to extract information which might be of value for Google's customers (i.e. advertisers), which belongs to the rules of the "free" game, but I would not expect them to modify files.

[FeRD_NYC]

Well, right after I initially uploaded it that page literally said "Please wait, we're still processing..." or whatever, and the embedded streaming player wasn't showing yet. Just hard to know if that meant reencoding, virus-scanning, or... well, could be anything. Including farming for tracking data, which as you say is expected, and which I'm fine with as long as they don't muck with the actual data.

Regardless, it doesn't seem they did. I re-downloaded the video from that share page just now to check, and the download version has the same SHA1 checksum as the original upload.

Thanks for looking into this!