What's the best software to reduce video file sizes?

[LOST TALE]

I think something that uses Variable bit rate would be best.

Something that can use my rx 56 vega to boost encoding times would be good aswell but not required.

The main quality goal is to preserve text legibility.

[System51]

I personally use HandBreake works fine with Nvidia I don't know if they added AMD support yet you can test that out. Also there are a bunch of tutorials about that programm so you won't have a hard time getting into that. 

[Electronics Wizardy]

What is the source footage?

Im a big fan of shutter encoder, and you can use your gpu with it, but depending on codec, the gpu encoder is much worse than using cpu power, so if you want small sizes id just use your cpu.

[LOST TALE]

1 hour ago, Electronics Wizardy said:

What is the source footage?

Im a big fan of shutter encoder, and you can use your gpu with it, but depending on codec, the gpu encoder is much worse than using cpu power, so if you want small sizes id just use your cpu.

codec is h264/AVC and it's a constant bitrate from radeon relive

[Electronics Wizardy]

8 minutes ago, LOST TALE said:

codec is h264/AVC and it's a constant bitrate from radeon relive

What codec do you want to turn it into? If you want smaller, probably go with h.265, and use cpu encoder for the best compression effiency.

[LOST TALE]

58 minutes ago, Electronics Wizardy said:

What codec do you want to turn it into? If you want smaller, probably go with h.265, and use cpu encoder for the best compression efficiency.

by compression efficiency, do you mean quality/size resulting in lower size same quality or better quality same size?

Is cpu being more efficient something normal or specific to your program?

[Electronics Wizardy]

1 hour ago, LOST TALE said:

by compression efficiency, do you mean quality/size resulting in lower size same quality or better quality same size?

Is cpu being more efficient something normal or specific to your program?

Compression effiency was my way of saying quality for a given size. Some encoders are better than others. Normally the hardware encoders found on gpus are some of the worst for effiency, with cpus being the best, but really depends. hardware encoders are faster.

[Mark Kaine]

handbrake 

 

youll get to half size pretty easily and readability will be at least ok.

 

[LOST TALE]

20 hours ago, System51 said:

I personally use HandBreake works fine with Nvidia I don't know if they added AMD support yet you can test that out. Also there are a bunch of tutorials about that programm so you won't have a hard time getting into that. 

does handbreak use variable or constant bitrate?

[LOST TALE]

20 hours ago, Electronics Wizardy said:

What is the source footage?

Im a big fan of shutter encoder, and you can use your gpu with it, but depending on codec, the gpu encoder is much worse than using cpu power, so if you want small sizes id just use your cpu.

doe shutter encoder use variable or fixed bitrate?

[System51]

1 minute ago, LOST TALE said:

does handbreak use variable or constant bitrate?

U can select that. There are a ton of options. 

[Mark Kaine]

14 minutes ago, LOST TALE said:

does handbreak use variable or constant bitrate?

both, you can choose... variable makes the most sense i guess.

[LOST TALE]

On 1/16/2022 at 2:41 PM, Electronics Wizardy said:

What is the source footage?

Im a big fan of shutter encoder, and you can use your gpu with it, but depending on codec, the gpu encoder is much worse than using cpu power, so if you want small sizes id just use your cpu.

2 pass, MaxQ cpu gave a bigger size than maxQ gpu. 

The AMD AMF encoder is not a dedicated encoder, just an interface with the GPU. It reduced a 33h (16.5h if 1 pass) workload to 0.5h and the file size was 550 instead of 600 MB. actually one had about 4% of the image cropped. Somehow the cpu one had the crop setting removed by accident.

 

Is cpu quality being superior just a speculation or something reliable? is it singificant? or should I just ignore it and use my gpu encoder to assist?

 

Results are

maxq	2pass	gpu	est time	VBR
yes	yes	no	33	1000
yes	no	no	16.5	1000
yes	no	yes	0.51	1000
no	no	no	1.75	1000
no	no	yes	0.33	1000

[Electronics Wizardy]

5 hours ago, LOST TALE said:

2 pass, MaxQ cpu gave a bigger size than maxQ gpu. 

The AMD AMF encoder is not a dedicated encoder, just an interface with the GPU. It reduced a 33h (16.5h if 1 pass) workload to 0.5h and the file size was 550 instead of 600 MB. actually one had about 4% of the image cropped. Somehow the cpu one had the crop setting removed by accident.

 

Is cpu quality being superior just a speculation or something reliable? is it singificant? or should I just ignore it and use my gpu encoder to assist?

 

Results are

maxq	2pass	gpu	est time	VBR
yes	yes	no	33	1000
yes	no	no	16.5	1000
yes	no	yes	0.51	1000
no	no	no	1.75	1000
no	no	yes	0.33	1000

