--sar

[x265]

How to calculate --sar for BD encode(720p)?

[foxyshadis]

That's easy, Blu-ray PAR is always 1:1 except for 1440x1080 or SD, so the SAR is same as the DAR, width divided by height.

[x265]

resolution after crop - 1920x1036
x264 --sar 1920/1036 -- 1.853

will the sar change if i resize from 1920x1036 to 1334x720?

[Asmodian]

No...

[Sharc]

As the poster asked about the --sar for Blu-Ray, I thought that only following sets are legal for 2D blu-ray:

For DAR 16:9
1920x1080 => --sar 1:1
1440x1080 => --sar 4:3
1280x720 => --sar 1:1
720x576 => --sar 16:11
720x480 => --sar 40:33

For DAR 4:3
720x576 => --sar 12:11
720x480 => --sar 10:11

Anything else it not Blu-Ray compliant AFAIK.

[Asmodian]

Blu-Ray as a source not as a destination.

[Sharc]

Oh I see.
But even then the poster's original --sar is 1:1 for a 1920 wide blu-ray picture. Cropping does not change the --sar, means after cropping to 1920x1036 the --sar is still 1:1 (the movie aspect ratio is 1.85.... though), and after resizing to 1334x720 the --sar is still 1:1 (within rounding accuracy) but the resolution is no longer blu-ray compliant.
IMO it would be better to take the original 1920x1080 picture (i.e. including the black borders) and resize it to 1280x720. --sar remains 1:1 and the resolution is blu-ray compliant.

If however one wants to crop and resize to a free resolution the new_sar is calculated as:
new_sar = original_sar x (cropped_width x resized_height) / (cropped_height x resized_width).
Applied to the poster's example:
new_sar = 1.000 x (1920 x 720) / (1036 x 1334) = 1.000272065, (which is practically still 1:1).

[x265]

Thank you for the reply :)

[Asmodian]

Oh I see.
But even then the poster's original --sar is 1:1 for a 1920 wide blu-ray picture. Cropping does not change the --sar, means after cropping to 1920x1036 the --sar is still 1:1 (the movie aspect ratio is 1.85.... though), and after resizing to 1334x720 the --sar is still 1:1 (within rounding accuracy) but the resolution is no longer blu-ray compliant.
IMO it would be better to take the original 1920x1080 picture (i.e. including the black borders) and resize it to 1280x720. --sar remains 1:1 and the resolution is blu-ray compliant.

If however one wants to crop and resize to a free resolution the new_sar is calculated as:
new_sar = original_sar x (cropped_width x resized_height) / (cropped_height x resized_width).
Applied to the poster's example:
new_sar = 1.000 x (1920 x 720) / (1036 x 1334) = 1.000272065, (which is practically still 1:1).

Aren't you talking about PAR?

I guess we should define terms:

SAR × PAR = DAR

PAR = pixel aspect ratio
DAR = display aspect ratio
SAR = storage aspect ratio

Is this what everyone means? :p

[Sharc]

No, I am talking about --sar = sample aspect ratio as defined in the h.264 standard and used by the x264 encoder. It is in fact the same as the formerly used PAR = Pixel Aspect Ratio which has sometimes be mistaken as "Picture Aspect Ratio". (Maybe that's the reason why it has been changed to --sar).
Anyway, these 3-letter acronyms have lead to a lot of confusion and ongoing debates.

Edit:
I may add that the format is --sar a:b, means in the example above the "new_sar" then becomes
--sar 1382400:1382024, or
--sar 172800:172753

[Asmodian]

Ah yes, with x264 I tend to simply set --sar 1:1 with a bluray source. I don't think it is worth marking it anamorphic to correct such small aspect errors but there is no reason not to as far as I know.

I do like "pixel aspect ratio" as it is so specific (it is the aspect ratio of each pixel - independent of resolution), sample aspect ratio sounds less specific IMO (it might be resolution dependent?). Like you said, generates confusion and debates. ;)

