Need help with first anamorphic encode via MeGUI

[jellysandwich]

This is what I did:

1)AVS script creator -> select d2v file (ITU 16:9 1.823 NTSC)
2)Clever(TM) anamorphic encoding -> Overcrop
3)Autocrop
4)On Save close and load to be encoded
5)Save
6)Encode

Resulting avs file:
# Set DAR in encoder to 37 : 20. The following line is for automatic signalling
global MeGUI_darx = 37
global MeGUI_dary = 20
DGDecode_mpeg2source("D:\Dvd\SuperTroopers\SuperTroopers.d2v",info=3)
ColorMatrix(hints=true)
#blank deinterlace line
crop( 6, 6, -2, -10)

LanczosResize(720,464) # Lanczos (Sharp)
#denoise
trim(0,1000) #test


When I playback the file, it doesn't resize properly; it just plays as 704*464. I searched the forums, and all of the anamorphic threads mention something about setting the AR in the codec configuration menu. I tried looked through the config menu but couldn't find such an option... Was it taken out? I remember seeing the option there a few months ago...

Anyway, what am I doing wrong?

js

[nurbs]

If you use ffdshow for playback you have to check "use overlay Mixer" in the options. Mayby "allow output format changes" too, but I'm not sure about that.
You can also try if VLC plays the file correctly.

[jellysandwich]

Nope. I played around with the ffdshow options, but it didn't work. VLC didn't work either...

js

[berrinam]

What did you encode to, what codec, can you post your log, also try MPC if you haven't already.

[jellysandwich]

What did you encode to, what codec, can you post your log, also try MPC if you haven't already.

I use MPC 6.4.8.9 with ffdshow r2546(6/4/06) by default. I used x264 to encode it, and this is the log from MeGUI:

Starting job job25-1 at 7:40:06 PM
encoder commandline:
--pass 1 --bitrate 1000 --stats "D:\Dvd\SuperTroopers\sttest.stats" --bframes 3 --b-pyramid --direct auto --subme 1 --analyse none --me dia --progress --no-psnr --output NUL "D:\Dvd\SuperTroopers\sttest.avs"
successfully started encoding
Processing ended at 7:41:30 PM
----------------------------------------------------------------------------------------------------------

Log for job job25-1

avis [info]: 704x464 @ 23.98 fps (1001 frames)
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2 3DNow!
x264 [info]: slice I:14 Avg QP:27.14 size: 18070
x264 [info]: slice P:468 Avg QP:29.39 size: 7170
x264 [info]: slice B:519 Avg QP:31.04 size: 2927
x264 [info]: mb I I16..4: 37.0% 0.0% 63.0%
x264 [info]: mb P I16..4: 22.7% 0.0% 0.0% P16..4: 49.5% 0.0% 0.0% 0.0% 0.0% skip:27.9%
x264 [info]: mb B I16..4: 2.5% 0.0% 0.0% B16..8: 33.3% 0.0% 0.0% direct: 8.5% skip:55.7%
x264 [info]: final ratefactor: 27.47
x264 [info]: direct mvs spatial:99.8% temporal:0.2%
x264 [info]: kb/s:982.5

encoded 1001 frames, 12.28 fps, 982.67 kb/s

----------------------------------------------------------------------------------------------------------
Job completed successfully and deletion of intermediate files is activated
job job25-1 has been processed. This job is linked to the next job: job25-2
Starting job job25-2 at 7:41:30 PM
encoder commandline:
--pass 2 --bitrate 1000 --stats "D:\Dvd\SuperTroopers\sttest.stats" --ref 5 --mixed-refs --bframes 3 --b-pyramid --b-rdo --bime --weightb --direct auto --subme 6 --trellis 1 --analyse all --8x8dct --me umh --progress --no-psnr --output "D:\Dvd\SuperTroopers\sttest.mp4" "D:\Dvd\SuperTroopers\sttest.avs"
successfully started encoding
Processing ended at 7:45:05 PM
----------------------------------------------------------------------------------------------------------

Log for job job25-2