You didn't compare quality here, just speed, and there are many more switches that will affect the speed of the encode.

 

If you want the best quality, cpu encoding is much better, but really depends on how much speed matters to you. You can really get in depth here, but something like x265 on slower id say is a good comprimise if you want good encode quality

[LOST TALE]

3 hours ago, Electronics Wizardy said:

You didn't compare quality here, just speed, and there are many more switches that will affect the speed of the encode.

 

If you want the best quality, cpu encoding is much better, but really depends on how much speed matters to you. You can really get in depth here, but something like x265 on slower id say is a good comprimise if you want good encode quality

what is slower id? What I would ask is if maxQ gpu encode > cpu encode without maxQ. If so, then GPU encode gives better quality with less time.

[Electronics Wizardy]

1 minute ago, LOST TALE said:

what is slower id? What I would ask is if maxQ gpu encode > cpu encode without maxQ. If so, then GPU encode gives better quality with less time.

You can test quality your self by seeing if it looks better, but the cpu should be able to do better quality for a given filesize here.

 

There is no fixed quality for the cpu, you can adjust it based on the balance of cpu usage and quality, so it can be faster with worse quality or slower with better quality on the cpu.

[LOST TALE]

5 minutes ago, Electronics Wizardy said:

You can test quality your self by seeing if it looks better, but the cpu should be able to do better quality for a given filesize here.

 

There is no fixed quality for the cpu, you can adjust it based on the balance of cpu usage and quality, so it can be faster with worse quality or slower with better quality on the cpu.

MaxQ or no MaxQ is the only quality setting I have besides 2 pass. So I'm asking based on these.

[Electronics Wizardy]

5 minutes ago, LOST TALE said:

MaxQ or no MaxQ is the only quality setting I have besides 2 pass. So I'm asking based on these.

can you show a screenshot? That shoudln't affect quality unless its picking the gpu your using

[Guest cumcwat]

Handbrake for me, clean, simple, and very easy to navigate with lots of options.

[LOST TALE]

On 2/2/2022 at 10:30 PM, Electronics Wizardy said:

can you show a screenshot? That shoudln't affect quality unless its picking the gpu your using

I don't know how it affects quality. I only know how it affects render times.

[mariushm]

The hardware encoder on the video card is optimized for speed (real time encoding) within the constraints of the hardware chip. So it trades off some quality for speed. You already lose some quality by capturing stuff with Relive, which uses the hardware encoder.

Compressing the video again using the hardware encoder will simply result in further quality loss, it's like opening a JPG picture with your favorite picture viewer and saving the picture again as another JPG file.

 

If you want to reduce the video size to upload to Youtube then it's not a good idea, because Youtube will take your video and recompress it again, so basically your content will go through 3 recompressions, each time losing some quality.

 

 

If you have a lot of disk space, your best option would be to skip Relive and use OBS with x264 software encoder configured when capturing stuff - but the trick is in what configuration options you use with the encoder.

You want to configure the encoder into a mode where it sort of works like saving a series of PNG pictures ... basically you tell the encoder you don't care about disk space, you don't want it to be "smart" and use a lot of cpu time to find things in the frames that can be compressed so that you end up with a low bitrate, you just want to work like a near lossless compressor. 

So in OBS, you can go and set it x264 as encoder and then go in configuration and you

* set it in CRF  (constant rate factor ) - think of it like picture quality level, where 0 is lossless and something like 50 is worst. The default for 8-12 GB 1080 videos would be around 18-22

You don't want to set it as 0 as that's lossless and some video editors don't support lossless h264 (4:4:4 Predictive), but you can set it at around 5-8, any lower you wouldn't notice quality difference.

Basically, that 5-8 range is like when you save a picture to JPG at quality 95-98%, practically almost lossless. You tell the encoder that as soon as it finds some stuff that can be removed without dropping the quality level lower than 95-98% jpg equivalent, the encoder should stop and be happy about it and move on to next frame, so you get very low cpu usage but disk space is higher.

* set the CPU Usage preset to Ultrafast. In CRF mode, the encoder stops as soon as that level of quality is reached, so this cpu usage preset doesn't matter. The higher we raise this preset, it just means the encoder spends more time figuring out what can be compressed more while still retaining that 95-98% jpg equivalent quality. So the more you increase this, the more cpu would be used, and you'd get less disk space used on your computer. But, you don't care about disk space because you'll recompress the video with high quality settings when you're done.

* tune ... there's no point to it here, it would help when you're recompressing this to a specific bitrate, to retain as much quality as possible.

Then you can add specific parameters in the x264 options

 

So basically, if you capture 1080p 60 Hz, with CRF 5-8  you will probably average around 80-150 mbps bitrate, or around 2-4 GB per minute, so one hour of recording would probably be around 200-300 GB.

