Activity › Forums › Adobe Premiere Pro › Premiere Pro lagging with H.264
-
Premiere Pro lagging with H.264
Sunderland Green replied 8 years, 6 months ago 8 Members · 21 Replies
-
Chris Borjis
March 27, 2017 at 8:23 pm[Jon Doughtie] “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.”
Ran into that recently with a live stream captured webinar.
Oddly media encoder CC 2015.2 will not fix that for a transcode,
but using apple compressor 3.5 to transcode does. -
James Agro
March 29, 2017 at 9:19 pmNope, 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.
-
Lorenzo Ciuciat
July 23, 2017 at 8:26 pmHi, 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.mp4Once 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 -
Chris Wright
July 24, 2017 at 1:08 amdoes the file size change with muxing? any quality loss? 10 bit support? if this works, then adobe should implement muxing instead of transcoding proxies.
-
Duke Sweden
July 24, 2017 at 2:50 pmI 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?
-
Lorenzo Ciuciat
July 24, 2017 at 6:05 pmbut “mov” files are already muxed… they have VIDEO and AUDIO in the same files… ‘right?
-
Duke Sweden
July 24, 2017 at 7:13 pmSo 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?
-
Duke Sweden
July 24, 2017 at 11:19 pmThanks, Dave. It appears I’ve been duped!!! Which is NOT short for duplicated!!! 😉
-
Lorenzo Ciuciat
July 24, 2017 at 11:57 pmneither do I: I don’t user QT codec so i don’t know the internal coding ☹
Thank you for sharing your knowledge here, anyway! 🙂
-
Lorenzo Ciuciat
July 25, 2017 at 12:06 amexact: muxing with the 2 parameters I wrote before (-vcodec copy -acodec copy) simply put the same streams in the container so there is NO transcoding (and no quality loss… and max speed!)
Reply to this Discussion! Login or Sign Up