MeGUI_darx, MeGUI_dary and SAR values

[Chris_Smith]

Hi Guys,

Can anyone please explain how MeGUI generates its MeGUI_darx, MeGUI_dary and SAR values. I have just done a search of the forum, and can't find any info on the calculation process.

I have a movie that is ITU 16:9 PAL Anamorphic (DAR 640:351, SAR 512:351). To remove the black bars, 12 pixels have to be cropped from the top and bottom, and 2 pixels have to be cropped from the right hand edge. This leaves a 718 x 552 frame size that is not encoder friendly. If I am correct, I have two choices, and can further crop to achieve mod(16) on height and width (704 x 544), or achieve mod(16) on height, and mod(4) on width. The former looks the more promising option, as it is closer to the original aspect ratio of the movie. When I input the above sizes into the MeGUI avs script creator with clever anamorphic ticked, it produces the following DARs:

a) 716 x 544 -> darx = 48, dary = 25, x264 encoder SAR = 3145:2156

b) 704 x 544 -> darx = 185, dary = 98, x264 encoder SAR = 6528:4475

Possible solutions are:

For case a: DAR = (512/351) x (716/544) = 1.919893

For case b: DAR = (512/351) x (704/544) = 1.887716

My two calculated DARs are very close to the machine generated ones, by how are the SARs generated?

I hate inscrutable black boxes, and would appreciate any help on the matter.

[nm]

I have a movie that is ITU 16:9 PAL Anamorphic (DAR 640:351, SAR 512:351). To remove the black bars, 12 pixels have to be cropped from the top and bottom, and 2 pixels have to be cropped from the right hand edge. This leaves a 718 x 552 frame size that is not encoder friendly.

It's fine for x264 -- no need to crop further or do anything else unless you have a hardware player that doesn't like the frame size for some obscure reason.

Can't MeGUI be set to use the source SAR?

[hello_hello]

Non-mod16 encoding is fine. I've not yet come across any playback problems with non-mod16 video.

The DAR of the encode and the original movie DAR don't have to be the same.... well it's not something I fuss about. In fact if you crop, they generally can't have the same DAR. You're not thinking of the shape of objects in the video and the DAR as being one and the same are you? As you crop, MeGUI will recalculate the DAR so as not to distort the picture.

If it helps, you don't actually have to think about it. MeGUI has an "acceptable aspect error" option which applies to anamorphic encoding. It's set to 2% by default (makes it easier to achieve nice 16:9 or 4:3 aspect ratios if you want to) but you can change it to 0%. I usually do.
Then just let MeGUI do the thinking. The resulting encode shouldn't distort the picture regardless of how you crop.

I have no idea how MeGUI physically generates the DAR, only that it does.

Are you sure your DVD uses the ITU resizing method? MeGUI defaults to the ITU resize method and unfortunately there's no way to tell it not to, but most DVDs don't use the ITU resize method..... just straight 16:9 (or 4:3) resizing.
I always use the straight resizing method. 99% of the time it's the correct one.

[Chris_Smith]

I did find some info on Avisynth functions that calculate the DAR and SAR. When cropping, the SAR does not change so it remains at 512/351. The PAR is changed with cropping, and hence the DAR changes by virtue of DAR=PARxSAR. I will post a URL, and some calculation that I did on another DVD, that had 160 pixels cropped from its height which changed its DAR from 2.39 to an insane 2.523.

[hello_hello]

I will post a URL, and some calculation that I did on another DVD, that had 160 pixels cropped from its height which changed its DAR from 2.39 to an insane 2.523.

Well unless my math is bad, it sounds about right to me. By my calculations for a PAL DVD, assuming 720x416 after cropping....

ITU resizing:
(720/416)x(118/81)=2.521

Non-ITU resizing:
(720/416)x(16/11)=2.517

[hello_hello]

The PAR is changed with cropping, and hence the DAR changes by virtue of DAR=PARxSAR.

