Premiere Pro lagging with H.264

James,

The advice you were given is the correct answer. H.264 is an extremely processor intensive codec and is not generally considered good for editing. Basically it is so compressed that your computer's cpu is having to decode it on the fly, which is a big burden. Choose a DNX or ProRes variety proxy file.

The latest version of Premier will automatically convert to a proxy on import if you set it up that way. Have you experimented with this? If your computer has trouble playing the DNX or ProRes then there are bigger problems going on. Perhaps drive speed?

Good luck.

Jud Archer
Apple / Adobe Systems

Thanks for your responses, However, I used to run an i7 4790, and that ran this same type of footage perfectly. But since I've got my new CPU (Ryzen 7 1800x 8c/16t) it is lagging. Does anyone think the issue could be to do with this?

One things that has not yet been mentioned is how and where you are storing your video. Where is your footage, and what is the connection type to the system? Internal drive, External? How connected? Please don't say your footage is on the C drive.

System:
Dell Precision T7600 (x2)
Win 7 64-bit
32GB RAM
Adobe CC 2015.02 (as of 6/2016)
256GB SSD system drive
4 internal media drives RAID 5
Typically cutting short form from HD MP4 and P2 MXF.

I have to second the thought that you really shouldn't have to transcode h.264
I haven't had to transcode anything since going from fcp 7 to premiere cs 5.5
The only footage that ever slows me down is Red4k these days.

I have an early 2009 mac pro with raid storage, 32gb of ram and
an old GTX 670 and CC 2015.2. Thing cuts h.264 like a hot knife through butter.


Have you tried lowering the program window resolution?

Maybe do a google search of premiere cc editing with the new Ryzen cpu?

Well, Ryzen is a brand new Architecture from AMD, It's an 8 core 16 thread CPU, It does outperform the $1000 Intel CPU often. It was designed for productivity, and reviewers show Premiere Pro benchmarks, in which it outperforms or matches the i7 5960x 8 core 16 thread CPU, which can be seen here:



.
I'm still a bit stumped on this whole thing, since I doubt it's anything to do with the CPU at all anyways. It could be, but I think it's some kind of software bug.

Thanks for the responses.

If that OBS you mentioned created variable frame rate videos, that is indeed the source of grief. You'll always want to transcode anything variable frame rate (like anything recorded on iPhones with the native app) to a codec with a fixed frame rate.

System:
Dell Precision T7600 (x2)
Win 7 64-bit
32GB RAM
Adobe CC 2015.02 (as of 6/2016)
256GB SSD system drive
4 internal media drives RAID 5
Typically cutting short form from HD MP4 and P2 MXF.

Nope, It was a constant frame-rate. It really just has problems with .mov from OBS, I really don't understand why, but since I'm using .mp4's from it, it works fine.

Hi, I hope to reply clearly to your question.
Following topics need to be know to understand the cause of the problem & the solution: stream, containter, index, transcode.

Adobe Premiere Pro cannot create a "transparent" index of raw H264 stream, so EVERY reposition in the timeline need a WHOLE reload the entire file (it doesn't matter if you go at the beginning, in the middle or at the end of the clip in the timeline). I have just verified this problem with APPRO 2017.1 using a raw 264 stream (without any container).

The simplest and faster solution is NOT TO TRANSCODE (any re-encoding of a stream modify the original stream: it can only become worste in quality) but to MUX the stream in a proper container. I usually use "FFMpeg" to do this task, with you HW specs you will be able to mux at OVER 1000 FPS (with a decent SSD).

You can use the following command to mux the single raw streams into a single muxed file:
ffmpeg -i video.264 -i audio.ac3 -vcodec copy -acodec copy muxed.mp4

Once muxed in the mp4 container via ffmpeg you can put it in the timeline in Premiere Pro and "VOIT LA" everything will be over 1'000x faster! (value based on a 13 GB raw h264 file: the bigger the file, the faster the index in the container will result).

Hope this will be useful for you. This cause can be self-checked using Microsoft (ex Sysinternals) "procmon" (Process Monitor) utility.

Lorenzo Ciuciat


Useful Links:
https://www.ffmpeg.org/
https://technet.microsoft.com/en-us/sysinternals/processmonitor.aspx
https://live.sysinternals.com/Procmon.exe

I have ffmpeg properly installed. Still figuring out how to mux a file named, say "hello.mp4" (or hello.mov, for that matter). I typed in your command ffmpeg -i video.264 -i audio.ac3 -vcodec copy -acodec copy muxed.mp4 and I get, in red, video.264: No such file or directory.

What would be the proper syntax? Also, if I have a folder with 100034.mov to 100045.mov, how would I mux the entire folder?

So does an mp4 file. I thought mux was a totally uncompressed file which, if I misunderstood you properly takes no time to transcode. So your "muxing" method is only to combine audio and video into one file?

"MUXED" is an abbreviation of "multiplexed". It refers to embedding the audio within the video track. Quicktime movies (mov) have a video track plus separate audio tracks within the same file. I don't know of any quicktime codec that will even support muxed audio.

Dave LaRonde
Promotion Producer
KGAN (CBS) & KFXA (Fox) Cedar Rapids, IA

neither do I: I don't user QT codec so i don't know the internal coding ☹

Thank you for sharing your knowledge here, anyway! :)