AMD h.264 Encoder Issue with FCP 11 and FCP 2.1 for iPad

The file is internally damaged, likely due to malformed Long GOP encoding structure. It fails on Resolve Studio 19.1.3 on MacOS and also Premiere Pro 25.1.0, if they have hardware decode acceleration enabled. That is a typical scenario since hardware decoding is more sensitive to illegal or damaged video encoding.

The bad file could be likened to contaminated gasoline, which causes one car to run roughly but not another car. The solution isn't enabling all cars to run on contaminated gas. Rather, the root cause of the contamination must be traced and the responsible party held accountable.

This is apparently a known issue and is causing problems for various software. You can Google "ROG Ally X video decoding error" and you'll see those. This cannot be fixed in FCP or Resolve or Premiere. It must be fixed at the source by whoever is responsible.

I'm working on a utility to scan for such contaminated files, but the task is very complex, so I haven't finished it yet. But that would only help identify such cases in the future.

It seems that movie can be fixed by losslessly rewrapping it with ffmpeg 7.1_3 (ffmpeg 4.4.5_4 does not fix it):

ffmpeg7 -i input.mp4 -c copy output.mp4

broken_rog_allyX_OBS_FCP_recording_rewrapped.mp4 in the link below:

https://www.dropbox.com/scl/fi/fjc3bghxwoy0vtrkle02o/broken_rog_allyX_OBS_FCP_recording_rewrapped.mp4?rlkey=n7tkkltv42bcr4b08zaro3uvj&dl=0

Matti, thanks for that. The rewrapped file seems to work in FCP, Resolve and Premiere using hardware decoding on all three. However, I noticed there is still a duration mismatch between video: 9.833s vs audio: 9.771s. That might indicate there's something still wrong with it. OTOH, if rewrapping works, that implies a container-level issue.

This H.264 video was encoded by an ASUS Ally X gaming handheld. A professional manufacturer should subject video datastream output of their devices to stringent tests using QC suites such as Elecard StreamEye.

However, unlike standards such as Radio Frequency Interference, AC power safety, etc, there is no licensing or regulatory oversight of data output quality. A hardware or software component could easily spew subtly damaged video data around the world. It's often hard to know where the file even came from.

This is a big problem because even expert end users or video editors do not have access to professional QC tools that check every aspect of the encoded stream, from the highest-level container format down to individual NAL units and their parameters. The assumption is the hardware or software that encoded that file was tested and validated by conscientious engineers. That seems to not be the case with the ASUS Rog X.

H.264 can be recorded in a multitude of ways. There are many parameters that can be tweaked. I think we'd need to know the specifics of the H.264 files the ROG is recording. Not all H.264 files will play in all video playback hardware/software. It's not a universal thing. And no software vendor is able to test every scenario and every combination of software hardware in the universe. It's too overwhelming of a task.

I see something similar. The files seems to play fine in QT but appears broken in FCP11 (on Intel iMac). The clip is mostly green and when the content is visible it's almost like i frames are misplaced so it's jumpy and erratic. Optimizing the clip makes it better but not entirely. Nothing jumps out to me in Invisor or ffprobe. Maybe @joema or @Matti can see something.

Thank you Matti and joema.

@_wick3d_, as joema says, the correct way to resolve this is for ASUS to fix their encoder. I suggest you contact their support with the details and a link to this discussion.

In the meantime, as Matti showed, you can pretty quickly fix the broken files with ffmpeg. I use macports which is a really simple way to install thousands of open source projects on your Mac. Go to macports.org and follow the instructions to install. You can then easily install ffmpeg7 by entering this in the terminal.app:

sudo port install ffmpeg7 +nonfree

macports will take care of all the dependencies and install into /opt/local/ which Apple has stated they won't alter. I prefer this over something like homebrew which relies on the MacOS system utilities and can break their installs when the OS is updated.

The "+nonfree" instructs macports to also install support for aac.

Excerpt from the FCP system log when trying to play the OBS video file:

Still need to know the specifics of the ROG encoded files. If it's using the old Quicktime framework, that's out of date and unsupported, it won't work any longer.