Skip to main content
Horshack
Legend
May 6, 2017
Question

Using heavily-compressed H.264 for proxies

  • May 6, 2017
  • 3 replies
  • 6301 views

I know the prevailing wisdom is to use a lightly-compressed intermediate codec for proxies like CineForm to maximize responsive editing performance in Premiere. However I'm looking for a more compact codec for a future 4K project that I plan to edit remotely on a notebook - a codec small enough where I can fit everything on an internal SSD. So to start I went to the extreme and produced an ingest profile that goes all the way down to 480P 1Mbps on H.264 using a 10-second GOP. That yielded a proxy that's about 1.8% the size of the original 4K H.264 (ex: 611MB -> 11MB for a 90-second clip). Based on some cursory testing (scrubbing, edits, various effects) I'm not noticing a performance difference between this super-compressed proxy and CineForm, even for large files. I'm using a quad-core i7-4770 to test.

Does anyone have advice on what specifically I should test with respect to proxy performance to make sure I'm not missing something that will bite me later?

    This topic has been closed for replies.

    3 replies

    nicklear
    Inspiring
    August 31, 2018

    I have had good success with using these presets on my system for H.264 proxies. Where my machine struggles playing back 4K H.264 off my RAID, it does very well with the lower res 720p H.264 proxy files which I can fit on my SSD drive. For me if it works, it works.

    The main problem I having is that Premiere wants to make a .cfa audio file for each proxy file, as it does with any file that isn't 48kHz uncompressed audio. Is this normal? Do the cineform and prores proxy encoding settings use wav audio?

    Inspiring
    May 6, 2017

    Any time you are using an interframe codec such as H.264 versus an intraframe codec such as Cineform or ProRes you are adding an additional workload to your computer.

    For example in a 24fps project, Cineform presents 24 unique frames to the computer per second, while H.264 presents 3 packets of 8 frames each. The frames inside the packets are mixed together like pieces of a jigsaw puzzle in a carton, designed to minimize the amount of space the puzzle is taking up while in storage - but needing to be reassembled prior to being seen as an actual image.

    To play the Cineform the computer just plays the frames one after another, to play the H.264, the computer has load the GOP, reconstruct the individual frames out of each packet, and then display them - continuously.

    The apparent operational consequences of choosing one over the other for editing (as opposed to the impact on image quality, recompression artifacts, etc.) are basically a matter of computing horsepower - you need and will use a lot more horsepower to work with interframe codecs.

    MtD

    Horshack
    HorshackAuthor
    Legend
    May 6, 2017

    Yep, understood about the computing implications of using a long GOP - in fact I'm using a 10-second GOP for this test ingest profile. I'll have access to AC on the notebook so power consumption from a higher CPU utilization wont be an issue.

    Legend
    May 6, 2017

    Simple scrubbing shows a marked difference for me.

    Horshack
    HorshackAuthor
    Legend
    May 6, 2017

    Jim_Simon​, the only difference I see in scrubbing with the proxy is a long delay when I attempt to play backwards via JKL and stuttered reverse playback, which I don't do very often in my workflow. Scrubbing backward with the playhead seems responsive.

    Legend
    May 6, 2017

    Well, if it works...