PAR/DAR with MeGUI?

[Elias]

What happened with the PAR feature in XviD/x264 in MeGUI? I remember it being available in older versions of MeGUI but with the latest version it seems like gone with the wind.

[Irakli]

What happened with the PAR feature in XviD/x264 in MeGUI? I remember it being available in older versions of MeGUI but with the latest version it seems like gone with the wind.

It can be activated by choosing Clever (TM) anamorphic encoding in MeGUI's Avisynth Script Creator.

Regards,
Irakli

[Elias]

It can be activated by choosing Clever (TM) anamorphic encoding in MeGUI's Avisynth Script Creator.

Regards,
IrakliThanks for the tip. But why has this been removed from the codec configuration? I thought this was a codec specific feature, not avisynt script setting.

[Irakli]

Thanks for the tip. But why has this been removed from the codec configuration? I thought this was a codec specific feature, not avisynt script setting.

IIRC, it was mentioned on the forum that this feature was removed because new Clever (TM) Anamorphic Encoding is just much more flexible way to encode anamorphic (e.g. one can overcrop to mod16 or encoder non-mod 16, etc.). I personally don't know how this feature compares to an old one, since I've never used old MeGUI versions.

I think the fact that MeGUI offers the anamorphic encoding configuration through the Avisynth Script Creator is a good thing because the decision about encoding anamorphic/non-anamorphic is really made at this stage (e.g. if you're going to encode anamorphic then you are most likely not resizing, etc.). In any case, MeGUI will always pass an appropriate --sar (x264) or -par (xvid) command to the encoder.

Of course, PAR can be still changed via encoder configuration window by simply adding an appropriate custom command line options under 'Zones' tab.

Regards,
Irakli

[Elias]

Of course, PAR can be still changed via encoder configuration window by simply adding an appropriate custom command line options under 'Zones' tab.It would be nice if this custom cmd line option could be discussed here in this thread.

[Desmodeus]

On this note I would like to ask ...what DOES the --par command do?
I tried encoding with the --sar 4:3 and --par 6:5 strings attached to achieve a 16:10 anamorphic display, but instead I got a 2:1 DAR.
Anyone care to tell me what I'm doing wrong? :(

[yetanotherid]

I read the thread, thought I had the answer and then realised why I try not to think about this sort of thing. That's why I use a program like MeGUI, so I don't need to.

Desmodeus,
After trying a couple of test encodes using MeGUI and checking the log file, my assumption that SAR would be storage aspect ratio seemed to go out the window. It seems it's signal aspect ratio to the encoder and as far as I can tell it means the same thing as output pixel aspect ratio.

My test encodes were of a couple of AVIs as I didn't have any vob files handy. I just chopped off a different number of pixels each time and resized to mod16. If you want to specify the DVD pixel dimensions you'd have to know what they are.
In my case they were square pixels so it's easy to work out what went on. My original AVI was 704 x 288 and after chopping off 4 pixels and resizing down to 688 this is what was in the MeGUI log file:

--[NoImage] Job commandline: "C:\Program Files\MeGUI\tools\x264\x264.exe" --sar 175:172 --output "E:\Movie.mkv" "E:\Movie.avs"
--[Information] [3/01/2011 5:18:12 PM] Encoding started
--[NoImage] Standard output stream
--[NoImage] Standard error stream
---[NoImage] avs [info]: 688x288p 175:172 @ 10000000/417101 fps (cfr)
---[NoImage] x264 [info]: using SAR=175/172

It makes sense. I'd cropped the video to 700x288 and then used MeGUIs clever anamorphic encoding after resizing down to 688x288. If you work out the aspect ratio from the log 175:172 is 1.01744. That times 688 gives display dimensions of 700 x 288 which is what I started with, so SAR must be the same as the output PAR.
When cropping the 4 pixels MeGUI's script says it's setting the display aspect ratio to 175:72, which is the display aspect ratio of 700 x 288.

I cropped off 8 pixels and tried again. The encoder SAR was changed to 87:86 and the display aspect ratio in the script was 29:12.
Once again it works out.... 87:86 is 1.0116, times 688 is a width of 696. 696/288 = 29/12.

From all that I assume MeGUIs clever anamorphic encoding works out the math it needs to apply in order supply the encoder with the correct SAR to maintain display aspect ratio. The encoder wouldn't need anything else I assume, because once you've finished cropping and resizing the number of pixels is fixed, so SAR therefore sets the final DAR too.

I don't have time to think about it more and that's already making my head hurt a little. What the --par command does I don't know. Then again, I didn't know any of the above when I started typing so at least I've learned something.

[Sharktooth]

SAR is Sample Aspect Ratio that is the same as Pixel Aspect Ratio.

[Elias]

SAR is Sample Aspect Ratio that is the same as Pixel Aspect Ratio.I've had a long break from the codec world, it's been a while, but from what I can remember, DAR was better than SAR/PAR because it didn't change anything in the actual encoding settings and was only an instruction to the decoder to display it in proper aspect ration when played, and could easily be changed when changing container and so on, whereas PAR/SAR was a 'deeper' aspect ratio setting, like more hardcoded into the file.

Something like that anyway, correct me if I'm wrong.

[Sharktooth]

Aspect ratios may be stored in both the container and the stream. however what you say makes no sense at all coz even SAR doesnt change anything in the actual encoding settings.
different standards/encoders use different AR signaling options but still, if the decoder supports aspect ratio signaling it will decode the stream with the correct AR.
However a problem rises when the stream and the container have different values for the AR. In that case the decoder makes a choice...