What x264 level for SD?

[kkiller23]

I searched and didn't really find anything about SD, what would be the best level to use for SD?

Right now i'm using high@3.1

Would i notice any real difference if i moved to 4.1?

Here is the command i'm using
--level 3.1 --preset veryslow --tune film --pass 2 --bitrate 1620 --stats ".stats" --deblock 1:1 --keyint 240 --bframes 3 --ref 5 --merange 16 --subme 11 --partitions p8x8,b8x8,i4x4,i8x8 --output "output" "input"

If you have any suggestions that would improve the quality let me know, source is a blu-ray btw incase that matters. I'm trying to keep the final filesize in the 1gb range hence the bitrate and hence why i'm not using crf as it's a pain trying to get the filesize where i want it with crf.

here is the source
mediainfo
http://pastebin.com/BLzJZtPn
I used HD Streams Extractor that's why it's an mkv

[sneaker_ger]

Would i notice any real difference if i moved to 4.1?

No, none at all. Level 3.1 leaves plenty of room already.

http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Levels

[kkiller23]

So the levels don't actually improve the quality how do they work? more of just a limit or what?

[Atak_Snajpera]

it is just a label. level specifies maximal bitrate , resolution and fps which can be used

[kkiller23]

I have another question that's off topic, but what kind of filters could i use to improve quality? Right now this is all i use pretty much basic megui avs file
LoadPlugin("C:ffms2.dll")
FFVideoSource("C:T2_Video - .mkv", threads=1)
#deinterlace
crop(0, 128, 0, -138)
Spline36Resize(720,304) # Spline36 (Neutral)
#denoise

I pretty much know nothing about avisynth, i use megui in case the hd stream extractor wasn't a give away.
Could i use any other filters to make it look a bit better and more crisp? I know that it's not going to look amazing for the bitrate and filesize i'm going for, but still or am i pretty much doing all i can for quality?

[sneaker_ger]

Try experimenting with denoisers and/or higher resolutions. Even a NTSC DVD uses more lines.

[kkiller23]

Wouldn't making the resolution higher make it NON-SD? what would be a good denoiser as like i said i don't know much about avisynth and when googling it most of the results are like 3 years old.

[sneaker_ger]

Wouldn't making the resolution higher make it NON-SD?

If you want to continue using square-pixels (DVDs do not), then yes. Do you really need to stay "SD" in a time were smartphones do 1080p effortlessly, though?

what would be a good denoiser as like i said i don't know much about avisynth and when googling it most of the results are like 3 years old.

Take a look at the avisynth section, this question is discussed relatively often.

[Taurus]

Wouldn't making the resolution higher make it NON-SD? what would be a good denoiser as like i said i don't know much about avisynth and when googling it most of the results are like 3 years old.
Some month old:
http://forum.doom9.org/showthread.php?p=1527888#post1527888
and there are more...

[kkiller23]

I tried using MCTemporalDenoise.

I installed the MCTemporalDenoise.exe that came with all the filters etc you needed for the script to work, but now megui crashes when i try to load a avs

[detmek]

MeGUI has a few built-in denoisers. Try those. Also, MDegrain is not part of MeGUI but is usualy faster then MCTD. FFT3DFilter or FFT3DGPU? Dfttest?

[kkiller23]

MeGUI has a few built-in denoisers. Try those. Also, MDegrain is not part of MeGUI but is usualy faster then MCTD. FFT3DFilter or FFT3DGPU? Dfttest?

I found a MDegrain mod called SMDegrain v.2.0d atleast i think it's a MD mod, anyway i'm trying it now. It does seem pretty slow though.

[sneaker_ger]

Don't get too focused on the denoising. It was merely a suggestion to improve overall compression a bit, so you could up the resolution. Denoising in itself will probably not result in increased "crisp"yness.

[detmek]

Try like this:

super = MSuper(pel=2, sharp=1)
backward_vec2 = MAnalyse(super, isb = true, delta = 2, blksize=16, overlap=4)
backward_vec1 = MAnalyse(super, isb = true, delta = 1, blksize=16, overlap=4)
forward_vec1 = MAnalyse(super, isb = false, delta = 1, blksize=16, overlap=4)
forward_vec2 = MAnalyse(super, isb = false, delta = 2, blksize=16, overlap=4)
MDegrain2(super, backward_vec1,forward_vec1,backward_vec2,forward_vec2,thSAD=400)