avis [info]: 704x464 @ 23.98 fps (1001 frames)
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2 3DNow!
mp4 [info]: initial delay 2002 (scale 24000)
x264 [info]: slice I:14 Avg QP:25.50 size: 18931
x264 [info]: slice P:468 Avg QP:28.38 size: 7109
x264 [info]: slice B:519 Avg QP:29.86 size: 3153
x264 [info]: mb I I16..4: 23.5% 63.5% 13.0%
x264 [info]: mb P I16..4: 11.4% 19.5% 1.9% P16..4: 32.5% 10.5% 2.0% 0.1% 0.0% skip:22.1%
x264 [info]: mb B I16..4: 1.0% 2.8% 0.4% B16..8: 36.1% 2.1% 3.6% direct: 1.7% skip:52.3%
x264 [info]: 8x8 transform intra:60.5% inter:71.6%
x264 [info]: direct mvs spatial:99.6% temporal:0.4%
x264 [info]: ref P 75.8% 12.1% 6.0% 3.2% 2.9%
x264 [info]: ref B 83.6% 9.3% 3.6% 2.1% 1.5%
x264 [info]: kb/s:1001.8

encoded 1001 frames, 4.67 fps, 1002.05 kb/s
desired video bitrate of this job: 1000 kbit/s - obtained video bitrate (approximate): 6 kbit/s
----------------------------------------------------------------------------------------------------------
Job completed successfully and deletion of intermediate files is activated
Found intermediate output file 'D:\Dvd\SuperTroopers\sttest.stats', deleting...
Deletion succeeded.

This (http://amnah.net/uploader/files/1/videos/sttest.mp4) is the resulting file. Can you guys check if it plays properly for you?

js

[berrinam]

Your commandline does not have a single --sar x:y switch in it, so it obviously isn't being signalled. I copied your instructions exactly as you wrote them, nothing extra, and it generates a perfect encode and commandline for me.

The option to configure DAR manually is available in the video preview window, which opens automatically when a video is loaded, and you can also open manually be double-clicking the video input field on the main window.

Other than that, make sure you are running the latest version of MeGUI (0.2.3.2165 at the moment).

[jellysandwich]

Ahha! After some testing, I figured out the problem. It seems that MeGUI does not signal the correct DAR unless the video preview window opens, either through the "Open Preview after Avisynth script selection" option or double-clicking the video input field. (I typically don't open the preview window because I use GKnot/Vdub to create my scripts.)

Thanks for the help.

js

[lazyn00b]

If you want your circles to actually look like circles instead of ovals, use --sar 32:27 for SAR/PAR. On almost every movie I've seen, the ITU's so called "standard" is wrong.

[jellysandwich]

If you want your circles to actually look like circles instead of ovals, use --sar 32:27 for SAR/PAR. On almost every movie I've seen, the ITU's so called "standard" is wrong.

Maybe too advanced for me right now... 2 more questions:

1) Is there any point in doing anamorphic encodes for 4:3 content, specifically anime? Typically, I resize anime to 640*480. With anamorphic encodes however, I wouldn't resize after cropping it to less than xxx*480... Or maybe I should resize?

2) I've noticed that MeGUI/x264 allows one to encode to non-mod16. Is this a bad idea to do? If so, why?

js

[check]

All (normal) video codecs encode information in blocks of 16, so if the video is not in multiples of 16, it will just add extra data onto the edges and not display it if I recall correctly.

[berrinam]

check is right. Just to clarify, this extra data will also mean a slight loss in compressibility or quality. However, it's probably the best option, because it means you can avoid resizing, which might (keep in mind that I haven't got any evidence to back up what I say) lower the quality even more.

