Making HD material more compressible

[AlonP]

Hi,

I have an hour and a half footage of my dad's birthday - there's lots of movement since ruskis+drinking=dancing and what not. Or at least they call it dancing... *shrugs*

At any rate, they want the video sent to their friends - so far a decent quality is achieved at ~8k bitrate. I'd like to make it much more compressible, without losing too much, and wuthout it taking more than 48 hours to encode(i7-950).

What filters/scripts would you guys suggest?

[Reel.Deel]

You can try STPresso: http://avisynth.nl/index.php/STPresso

Unfortunately for optimal results it's only recommended for resolutions up to 720p. I've never tried it with 1080p so I'm not sure how well it works.

[kuchikirukia]

spline36resize(1280,720)

[feisty2]

Blur(1).blur(1)...blur(1)

[creaothceann]

Increase encoding time. (preset=placebo)

[BakaProxy]

Wow these are like one of the most useless answers I've seen to date on such a basic problem.

Either way I'd first try to use variable bitrate instead of contstant. Then if downscaling is an option it's probably the easiest way to compress your video more. If not try getting rid of as much temporal noise (like grain), I suggest taking a look at smdegrain, despite the name it doesn't only work on grain as well. And lastly if that fails take a look at spatial denoisers like knlmeans, dfttest, f3kdb and/or gradfun3 from the dither package, those will help compressibility at the expense of detail. Well lastly, but honestly a given, use a decent encoder like x264 or possibly even x265 for this scenario.

[johnmeyer]

Short answer: encode to MP4 H.264 using Handbrake.

Use either VBR or constant (just to confuse things, I'd recommend "constant quality" encoding, but VBR works pretty well too). Handbrake tutorials are a dime a dozen, so just use Google to find one. Over at the Vegas forum, many people have done tests comparing different ways to get the "best" quality at low bitrates (i.e., for small file sizes), and Handbrake seems to have emerged as the overwhelming favorite, at least on that forum. It sure beats the two H.264 encoders built into the "professional" version of Vegas.

While Google will turn up lots of tutorials, here are two links that take you to two Vegas forum discussions about this subject:

The "well known" Handbrake tutorial?

handbrake tutorial

[raffriff42]

STPresso seems worth a look. But in general, yes, downsizing + temporal filtering is the way to go. Downsize especially if this is footage from a typical camera you see these days, with lots of advertised "megapixels" but with optical and noise problems that make that high resolution useless. Downsizing in that case loses very little information. (EDIT in fact it filters out some sensor noise)

And yeah, Handbrake has a reputation for being very bit-efficient for some reason.

[Reel.Deel]

Originally Posted by BakaProxy

Wow these are like one of the most useless answers I've seen to date on such a basic problem.

I don't think suggesting STPreso is a complete useless answer. Yeah I might of been vague but it did answer the OP's question (What filters/scripts would you guys suggest?). It's certainty more useful than "Blur(1).blur(1)...blur(1)" .

A while back I was encoding the 1st and 2nd season of "That '70s Show" , it was shot on film so some scenes where quite grainy and temporally unstable. I experimented with STPresso and other things but in the end I decided to lightly denoise the 1080p video with SMDegrain, downscale to 720P and then use STPresso. The compression gain was a bit better than just denoising with SMDegrain and then downscaling to 720p. I also did a few test encodes with various x264 settings to see which settings to choose for optimal compression/quality.

----

Isn't handbrake just a frontend for x264 (and other encoders)? AFAIK Handbrake doesn't do anything special, x264 is where all the magic happens .

-----

Originally Posted by johnmeyer

That statement overlooks two things:

1. Handbrake encodes to many formats, not just h.264.

2. Much more important, while decoding h.264 always produces identical quality results (CPU usage can vary), regardless of the decoder, encoding to h.264 is completely and totally different from one encoder to the next. Some are really good, and some are actually quite awful.

So, with some encoders, the magic doesn't happen. Put another way, h.264 is not a guarantee to good quality.

Since Handbrake is open source, and since I haven't looked carefully at its pedigree, I don't know where the h.264 encoding was developed, and whether it is identical to what can be found in, for instance, MeGUI. That happens to be what I use, and it also does a really good job with low-bitrate encodes. I use MeGUI because of its close coupling with AVISynth, but I've seen comparisons with Handbrake, and they seem to produce pretty similar results.

1) Yeah I know, that's why I said Handbrake is just a frontend for x264 and other encoders (x265, Xvid, etc).

