Video editing newbie here. My understanding is that MPEG is the default proxy clip setting because it reduces processing load (I've never used MPEG in any other context). My hunch, though, is that x.264 would create a smaller file (and that MPEG2 is an intermediately between these two options).

My use-case is such that my proxy clips will likely stay on my hard-drive for years, so size is a bit of a concern.

Would a GPU with hardware x.264 decoding negate the benefits of MPEG and MPEG2? (if so, I'm assuming this would only work if GPU playback is enabled).

Also, I accidentally deleted the MPEG profile for proxy clips. Could someone point out where I could find it to recreate it?

Thanks,
kale

Hello,

Kdenlive relies on MLT backend, which unfortunately isn't really optimized for GPU hardware processing.
Many effects and transitions are CPU based, so the frames stored in GPU must be copied from and to GPU, which costs more time than the tasks the GPU did itself. Constraining MLT to remain on GPU for the whole pipeline (decoding/processing/encoding) would be a huge step forward, but nobody has done it yet, and it is quite complex as it requires good GPU knowledge (maybe Movit author has an idea, as he wrote this GPU effects library, but he is not focusing on MLT: integration of his library is very unstable).

Proxies offer fluid editing when resolution is reduced, of course, but also...
when full frames (I frames) are saved more often to ease navigation: H264 allows very large "group of pictures", so with certain encoder settings you may have to analyze hundreds of partial frames (P frames) to build the precise frame you want. MPEG2 usually limits the GOP to 12 or 15. And you can also have B-frames that are even more costly to compute.

With 17.12 release, we took a new look at our proxies settings.
We now rather propose DNxHD and MJPEG codecs, that store every frame with no frame-to-frame compression: they are very efficient to navigate, but cost more disk space.
We also introduced a x264 codec, but with encoder settings that disable P & B frames: slightly more compressed, still fast to decode.

Codecs are not the only determining parameter: container format can kill the seeking performance... such as the TS format we used to have by default!

Conclusion : please use the latest 17.12 version (AppImage is a good solution) with our new settings.
And try to find developers with GPU programming experience that would like to invest quite some time to bring MLT at a new level