However, you can then load that video into Handbrake or other software and configure either a CRF with higher value (ex 15-18 will probably result in around 30-50 mbps, maybe around 10 GB per hour ) or do 2-pass encoding with a specific bitrate, set tune to animation (for cell shading, pixel art, games with sharp edges), set preset to slower or very slow, set profile high, set

 

[LOST TALE]

On 2/8/2022 at 7:31 PM, mariushm said:

The hardware encoder on the video card is optimized for speed (real time encoding) within the constraints of the hardware chip. So it trades off some quality for speed. You already lose some quality by capturing stuff with Relive, which uses the hardware encoder.

Compressing the video again using the hardware encoder will simply result in further quality loss, it's like opening a JPG picture with your favorite picture viewer and saving the picture again as another JPG file.

 

If you want to reduce the video size to upload to Youtube then it's not a good idea, because Youtube will take your video and recompress it again, so basically your content will go through 3 recompressions, each time losing some quality.

 

 

If you have a lot of disk space, your best option would be to skip Relive and use OBS with x264 software encoder configured when capturing stuff - but the trick is in what configuration options you use with the encoder.

You want to configure the encoder into a mode where it sort of works like saving a series of PNG pictures ... basically you tell the encoder you don't care about disk space, you don't want it to be "smart" and use a lot of cpu time to find things in the frames that can be compressed so that you end up with a low bitrate, you just want to work like a near lossless compressor. 

So in OBS, you can go and set it x264 as encoder and then go in configuration and you

* set it in CRF  (constant rate factor ) - think of it like picture quality level, where 0 is lossless and something like 50 is worst. The default for 8-12 GB 1080 videos would be around 18-22

You don't want to set it as 0 as that's lossless and some video editors don't support lossless h264 (4:4:4 Predictive), but you can set it at around 5-8, any lower you wouldn't notice quality difference.

Basically, that 5-8 range is like when you save a picture to JPG at quality 95-98%, practically almost lossless. You tell the encoder that as soon as it finds some stuff that can be removed without dropping the quality level lower than 95-98% jpg equivalent, the encoder should stop and be happy about it and move on to next frame, so you get very low cpu usage but disk space is higher.

* set the CPU Usage preset to Ultrafast. In CRF mode, the encoder stops as soon as that level of quality is reached, so this cpu usage preset doesn't matter. The higher we raise this preset, it just means the encoder spends more time figuring out what can be compressed more while still retaining that 95-98% jpg equivalent quality. So the more you increase this, the more cpu would be used, and you'd get less disk space used on your computer. But, you don't care about disk space because you'll recompress the video with high quality settings when you're done.

* tune ... there's no point to it here, it would help when you're recompressing this to a specific bitrate, to retain as much quality as possible.

Then you can add specific parameters in the x264 options

 

So basically, if you capture 1080p 60 Hz, with CRF 5-8  you will probably average around 80-150 mbps bitrate, or around 2-4 GB per minute, so one hour of recording would probably be around 200-300 GB.

However, you can then load that video into Handbrake or other software and configure either a CRF with higher value (ex 15-18 will probably result in around 30-50 mbps, maybe around 10 GB per hour ) or do 2-pass encoding with a specific bitrate, set tune to animation (for cell shading, pixel art, games with sharp edges), set preset to slower or very slow, set profile high, set

 

Is there a better encoding algorithm for preserving text? My goal is not to preserve quality but to preserve a minimum level of quality to be able to read at the lowest size possible for archiving. For example, I crop the video and lower the audio to 64kbps and drop the FPS to as low as 3

edit: perhaps at my level of quality, those differences aren't worth the trouble?

 

2 pass enocidng was only allowed with CPU so I presume you were suggesting I use CPU only in handbrake. However single pass default quality took 1h45 with cpu whereas maxq single pass with gpu took 31 min. I'd ask which is better: A higher h265 quality setting with gpu or a normal h265 quality setting with cpu? Unfortunately I don't know what these quality settings actually are. All I see is MaxQ being on or off in the GUI.

 

I figured a higher quality encoding setting with gpu would beat a normal quality setting with the CPU, also the gpu was still faster as a bonus.

[Mark Kaine]

On 1/16/2022 at 8:41 PM, Electronics Wizardy said:

shutter encoder

holy shit i just tried this… reduced.a 14GB file (1 hour playtime) to 1.5GB… and it doesn't look like shit lol.

Whatever i tried in handbrake to reduce the file size typically resulted in grainy, pixelated image, the only way i could  reduce the size slightly was with pretty high settings, but that was only like 5GB --> 4GB maybe…

 

Im using h.264 --> mp4

and

CQ 28 for 1080p videos …

in Shutter Encoder  (also merge and stuff is cool i guess)