Regarding whether or not to do anamorphic encodes:
aside from practical/implementation issues (ie, not supported on stand-alones, your processor can't support the resolution, etc), the answer is pretty much always yes. Theoretically, doing an anamorphic encode means you can encode at the optimal resolution (determined by your bitrate and compressibility, etc), yet guarantee the correct video shape. It also has the benefit that you should never have to encode unnecessary pixels (by, eg, upsizing before encoding)

However, sometimes, if you are lucky, you will start off with square pixels, in which case encoding anamorphically will give you the same results as non-anamorphic, in which case it doesn't matter what you do.

[Coren]

I too have recently discovered the joys of anamorphic encodes.
There's one thing I don't quite get, though.

First, I'm encoding an interlaced 16:9 PAL DVD.
I've used MeGUI's Smart Anamorphic feature with overcrop to mod16 and the AVS ends up looking like much like jellysandwish's:

# Set DAR in encoder to 37 : 20. The following line is for automatic signalling
global MeGUI_darx = 37
global MeGUI_dary = 20
DGDecode_mpeg2source("C:\MovieGear\SFU4\06.d2v")
edeintted = last.AssumeTFF().SeparateFields().SelectEven().EEDI2(field=-1)
TDeint(order=1,edeint=edeintted)
crop( 8, 8, -8, -8)

I Save and Load, fire up an automated 2pass using the x264 HQ-Slow profile and everything seems to encode just fine.

The one thing I'm wondering about is:
do I need to enter a specific AR or Resolution when muxing my files in MKVmerge?
I tried selecting 16/9, but it scales up my video to 1000+ x something on playback (correct AR, just very large). Is this normal? I've tried entering 853 x 480 as display width/height in MKVmerge but there too the video is scaled up to 994 x 560.

Can somebody explain why this happens and if it's normal?

Also, if you see any flaws in my way of encoding the video, feel free to give your opinion, I've pretty much only learned this through trial and error.

Coren

[lazyn00b]

Maybe too advanced for me right now... 2 more questions:

1) Is there any point in doing anamorphic encodes for 4:3 content, specifically anime? Typically, I resize anime to 640*480. With anamorphic encodes however, I wouldn't resize after cropping it to less than xxx*480... Or maybe I should resize?

2) I've noticed that MeGUI/x264 allows one to encode to non-mod16. Is this a bad idea to do? If so, why?

js

1) Sure, I try to avoid resizing of any kind before encoding, because it invariably causes some loss of quality, even if very slight. If you search the forums, I'm pretty sure I remember SeeMoreDigital posting the correct PAR ratio for 4:3 content.

2) Somebody asked this recently, and the consensus seemed to be that it wasn't a big deal. This issue came up for me recently when I wanted to encode some 1920x1080p content and MeGUI complained. So I tried encoding with 1080p and also with 1088p (using Avisynth to add the extra 8 lines), and I swear I couldn't tell the difference.

[jellysandwich]

Theoretically, doing an anamorphic encode means you can encode at the optimal resolution (determined by your bitrate and compressibility, etc), yet guarantee the correct video shape. It also has the benefit that you should never have to encode unnecessary pixels (by, eg, upsizing before encoding)

Hmm. I think I'm a little confused on exactly what anamorphic encoding is. I thought that it simply takes a video and expands it horizontally during playback. If that's the case, then how do you explain the optimal resolution?

js

[berrinam]

Anamorphic encoding means any form of encoding where the final shape of the video is determined by the signalled AR as opposed to the resolution. That means you can have any resolution and it will still look right when you play it back.

What I was saying about optimal resolution is that since it is guaranteed to play back fine at any resolution, this gives you a lot of freedom in the resolution you can choose. The optimal resolution is simply the resolution which will give you the best quality at a given combination of settings. It's not a strictly-defined thing, but lower-bitrate encodes will presumably look better on low resolutions and vice versa, so anamorphic encoding will allow you to make whatever resolution adjustments you need without being worried about the final shape.

[jellysandwich]

Just to make sure, anamorphic only resizes horizontally right? I'm a little confused because I thought the point of anamorphic encoding was to not resize. If that's so, then wouldn't reducing the resolution (=resize down) go against that?

js

[berrinam]

Just to make sure, anamorphic only resizes horizontally right?Anamorphic only specifies the ratio. The actual sizes will be scaled according to the dimensions of the display, which means the in most cases, the video will end up being resized both horizontally and vertically.

I'm a little confused because I thought the point of anamorphic encoding was to not resize. If that's so, then wouldn't reducing the resolution (=resize down) go against that?Anamorphic encoding is fundamentally for guaranteeing the correct video shape. However, while most people use anamorphic encoding to avoid resizing, when the bitrate gets VERY low, the artifacts introduced by resizing will be overcome by compression artifacts, and you will most likely end up with an overall better quality by sacrificing resolution for easier compresion. I was just using this example to show what 'optimum' resolution *could* mean. However, in most cases, 'optimum' means identical to the original.

[foxyshadis]

Unless you use IIP (or your favorite total reprocessing solution). :D Then optimum is whatever res and aspect ratio you decide to encode at, but you'll presumably be throwing so much bitrate at it that it won't matter. [/ot, sorry]

That's why bpp was there as a guide for a long time, to put some science into picking a resolution, even if it broke down as codec quality improved. The other option is applying a stronger filtering, but not so strong to ruin it, so that the video becomes much more compressible. At best doing that isn't much better than just resizing down, and often a bit worse, though.