I think you've got that a little backwards. The whole point of anamorphic encoding is not to change the PAR. The only time the PAR should be changed when using anamorphic encoding with MeGUI, is if you select the "resize to mod-16" method, otherwise it should remain the same as the source.

When you crop, you're changing the storage aspect ratio (width/height in pixels), so by virtue of DAR=PARxSAR, if the PAR is a constant, the DAR must change when the SAR changes.

PS. What happens if you open the original DVD in a media player, then open the encode in a media player to compare them? Do objects in the video look stretched/distorted in any way, or do they look the same?
(If you're using the ITU resize method when encoding, the encode will probably look a little horizontally stretched when compared to the original DVD, as most software players use the non-ITU resize method for playback)

[nm]

I think you've got that a little backwards. The whole point of anamorphic encoding is not to change the PAR. The only time the PAR should be changed when using anamorphic encoding with MeGUI, is if you select the "resize to mod-16" method, otherwise it should remain the same as the source.

When you crop, you're changing the storage aspect ratio (width/height in pixels), so by virtue of DAR=PARxSAR, if the PAR is a constant, the DAR must change when the SAR changes.

You are both talking about the same thing with different acronyms. Chris uses terms SAR = sample aspect ratio and PAR = picture aspect ratio, and you use SAR = storage aspect ratio (which is the same thing as picture aspect ratio) and PAR = pixel aspect ratio (which is the same thing as sample aspect ratio).

[hello_hello]

You could be right about that, although I'm not sure.....

Just for the record then, when it comes to the DAR=PARxSAR equation, we should be referring to Display aspect ratio, Pixel aspect ratio and Storage aspect ratio.

[nm]

Just for the record then, when it comes to the DAR=PARxSAR equation, we should be referring to Display aspect ratio, Pixel aspect ratio and Storage aspect ratio.

Well, the same equation works with PAR="picture aspect ratio" and SAR="sample aspect ratio" and those are the terms I've seen used more often -- at least since MPEG specifications started to use SAR for sample aspect ratio.

Personally I'm fine with "pixel aspect ratio" and "storage aspect ratio" too, but people should define the acronyms before using them. Undefined acronyms are a common source of confusion when talking about aspect ratios.

[hello_hello]

I don't think I've ever seen PAR used to describe the picture aspect ratio.

[nm]

I don't think I've ever seen PAR used to describe the picture aspect ratio.

Yep, I guess usually people just talk about frame width and height when SAR is reserved for sample aspect ratio.

"Frame aspect ratio" or "image aspect ratio" could also be used. Most of these terms may be confused with DAR if the meaning is not defined. "Picture aspect ratio" usually does mean DAR.

[hello_hello]

Well, the same equation works with PAR="picture aspect ratio" and SAR="sample aspect ratio" and those are the terms I've seen used more often

Actually thinking about it, it doesn't.
Picture Aspect ratio x Sample aspect ratio = ?
How do you put Picture aspect ratio and Display aspect ratio in the same equation if they mean the same thing?

"and you use SAR = storage aspect ratio (which is the same thing as picture aspect ratio)"

"Picture aspect ratio" usually does mean DAR"

I think you're confusing the issue unnecessarily.

I still think we're both probably referring to the equation the same way....
Display Aspect Ratio = Pixel Aspect Ratio x Storage Aspect Ratio.
It's really the only way the "DAR=PARxSAR" equation works.

[nm]

Actually thinking about it, it doesn't.
Picture Aspect ratio x Sample aspect ratio = ?
How do you put Picture aspect ratio and Display aspect ratio in the same equation if they mean the same thing?

MeGUI and Chris_Smith use SAR for "Sample AR". MeGUI doesn't say anything about PAR, but Chris clearly used the acronym to mean width/height of the source frame. That isn't the common meaning of "Picture AR", but I had no problem understanding what he meant.

I think you're confusing the issue unnecessarily.

I'm just trying to explain that you use different terms to say the same thing.

I still think we're both probably referring to the equation the same way....
Display Aspect Ratio = Pixel Aspect Ratio x Storage Aspect Ratio.
It's really the only way the "DAR=PARxSAR" equation works.

Unless you define PAR to mean frame_width/frame_height and SAR to mean "Sample AR".

[J_Darnley]

Stop with the fucking three-letter acronyms!

[Chris_Smith]

Ok guys, lets not get bent out of shape over this. Just to clarify I used DAR = Display Aspect Ratio, PAR = Pixel Aspect Ratio and SAR = Storage Aspect Ratio.

I have a link to an article on Aspect ratio signalling that might give us a clue as to what is going on inside MeGUI.

Check out: http://mewiki.project357.com/wiki/MeGUI/Aspect_Ratio_Signalling_in_AviSynth_Scripts

This was written by someone who presumably knows what they are talking about, and if you look at the paragraph entitled "An example of using these functions in a script:", you will see that SAR is preserved when cropping. I shall do some tests on a movie that requires heavy cropping, and see how it displays circular images.

In response to Hello_Hello's question regarding ITU resizing, I have checked using ffmpeg and mediainfo, and they report that the original VOBs display aspect ratio is 16:9. However when the avs file is "played" with the DGDecode.dll info parameter set to info=1, the resulting information that is overlayed on the movie shows that the colorimetry is "ITU-R BT.470-2 System B, G (5)".

I did a quick MeGUI encode using 16:9, and found that circles weren't perfectly round, so it looks as if MeGUI is identifying the movie correctly.

[hello_hello]

I've no idea why J_Darnley got bent out of shape while we were having a simple discussion..... some people are odd....

Well it seems nm, was correct and I was not, and we were in fact referring to the same thing in different ways.

Edit:
Just to clarify I used DAR = Display Aspect Ratio, PAR = Pixel Aspect Ratio and SAR = Storage Aspect Ratio.

Actually no..... now that I think about it, we weren't referring to the same thing, so I think I was correct after-all. Now I'm confused too.....
But just to clarify further......
You realise the use of SAR in the link you supplied refers to "sample aspect ratio" and not "storage aspect ratio"?
Sample aspect ratio being the same thing as pixel aspect ratio?

Anyway.....


This was written by someone who presumably knows what they are talking about, and if you look at the paragraph entitled "An example of using these functions in a script:", you will see that SAR is preserved when cropping.

Which is actually what I said back in post #6, only I referred to it as pixel aspect ratio, not sample aspect ratio.
Sample aspect ratio, or pixel aspect ratio, whichever way you want to refer to it, isn't changed by cropping. Simply cropping off some pixels doesn't change their shape.
Cropping changes the storage aspect ratio (width/height) and as a result the display aspect ratio must also change accordingly.
The only MeGUI anamorphic encoding option which can also change the pixel (sample) aspect ratio is the "resize to mod 16" option. The rest purely crop, so they don't change the pixel (sample) aspect ratio.

In response to Hello_Hello's question regarding ITU resizing, I have checked using ffmpeg and mediainfo, and they report that the original VOBs display aspect ratio is 16:9. However when the avs file is "played" with the DGIndex info parameter set to info=1, the resulting information that is overlayed on the movie shows that the colorimetry is "ITU-R BT.470-2 System B, G (5).

There's no way to tell from that which resizing method was used.
Yes, DGIndex is telling you which ITU colorimetry was used, but it has no bearing on the resizing.
I'm pretty sure MediaInfo will always display the original vob resizing method as being 16:9. The fact that "straight 16:9" resizing gives you 16:9, while "ITU 16:9" resizing doesn't give you exactly 16:9 won't change what's reported by MedaInfo. There's no way to tell which resizing method is the "correct one", short of comparing them visually.

I did a quick encode at 16:9, and found that circles weren't perfectly round.

So ITU 16:9 resizing did produce round circles?
If so, you've obviously used one of the minority of DVDs for testing which does use the ITU resizing method. They do exist. Just don't count on it be the norm.

I shall do some tests on a movie that requires heavy cropping, and see how it displays circular images.

Maybe run a test encode without cropping first, after deciding which resizing method you think is correct, so you've got a "control" encode to use for comparison (keep in mind if you use the x264 Bluray target device option, it can enforce ITU resizing regardless of what's in the script, but that's a whole other story).
Make sure MeGUI's "acceptable aspect error" option is set to 0%.
Then crop away, let MeGUI set the aspect ratio (display aspect ratio) and run a second test encode. If there's a difference between the shape of objects in the second encode when compared to the first, I'll be absolutely astounded.

[sneaker_ger]

One misunderstanding comes from "SAR" and "SAR" not being the same. The one used in DAR=PARxSAR is defined differently ("Storage Aspect Ratio")as the one defined by H.264 ("Sample Aspect Ratio", i.e. x264cli's "--SAR x:y"). The one described in H.264 is actually the same as the "Pixel Aspect Ratio".

[nm]

One misunderstanding comes from "Storage Aspect Ratio" and "Storage Aspect Ratio" not being the same. The one used in DAR=PARxSAR is defined differently as the one defined by H.264 (i.e. x264cli's "--SAR x:y").

SAR in H.264 is "sample aspect ratio".

[sneaker_ger]

Embarrassing, apologies to J_Darnley. Corrected now. I guess my mistake shows just how confusing it can get sometimes...

[Chris_Smith]

Just downloaded MeGUI v2050 and tried it with a few DVDs, and it seems to always identify them as being ITU 16:9 or ITU 4:3. I also tried DVDDecryptor, and it identifies them as non-ITU DVDs. So I guess that MeGUI needs to be manually set to get the correct aspect ratio.

I did two test encodes on a 1 minute DVD clip that had some circular objects (no cropping 720x576) using PAL ITU 16:9 and PAL 16:9 settings, and found that visually there was not much difference between them. I even placed a piece of paper on the screen, and marked the lengths of the vertical and horizontal axes of the objects, but the difference between 512/351 and 64/45 is less than 3%, so it is not easy to tell which is the correct value.

[hello_hello]

Yeah MeGUI just defaults to ITU resizing so you have to change it manually. Aside from visually looking at the video I don't think there's any way to tell which resizing method to use.

My method..... if I really, really want to be sure.
I play the original DVD using MPC-HC, try to find a front-on shot of a round object, and save it as an image (it saves using the storage aspect ratio, not the display aspect ratio). Then I open the image using Irfanview (twice), resize it using each method, and then use the paint plugin to draw a circle over the round object. Whichever is closest to being actually round, that's the resize method I use.

I almost forgot how this thread started..... did you end up deciding MeGUI calculates the display aspect ratio correctly when cropping and encoding anamorphically?

[Chris_Smith]

Haven't found out yet how MeGUI calculates the display aspect ratio when cropping, but it seems to be within a fraction of a percent of my calculated values. At the moment I can only assume that the difference is due to it generating the closest fractional value from a decimal number.

In some of the movies that I have there are no reliable geometric objects to use as a reference, and in one, a lot of scenes are shot in the dark with rain and smoke, so under those conditions it is impossible to tell the difference between 16:9 or 640:351.

[Chris_Smith]

Just as a matter of interest, it one discovered that the movie was 16:9 and it had been encoded 640:351, would it be possible to convert it to 16:9 without degradation, or would it have to be re-encoded?

[nm]

Just as a matter of interest, it one discovered that the movie was 16:9 and it had been encoded 640:351, would it be possible to convert it to 16:9 without degradation, or would it have to be re-encoded?

You can change the sample aspect ratio information stored within the H.264 elementary stream by using roozhou's patched ffmpeg (http://forum.doom9.org/showthread.php?t=152419). This is a lossless process.

If you have problems with FFmpeg's demuxers or muxers:
1. Demux the video and audio streams with an appropriate external tool (for example MP4Box or mkvextract).
2. Change sample aspect ratio within the H.264 stream.
3. Mux the new H.264 stream and audio streams with external tools.

[Chris_Smith]

Thanks nm, I will have a look at that.