or faster version:

super = MSuper(pel=2, sharp=1)
backward_vec1 = MAnalyse(super, isb = true, delta = 1, blksize=16, overlap=4)
forward_vec1 = MAnalyse(super, isb = false, delta = 1, blksize=16, overlap=4)
MDegrain1(super, backward_vec1,forward_vec1,thSAD=400)

Instead of increasing resolution, anamorphic encoding is far better option (clever (TM) anamorphic in MeGUI script creator).

[Groucho2004]

super = MSuper(pel=2, sharp=1)
backward_vec1 = MAnalyse(super, isb = true, delta = 1, blksize=16, overlap=4)
forward_vec1 = MAnalyse(super, isb = false, delta = 1, blksize=16, overlap=4)
MDegrain2(super, backward_vec1,forward_vec1,thSAD=400)
Don't you mean MDegrain1?

[kkiller23]

I tried a simple SMDegrain()


It's so slow just using that standard settings. I get about 5fps and i hardly notice any real difference in the sample encode i did.
http://screenshotcomparison.com/comparison/138668
I don't really think that is worth like an extra 13hrs to encode.


Is there any good filters that are fast like the one built into megui "fluxsmoothst" or should i just use that one?

[kalehrl]

RemoveGrain is very fast.
RemoveGrain(mode=1) - little noise
RemoveGrain(mode=5) - a bit more noise
RemoveGrain(mode=2) - a bit more
RemoveGrain(mode=17) - heavy noise
I mostly use mode=5 when encoding using h264 and mode=2 when doing xvid.

Regarding levels, you don't have to worry about them.
If you use a preset, encoder will always choose level 3 for SD and 4 for HD.

[Bloax]

RemoveGrain(5) Is less aggressive than RemoveGrain(1), because mode1-4+4 use some extra precaution.

[kalehrl]

The official plugin page says this:
As far as compression is concerned, my benchmarks so far give the following mode ranking: 4,17,9,8,3,7,6,2,5,1
So, mode=5 provides better compression than mode=1 which led me to conclude that mode=5 is more aggressive than mode=1.
How can a mode which gives less compression be more aggressive than the one that gives better compression?

[kkiller23]

I just went with RemoveGrain(mode=1) and it seems to look pretty good.


I have one more off topic question.

Can someone link me to like a complete tutorial for resizing. I don't fully understand the difference between DAR, AR and SAR and i'm not sure if i'm doing the correct stuff to come to the resized resolution etc so i'm worried that i'm doing stuff wrong. I just wana be sure that i fully understand what i'm doing and i'm doing it the correct way.

[blubb444]

http://en.wikipedia.org/wiki/Pixel_aspect_ratio

In short, if you have for example a (full-width) PAL DV-AVI file with a resolution of 720x576 and you want it displayed in a 15:11 frame as to not get any distortion, then you have to use anamorphic pixels, because if you displayed it with square pixels, then you'd end up having a 5:4 frame which is too narrow.
If we stay in the nomenclature of the Wiki article, then this means the following:
- The Storage Aspect Ratio (SAR) just means the relation of the dimensions of the video, therefore in this case it is 720:576 = 5:4
- The Display Aspect Ratio (DAR) is how you want the image to be displayed, in this case 15:11. In case of non-anamorphic video (which is usually pretty much all non-SD digital video except HDV), SAR=DAR.
- The Pixel Aspect Ratio (PAR) is how the single pixels must be shaped in order to get from the SAR to the desired DAR. The equation is DAR = SAR * PAR, which rearranges to PAR = DAR/SAR, in this case (15/11) : (5/4) = (15*4) : (11*5) = 60:55 = 12:11. In case of non-anamorphic video you have square pixels (1:1). Confusion arises because apparently sometimes this is called SAR instead ("sample aspect ratio") for example by x264.

