[Lorenzo Ciuciat]

exact: 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!)

[Lorenzo Ciuciat]

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! 🙂

[Lorenzo Ciuciat]

but “mov” files are already muxed… they have VIDEO and AUDIO in the same files… ‘right?

[Lorenzo Ciuciat]

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