Media management trim corrupts files with extension .264

We've encountered corrupt trimmed files from sources with the file extension ".264"

These have been supplied by law enforcement as archive for a crime series, and all the problematic files are in the format:

"filename_H.264"

There is always a "H" character followed by ".264"

Media management frequently produces corrupt new trimmed source clips (displaying media offline on timeline monitor, however sources appear to present).

Other H264 archive clips wrapped as .mov or .mp4 don't seem to be affected.

I've searched for known bugs and limitations but haven't found anything. We've had to revert to the original master source clips.

Windows 10 pro
Resolve 19.1.4

H.264 is the raw codec in most cases. I'm suspecting that whatever process is used only writes the raw bitstream not in a container.
To verify, mediainfo https://mediaarea.net/en/MediaInfo will say something like

Code: Select all

Format                                   : AVC
Format/Info                              : Advanced Video Codec

If I'm right, any ffmpeg frontend can copy the video into a .mov or .mp4 container.

If I'm wrong, I'd reeeealy like the complete uncut mediainfo text.

Hi, thanks for the reply.

Mediainfo would imply they are actually .mp4

Perhaps they may have been wrangled badly, and the file extension has been lost?
I'd be very frustrated if someone had added a "." in a file name before the actual file extension.

Format : MPEG-4
Format profile : Base Media
Codec ID : isom (isom/iso2/avc1/mp41)
File size : 416 MiB
Duration : 59 min 57 s
Overall bit rate mode : Variable
Overall bit rate : 971 kb/s
Encoded date : UTC 2025-02-14 16:04:29
Tagged date : UTC 2025-02-14 16:04:29
Writing application : Lavf60.9.100

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L5.1
Format settings : CABAC / 4 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference frames : 4 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 59 min 53 s
Bit rate : 816 kb/s
Width : 704 pixels
Height : 480 pixels
Display aspect ratio : 3:2
Frame rate mode : Constant
Frame rate : 25.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.097
Stream size : 349 MiB (84%)
Writing library : x264 core 164 r3107 a8b68eb

Yep, sounds exactly like someone mistyped. I would bet that renaming to .mp4 will solve all your problems

There's also a "'#" symbol in each file name. Every instinct tells me this might be problematic too.

I've managed a closer look. Very odd but each new trimmed file is present in the media pool however they appear offline because they have been trimmed before the required TC, so they're all too short to supply the required media.

Is this a known H264 issue or should I just add it to the bad luck with this archive?

MP4 is not very reliable regarding TC. I'd try to re-wrap into MOV before trimming.

Hi Uli,

Prior to v19 I'd have definitely agreed with that, but since 19 we've had a lot of success. In this instance it's actually easier to revert back to the master clips.

The problem with these shows is the huge ratio of archive supplied to archive used - but I take the point.