2) Yup, specs require all H.264 decoders to be identical. Also I'm not talking about other encoders, I'm talking about x264, the encoder that Handbrake uses.

x264 is very popular and is considered to be the best H.264 encoder by some. There's no mystery why so many encoding apps use it (Handbrake and MeGui included). I've often see people giving high praises to such apps but fail to recognize the actual software behind the scenes that deserves the real credit. x264 is where all the magic happens.

[johnmeyer]

Isn't handbrake just a frontend for x264 (and other encoders)? AFAIK Handbrake doesn't do anything special, x264 is where all the magic happens .

That statement overlooks two things:

1. Handbrake encodes to many formats, not just h.264.

2. Much more important, while decoding h.264 always produces identical quality results (CPU usage can vary), regardless of the decoder, encoding to h.264 is completely and totally different from one encoder to the next. Some are really good, and some are actually quite awful.

So, with some encoders, the magic doesn't happen. Put another way, h.264 is not a guarantee to good quality.

Since Handbrake is open source, and since I haven't looked carefully at its pedigree, I don't know where the h.264 encoding was developed, and whether it is identical to what can be found in, for instance, MeGUI. That happens to be what I use, and it also does a really good job with low-bitrate encodes. I use MeGUI because of its close coupling with AVISynth, but I've seen comparisons with Handbrake, and they seem to produce pretty similar results.

[MysteryX]

1. Use KNLMeans to reduce noise
2. Use x264's preset veryslow or placebo
3. Unless you need a specific file size, use constant quality, it does a great job.
4. (optional) Resize to 720p as suggested and compare the quality/size difference

[creaothceann]

Originally Posted by MysteryX

3. Unless you need a specific file size, use constant quality, it does a great job.

Isn't CRF better?

[Groucho2004]

Originally Posted by creaothceann

Isn't CRF better?

I'm quite certain that using CRF was implied when he suggested constant quality.

[feisty2]

Constant quality = qp != crf

[vivan]

qp is constant quantizer ("quantization parameter").
crf is constant ratefactor which is an encoder's idea of quality.
As such crf is sometimes referred as "constant quality". qp? Almost never, except inferior encoders like xvid that lack crf.

[Groucho2004]

Originally Posted by feisty2

Constant quality = qp != crf

Have a look here

crf

Default: Not Set

The final ratecontrol method: Constant Ratefactor. While qp targets a certain quantizer, and bitrate targets a certain filesize, crf targets a certain 'quality'. The idea is for crf n to give the same perceptual quality as qp n, just in a smaller space. It is not extremely exact, but reasonably close (and will average out to be accurate over a large number of videos).

[feisty2]

Qp= constant OBJECTIVE quality
Crf= constant SUBJECT quality
I put my trust on objective stuff, not subjective

[Groucho2004]

Originally Posted by feisty2

Qp= constant OBJECTIVE quality
Crf= constant SUBJECT quality
I put my trust on objective stuff, not subjective

Almost all image, video and audio compression algorithms are based on models of human perception. I don't care how good the psnr or ssim values are, I want it to look good.

[feisty2]

The only way to keep it looking good is, pick lossless algorithms instead of lossy ones

[creaothceann]

Originally Posted by feisty2

The only way to keep it looking good is, pick lossless algorithms instead of lossy ones

So crf=1 looks bad to you?