i7 8700K overclock for better h264 scrubbing performance?

[masai91]

I have to edit a big time lapse project shoot on GoPro with 4k video time lapse, h264 made in camera (it's 2 months worth of footage, so a lot of scrubbing is needed to find the best stuff)

I was wondering if overclocking will improve scrubbing performance and yield less dropped frames. If so how much do I need or can do with my cooler and if you have a guide to suggest.

Here's my system:

CPU: i7 8700k stock

Cooler: Noctua NH-U12S air cooler

Mobo: MSI Z370 tomahowk

RAM: 16GB DDR4 2666 (2x8gb)

GPU: MSI GTX 1060 6GB

M.2: Samsung 960 EVO 250GB (system and software including Premiere and default media cache folder)

SSD: Crucial 700GB (footage and projects, previews)

HDD: 4TB Seagate (archive)

Also since we're talking hardware I know 16GB or ram is probably not enough for 4k but is 32gb going to improve scrubbing performance? I don't think so, that's mostly CPU work to decode h264 footage right?

If you have any other suggestion about my system an maybe the way I've set up footage, projects, media cache etc let me know.

Thanks, have a nice day

[R Neil Haugen]

According to Intel, that thing "stock" is running at 3.7Ghz, pretty decent. Six cores, maybe 8/10 is better but that's a pretty decent 6-core CPU.

Long-GOP CPU work is heavily based on fast cores up to say 10, then having up to 10GB of RAM per core. You have less than 3Gb/RAM per core right now. You might get better results by getting more RAM than over-clocking, as going to 32GB would still be just over 5GB/RAM per core.

Of course, what's your use monitor show when exporting?

Neil

[masai91]

Thanks for the reply.

Can I ask why do we need 10GB or ram per core? Where does that number come from? I just want to understand how long-GOP playback works on NLEs

That number seams pretty high, especially with today's ram prices. I was going to upgrade to 32 when I build this pc but with those prices I just decided to stay with the 16gb that I had (paid only 60 euro at the time)

Rant aside..

Now that I test that I actually see the ram used by premiere jumping as high as 10gb while quickly scrubbing those clips. Which is close to the 11gb limit set into the setting (5gb reserved to other applications). Should I try to lower this a bit?

CPU usage is moving a lot but around 80-90%

While exporting the situation is different, CPU always higher then 90% and RAM pretty low, about 50-60% total usage and GPU depending on the effects applied obviously.

I'm going to create intermediate cineform files alter a first rough selection of the clips, so after that scrubbing should be a lot better. It's not that bad right now, it's definitely manageable, but if overclocking would have helped a little I would have done it since it's free.

[R Neil Haugen · Accepted solution]

It's the nature of long-GOP file structure.

This doesn't have actual frames ... there are only complete " i-frames " every 9-30 "frames", with all frames in-between contained in matrixed data sets of 1) the pixels that have changed since the preceding i-frame,  2) the pixels that *will*change before the next i-frame,  or ... 3) BOTH.

Some drones even use *partial* i-frames and have full ones up to 120 frames apart.

To turn that into visual frames requires decoding/decompressing the relevant i-frames and storing them to RAM, calling for the p or b frame data, recalling the complete frames from RAM, computing the next frame ... rinse and repeat.

The more data the CPU can hold in RAM the faster it can work.

Neil

[masai91]

Thanks, that totally makes sense.

I guess my next upgrade will be more RAM then.

In the meantime I just finished a rough select and exported in cineform, now it's smooth like butter

[R Neil Haugen]

Good to hear. There's a lot of people who think that a larger file is harder for the computer to process ... seems logical, right?

But as Jim Simon points out around "here" so often, it's precisely because they're larger that the Cineform files normally play back so well. In most computers, reading from drive is pretty fast ... and far less work on the CPU than re-creating frame-by-frame from a mix of other 'frames' and data-sets.

Cineform is also not a constant-bit codec, and with the wave-lets or whatever it is that the technical term is, Cineform is very good about being only as many bits on disc as are really needed ... but all bits that are needed are there.

Neil

[masai91]

Yes 100% agree. Since we are talking about cineform I want to ask you something else, then we can close this since it's pretty much solved.

I tried various export settings and checked for quality, since I didn't want to go all the way to the max to save a bit of space. I tried both DNxHR and cineform and landed on using Cineform 10bit quality 2, which is supposed to be medium quality around 230mb/s according to this: https://blog.frame.io/2017/02/13/50-intermediate-codecs-compared/

What I get is actually around 320-400mb/s so that's the reason I could't see a difference with the higher quality settings. Do you think that's correct?