Editing h.264/x.264 in Premiere Pro

[Angelo Lorenzo]

Have you tried using FFMPEG to just simply rewrap your files?

It’s command line but fairly easy, something like (this is off memory so expect to google this):
ffmpeg.exe -i input_file.mkv -codec copy output_file.mov

The extension of the output file will most easily denote what the container should be, in this case quicktime. There is no reencoding as it just copies over the h.264 and whatever audio streams.

[Robert Dodson]

Will that fix skipping? My understanding (I forgot to say this) was that h264 skips because it is not frame-accurate and therefore is no good for editing?; however during my research on this problem I discovered some HD video cameras record in MP4 natively, and it sounded like PPCS5.5 supports these files.

Anyway, I’ll try rewrapping with FFMPEG, thanks.

[Robert Dodson]

Hi Angelo,

At the beginning of the output I was getting a couple errors:
“Using MS style audio codec tag, the file may be unplayable!”
“[mov @ 00000000057A77E0] track 1: codec frame size is not set”

This was followed by Metadata, including chapters, and then
“Could not write header for output file #0 (incorrect codec parameters?)”

I tried disabling the audio stream with -an and used -vcodec to only copy the video stream. This worked correctly, but CS5.5 still won’t import the new file, calling it “unsupported format or damaged file”. CS4 wouldn’t import the new file until I changed the extension to .avi. I threw it onto the timeline and checked it quickly and it hasn’t skipped yet, but I’m too caught up in other work to do anything comprehensive at the moment. I’ll check back later.

[Robert Dodson]

Unfortunately the new .mov file still skips. Any other ideas?

[Cios Kappel]

I experienced the same issues in the following process:
– Create sequences with source material as proxies (.MTS footage off a Panasonic GH2 with custom firmware)
– Process source material in VirtualDub (for deshaking using Deshaker) and encode using x264vfw
– “Replace Footage” to get the deshaken versions into Premiere

The original material never showed any problems. Once replaced with the (audioless) deshaken versions, the problems started occuring (black/red frames at beginning and/or end of clips, repeated frames –> judder at random points in clips). Replacing them with the source material would result in problemless video yet again.

After a lot of trial/error and online research, I find the following things are suspect:
– Transitions, specifically Cross Dissolve
– Video For Windows (VfW)
– B-frames in the video stream

I’m afraid I was happy enough to be able to export a problem-free version of my current project that I am not able to point the finger at the culprit without doubt. It may very well be a combination of factors.

The things I tried in chronological order were:
– Clear the media cache and delete all renders for the project (this step actually happened regularly in the debugging process)
– Rename/delete the userAppdataRoamingAdobePremiere Pro5.5 directory
– Disable writing an XMP ID to the files
– Remove transitions on clips before replacing the footage
– Repackage the video streams in the .avi-files outputted by VirtualDub in .mp4 containers using ffmpeg (this seemed to do wonders initially, if only in speeding up Premiere operation)
– Disable h264 decoding in ffdshow VfW configuration (after reading about VfW’s issues with B-frames and having seen implied that Premiere might use external VfW codecs)
– Reencode the footage where problems were showing with settings that avoid B-frames altogether

I’m not sure what the role of transitions is in this, but I do feel that for clips that do not involve any transitions, I’ve had way less or even no problems with repeated frames. Having said that, only the reencoding without B-frames seems to have reliably removed the issues (although most of the replacement material in the aforementioned project _does contain B-frames_ and is rendered without issue).

You could use MediaInfo to inspect your problematic material. The encoding settings are most probably stored in the video descriptor. I’d definitely try reencoding with a B-frame-less setting.