Personally I'd only encode as anamorphic if the source is anamorphic too, for example a DVD (when I crop black bars from the bottom and top or when I just transcode then I simply reuse the original PAR and keep the storage width the same, this should be more efficient for an encoder because there's no horizontal upscaling involved, this is all done by the player then). Blu-Rays are usually 1920x1080 non-anamorphic. If, for whatever reason, you want to downscale that and play the file on your PC, hardware player etc, simply divide width and height by the same number (you'll need to round to mod2 for 4:2:0 source though, typically SD would be 854x480 then), in that case square pixels stay (almost) square pixels and you don't have to worry about PAR.
If you want to encode to DVD then you'll need anamorphic pixels though, 64:45 for PAL or 32:27 for NTSC.

But again, why would you even want to downscale in the first place or stay under 1GB? Multi-terabyte HDDs are a steal nowadays, 32 or 64GB SD cards aren't that expensive either.

[kkiller23]

I'm very bad at math so i use a resize calculator, but there is no option for anamorphic encoding so i really don't understand the math for it.

If i use square pixels it's pretty easy as i can use the resize calculator.

example

1920x1080 bluray = 1.77
auto-crop 132 off the top and bottom = 2.35 like the back of the blu-ray says.
http://i50.tinypic.com/17tmkn.png
Like so... am i pretty much doing the right thing if i was to use square pixels?

[blubb444]

Not wanting to sound arrogant or anything, but I can't think of a much easier way to explain it...
Anyway, if you're encoding with x264 to YV12 (4:2:0) colourspace then you don't need mod16; mod2 is enough in that case to give you more AR precision (it'll still be minimally off sometimes but you won't notice it unless you resize to say, a width of 100 or so). If you so wish to go to 720 width from the cropped 1920x816, then simply calculate (816/1920)*720=306, it's even 100% exact in that case.
If you're really so eager about minimum filesize, have a lot of time on your hands and don't care too much about lost details (it seems so if you resize anyway), you could use a strong denoiser like MCTemporalDenoise with "Very High" preset (for best results: after cropping but before resizing) and later on use a 10-bit x264 build at "placebo" and crf 20 or so.

[kkiller23]

(816/1920)*720=306

that actually made me understand it i think lmao

Before with all the AR and DAR etc i was getting confused, but now that you showed me on a source that i had. It makes sense.

So if i used the anamorphic encoding

816/1904*720 = 308
1904/816=2.33
720/304=2.36
2.33/2.36=0.987288(AR error)
Is that right?

[blubb444]

Where does your 1904 come from? Between 1920/816 (what it says in your screenshot) and 720/306 (which is perfectly fine with mod2) there is actually zero AR error

[kkiller23]

When i ticked the "anamorphic encoding" box in megui it changed it to 1904 for some reason so i just went with it.

[Keiyakusha]

- The Storage Aspect Ratio (SAR) just means the relation of the dimensions of the video, therefore in this case it is 720:576 = 5:4
- The Pixel Aspect Ratio (PAR) is how the single pixels must be shaped in order to get from the SAR to the desired DAR. The equation is DAR = SAR * PAR, which rearranges to PAR = DAR/SAR, in this case (15/11) : (5/4) = (15*4) : (11*5) = 60:55 = 12:11. In case of non-anamorphic video you have square pixels (1:1). Confusion arises because apparently sometimes this is called SAR instead ("sample aspect ratio") for example by x264.

PAR and SAR are synonyms. PAR older name, SAR newer. Storage Aspect Ratio is probably someone's imagination. Its Sample Aspect Ratio.

[blubb444]

When i ticked the "anamorphic encoding" box in megui it changed it to 1904 for some reason so i just went with it.

Hmm strange, I can see no mathematical reason right now why it would do that... maybe it somehow automatically looks for a value, when mod16 is checked, to keep the AR error as small as possible? That's the only idea I have, maybe you should ask the programmer(s) about it.

PAR and SAR are synonyms. PAR older name, SAR newer. Storage Aspect Ratio is probably someone's imagination. Its Sample Aspect Ratio.

Well, I've seen both and that inconsistency confuses me sometimes. But what would you name the relation of the video's dimensions (like 720:576=5:4) instead? In fact I've seen it refereed to as "Pixels aspect ratio", making things even more complicated...

[Keiyakusha]

But what would you name the relation of the video's dimensions (like 720:576=5:4) instead?
I won't name it at all. Aspect ratio is a modifier that applied to source video that have some resolution. We know this resolution 720:576, there is no reason to have ratio for it, this is ratio itself.

I also know MAR - movie aspect ratio. It seems GUI's, aspect ratio calculators or other software can't survive without its own aspect ratio abbreviation :D

[kkiller23]

# Set DAR in encoder to 47 : 20. The following line is for automatic signalling
global MeGUI_darx = 47
global MeGUI_dary = 20
http://i49.tinypic.com/wbsyo6.png
That's that megui auto puts into the avs script, so i guess i'd just do this in a resize calculator, correct?
http://i45.tinypic.com/zvsf2b.jpg

The only anamorphic encoding setting in megui is the "Clever (TM) anamorphic encoding"
Should i just stick with square encodes? as i'm really confused by anamorphic encoding.

[detmek]

If your players can play anamorphic video I would suggest to you to stick with anamorphic and "Encode non-mod16". x264 does not require mod16.
If you go with square pixels and upsize you won't gain quality compared to anamorphic but encoder will need more bitrate to preserve quality. So file size will be larger. On the other hand, if you downsize to maintain square pixels filesize will be lower as quality too (less pixels).

[sneaker_ger]

I suggested a higher resolution with square-pixels because his source is 1920x1080. I agree in regard to anamorphic SD sources (i.e. DVDs).

[kkiller23]

If i go with the "encode to non-mod16"

I will have to enter Spline36Resize(720,306) # Spline36 (Neutral)
into the scrip myself as the gui won't let me resize if i use non-mod16

So would i have to use -SAR 47:20 then in the encoder? or will the gui auto do it for me?

[detmek]

Wait! Your video seems to have a square pixels. Your 720x306 also gives you square pixels.Why do you bother with anamorphic encoding?
And 47:20 is DAR (47:20=2,35), not SAR. SAR would be 799:800. And yes, GUI will set SAR.

[kkiller23]

Because everyone was telling me to use it haha

I guess i'll stick with square then and mod16 then.

[hello_hello]

Hmm strange, I can see no mathematical reason right now why it would do that... maybe it somehow automatically looks for a value, when mod16 is checked, to keep the AR error as small as possible? That's the only idea I have, maybe you should ask the programmer(s) about it.

Probably to do with MeGUI's re-size to mod16 anamorphic option.

[hello_hello]

kkiller23,
There's probably no point in using anamorphic encoding unless you're encoding a DVD. Unfortunately MeGUI is still stuck in the world of mod16 when it comes to resizing using square pixels, so using the above formula makes it easy to get the resizing right, or if I'm particularly after a nice 16:9 or 4:3 aspect ratio, like you I use the resize calculator to work out the cropping for minimum distortion. One you have the desired dimensions you can type them into MeGUI's resize fields. If you change the script directly under the script tab, whenever you make any other changes, MeGUI re-writes the entire script so the changes you made will be lost. So changing the script needs to be the very last thing you do before saving it.

When it comes to anamorphic (DVD) encoding there's no reason to second guess what MeGUI is doing. MeGUI has a setting in it's options called "acceptable aspect error" which is 2% by default. It only applies to the "resize to mod16" anamorphic encoding option and allows MeGUI to give you a nice 4:3 or 16:9 aspect ratio etc without having to get the cropping completely accurate. I generally change the acceptable aspect error setting to 0%, which means the "resize to mod16" anamorphic option will behave exactly the same way as the other anamorphic options.... every time you crop a pixel, MeGUI will adjust the aspect ratio accordingly.
So basically when using anamorphic encoding for DVDs the only thing you really have to worry about when it comes to aspect ratio is which resize method to pick.... ITU or non-ITU. There's also another setting in MeGUI's options ("use ITU aspect ratio") to tell it which resize method to default to. I uncheck that option.

By the way.... the calculator does calculate the aspect ratio for you when using anamorphic encoding. For instance if you start off with a 1920x1080 video, the source aspect ratio is all that matters, which will be 1.77777. All the other stuff is irrelevant. Crop a couple of pixels from the bottom for example, and the source aspect ratio will change to 1.78107. It doesn't matter how you resize the video..... you wouldn't (the general idea behind anamorphic encoding is not to resize at all), but you could resize to 3000x400 dimensions if you wanted to, however the aspect ratio should still stay as 1.78107 for it to display correctly.
At the bottom of the calculator is the Matroska Aspect Ratio tag, which should pretty much agree with the aspect ratio being set by MeGUI when using anamorphic encoding.