Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Usage

Reply
 
Thread Tools Search this Thread Display Modes
Old 5th September 2015, 09:30   #1  |  Link
AlonP
Registered User
 
Join Date: Feb 2014
Posts: 20
Making HD material more compressible

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?
AlonP is offline   Reply With Quote
Old 5th September 2015, 10:20   #2  |  Link
Reel.Deel
Registered User
 
Join Date: Mar 2012
Location: Texas
Posts: 1,084
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.
Reel.Deel is offline   Reply With Quote
Old 5th September 2015, 11:25   #3  |  Link
kuchikirukia
Registered User
 
Join Date: Oct 2014
Posts: 385
spline36resize(1280,720)
kuchikirukia is offline   Reply With Quote
Old 5th September 2015, 11:33   #4  |  Link
feisty2
I'm Siri
 
feisty2's Avatar
 
Join Date: Oct 2012
Location: Los Angeles, California
Posts: 2,119
Blur(1).blur(1)...blur(1)
__________________
If I got new ideas, will post here: https://github.com/IFeelBloated
feisty2 is offline   Reply With Quote
Old 5th September 2015, 16:29   #5  |  Link
creaothceann
Registered User
 
Join Date: Jul 2010
Location: Germany
Posts: 360
Increase encoding time. (preset=placebo)
creaothceann is offline   Reply With Quote
Old 5th September 2015, 19:58   #6  |  Link
BakaProxy
Registered User
 
Join Date: Jan 2015
Posts: 47
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.
BakaProxy is offline   Reply With Quote
Old 5th September 2015, 20:20   #7  |  Link
johnmeyer
Registered User
 
Join Date: Feb 2002
Location: California
Posts: 1,985
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
johnmeyer is offline   Reply With Quote
Old 5th September 2015, 22:12   #8  |  Link
raffriff42
Retried Guesser
 
raffriff42's Avatar
 
Join Date: Jun 2012
Posts: 1,377
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.

Last edited by raffriff42; 6th September 2015 at 03:32.
raffriff42 is offline   Reply With Quote
Old 5th September 2015, 23:33   #9  |  Link
Reel.Deel
Registered User
 
Join Date: Mar 2012
Location: Texas
Posts: 1,084
Quote:
Originally Posted by BakaProxy View Post
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 .

-----

Quote:
Originally Posted by johnmeyer View Post
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.

Last edited by Reel.Deel; 6th September 2015 at 06:32. Reason: reply
Reel.Deel is offline   Reply With Quote
Old 6th September 2015, 03:20   #10  |  Link
johnmeyer
Registered User
 
Join Date: Feb 2002
Location: California
Posts: 1,985
Quote:
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.
johnmeyer is offline   Reply With Quote
Old 6th September 2015, 06:45   #11  |  Link
MysteryX
Soul Architect
 
MysteryX's Avatar
 
Join Date: Apr 2014
Posts: 2,108
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
MysteryX is offline   Reply With Quote
Old 6th September 2015, 07:46   #12  |  Link
creaothceann
Registered User
 
Join Date: Jul 2010
Location: Germany
Posts: 360
Quote:
Originally Posted by MysteryX View Post
3. Unless you need a specific file size, use constant quality, it does a great job.
Isn't CRF better?
creaothceann is offline   Reply With Quote
Old 6th September 2015, 08:20   #13  |  Link
Groucho2004
 
Join Date: Mar 2006
Posts: 3,717
Quote:
Originally Posted by creaothceann View Post
Isn't CRF better?
I'm quite certain that using CRF was implied when he suggested constant quality.
Groucho2004 is offline   Reply With Quote
Old 6th September 2015, 08:23   #14  |  Link
feisty2
I'm Siri
 
feisty2's Avatar
 
Join Date: Oct 2012
Location: Los Angeles, California
Posts: 2,119
Constant quality = qp != crf
__________________
If I got new ideas, will post here: https://github.com/IFeelBloated
feisty2 is offline   Reply With Quote
Old 6th September 2015, 08:58   #15  |  Link
vivan
/人 ◕ ‿‿ ◕ 人\
 
Join Date: May 2011
Location: Russia
Posts: 649
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.
vivan is offline   Reply With Quote
Old 6th September 2015, 09:00   #16  |  Link
Groucho2004
 
Join Date: Mar 2006
Posts: 3,717
Quote:
Originally Posted by feisty2 View Post
Constant quality = qp != crf
Have a look here

Quote:
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).
Groucho2004 is offline   Reply With Quote
Old 6th September 2015, 09:19   #17  |  Link
feisty2
I'm Siri
 
feisty2's Avatar
 
Join Date: Oct 2012
Location: Los Angeles, California
Posts: 2,119
Qp= constant OBJECTIVE quality
Crf= constant SUBJECT quality
I put my trust on objective stuff, not subjective
__________________
If I got new ideas, will post here: https://github.com/IFeelBloated
feisty2 is offline   Reply With Quote
Old 6th September 2015, 09:29   #18  |  Link
Groucho2004
 
Join Date: Mar 2006
Posts: 3,717
Quote:
Originally Posted by feisty2 View Post
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.
Groucho2004 is offline   Reply With Quote
Old 6th September 2015, 09:33   #19  |  Link
feisty2
I'm Siri
 
feisty2's Avatar
 
Join Date: Oct 2012
Location: Los Angeles, California
Posts: 2,119
The only way to keep it looking good is, pick lossless algorithms instead of lossy ones
__________________
If I got new ideas, will post here: https://github.com/IFeelBloated
feisty2 is offline   Reply With Quote
Old 6th September 2015, 09:48   #20  |  Link
creaothceann
Registered User
 
Join Date: Jul 2010
Location: Germany
Posts: 360
Quote:
Originally Posted by feisty2 View Post
The only way to keep it looking good is, pick lossless algorithms instead of lossy ones
So crf=1 looks bad to you?
creaothceann is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 03:29.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.