minimum memory consumption when encoding 8K video

[rhbc73]

Hi guys,

I'm using X265 (API) to encode an 8K video. I can see from resource manager that memory usage reaches 1.5GB after only 13 frames were sent to encoder and subsequent encode function call failed because out of memory. (1.5 GB memory were used in a 32bit program)

I've tried to set threadnumber to 1, set reference frame number to 3. but none of them works.

Does any one have suggestion how to minimise memory consumption so that I can encode an 8K in a 32bit program?

Thanks

[Midzuki]

Does any one have suggestion how to minimise memory consumption so that I can encode an 8K in a 32bit program?

Yes, just get a 64-bit machine with TONS of memory and use the 64-bit edition of x265.

Seriously.

I managed to encode 5K HEVC "stills" (i.e., 1-frame "videos") on a XP machine with 1GB of RAM... and it took "forever"...

Of course you could divide the video into, let's say, 10-frame segments, and later
concatenate all the encoded segments with the old copy /b...

but that wouldn't be very practical, right?

[littlepox]

I don't even think it's practical to encode 4K with 32bit x265.
Even you managed to do that, you will have to sacrifice a lot, which should result in very poor encoding quality. Then why don't you just downscale?

[benwaggoner]

Yeah, 32-bit x265 is quite a bit slower in general, and a 64-bit OS is pretty much a given these days. I know that MCW didn't ever consider doing any work to enable 4K on 32-bit, let alone 8K. Recall that 8K is 16x the pixels per frame of 1080p.

Also, with intra-frame prediction in HEVC, IDR frames do take longer to encode than IDR frames in older codecs, but can be way more efficient. So trying to encode 8K on a 32-bit machine is like trying to encode 1080p in 96 MB (1536/16)!

[rhbc73]

Hi guys,

My question is not "SLOW" on 32bit X265, but "Encode failure" because of out of memory.

If I stick to 32bit, is there any way letting encoder not to hold so many frames (in my case, x265 holds 13 frames before encode fails, why it holds so many frames? for encoding reference?).

Yes we'll provide both 32 and 64 bit version but since we still have a lot customers on 32bit, we'd like to provide a solution on 32bit.

Thanks

[Midzuki]

My question is not "SLOW" on 32bit X265, but "Encode failure" because of out of memory.

I've already suggested a workaround.
Which I think is somewhat OK, as long as small filesizes /big bitrate-savings are not the main goal of your 32-bit encodes...

[sneaker_ger]

@rhbc73
Try --preset faster (or lower) --rc-lookahead 0 --bframes 0 --frame-threads 2

[MeteorRain]

since we still have a lot customers on 32bit, we'd like to provide a solution on 32bit.

32-bit with 8K doesn't sounds practical. You only have a tiny 2GB memory space available. x265 usually use the memory space to optimize the output, i.e. pick a frame for IDR, or find some CUs to be referenced. Reducing the memory space then you have to sacrifice tons of features which makes 8K encoding pointless.

[benwaggoner]

@rhbc73
Try --preset faster (or lower) --rc-lookahead 0 --bframes 0 --frame-threads 2
I'd say --frame-threads 1 plus --lookahead-slices 1.

I doubt that a 32-bit machine has that many cores anyway, and a single 4-core with hyperthreading can easily saturate 4K, let alone 8K. So no need to have any slice-based parallelism at all.

But yeesh, still I don't see 8K as being feasible on a 32-bit OS. It would be much simpler to get a 64-bit machine I'd think, and a 64-bit machine could use a lot more memory and produce a lot better quality, because turning off rc-lookahead and b-frames is a big quality hit.