To be honest I had forgotten x264 used --sar to set what I think of as PAR, I just remembered "you set PAR in x264". :o

[SeeMoreDigital]

Many years ago, with the help of Moitah, I conceived an application that's able to calculate the (non ITU spec) 'Aspect Ratio Signalling' value (aka: PAR, SAR and DAR) for any pixel resolution.

http://img233.imageshack.us/img233/9139/arscalculator9va.png

If anyone's interested, here you go: ARS Calculator (http://forum.doom9.org/attachment.php?attachmentid=5451&d=1139749825).

[hello_hello]

IMO it would be better to take the original 1920x1080 picture (i.e. including the black borders) and resize it to 1280x720. --sar remains 1:1 and the resolution is blu-ray compliant.

Them there's fightin' words.... I'm going to have to risk starting an argument. ;)

I've never met a Bluray/DVD player/media player which cares about the resolution when playing MKV/MP4 etc. Some don't support anamorphic, but that's another story.

If you crop you can create nice, sharp picture edges. Well I guess you could crop and add the borders back but the x264 encoder can blur a couple of rows of pixels top and bottom if there's borders. At least it could at some stage in the past. I've not encoded with borders myself in a long time. It might depend whether the video and/or borders are mod16. I'm not sure.

Not all displays are 16:9. Chances are, wider aspect ratio displays/TVs will become more common eventually. I'd prefer the video to fill as much of the screen as possible. If it's stuck at 16:9 it's more likely the player/TV will need to add extra borders to the sides..... or maybe wide-screen TVs will be sold with screen curtains.

I can't say I've tested how long it takes to run various filtering on the black bars, but I'd imagine a slow de-noising script would run faster at 1920x800 that it would at 1920x1080, even if the extra pixels are all black.

I'm not quite sure why creating Bluray compliant video is a better idea, especially as in order for it to be Bluray complaint you need to use Bluray complaint encoder settings which possibly result in larger file sizes or lower quality at a given bitrate.

[Sharc]

It's going off topic I am afraid, but anyway, my few cents:
I've never met a Bluray/DVD player/media player which cares about the resolution when playing MKV/MP4 etc.
My experience it just opposite: While you might be right with SW players regarding "free" resolutions (which have notably other issues btw), most HW standalone players are picky with non-standard formats (wrong aspect ratio, reject to play, etc.). I really don't like the idea of producing encodes and backups which may play with my current player, but may fail if I will change the player now or later.
Some don't support anamorphic, but that's another story
There you are. They just don't understand and follow pixel aspect ratios (PAR or --sar) but simply stretch the picture to 4:3 or 16:9 which leaves you with a distorted picture unless you have added the borders correctly!
If you crop you can create nice, sharp picture edges. Well I guess you could crop and add the borders back but the x264 encoder can blur a couple of rows of pixels top and bottom if there's borders.
Yes, but for blu-ray sources these borders are normally already nice and sharp. I agree that minimum blurring of few top and bottom pixel rows may occur unless you make everything mod16. But keep in mind that x264 will pad a non-mod16 picture to mod16 anyway.
For me this is no justification for producing non-standard encodes and taking the risk of playback issues, or fiddling with adjustments and guesses in order to get it "about right" during playback.
Not all displays are 16:9. Chances are, wider aspect ratio displays/TVs will become more common eventually. I'd prefer the video to fill as much of the screen as possible. If it's stuck at 16:9 it's more likely the player/TV will need to add extra borders to the sides..... or maybe wide-screen TVs will be sold with screen curtains.
May be, may not be. I personally don't want to base time-consuming encodes on speculations. Backward compatibility will probably be better supported for industry standards IMO.
I'm not quite sure why creating Bluray compliant video is a better idea, especially as in order for it to be Bluray complaint you need to use Bluray complaint encoder settings which possibly result in larger file sizes or lower quality at a given bitrate.
Well, I gave my arguments why I prefer to stick to industry standards. To each his own, however :)