Strange --sar problem

[Logan9778]

Hey guys. Ran into a new problem I can't figure out.

https://picload.org/image/rlldlocw/arproblem.jpg

I ran my Avisynth script ( on the bottom of the pic ) through Simple X264, once with --sar 12:11 and once with --sar 16:15, trying to figure out if it was ITU standard or not.

Both show that they are 720x576, but have different ARs. The one with 4:3 DAR, expands to 768x576 in Zoom Player. The 12:11 one expands to 785x576 in Zoom Player.

And of course, you can see MPC showing 4:3 and 785:586 ARs.

Am I right in guessing 16:15 would be the correct --sar to pic?

As you can see in Avisynth, I cropped out bad edges (after de-interlacing) and then added back in back borders as filler to get back to 720x576.

Hmm. -NDJamena - "or with ITU padding, 704 pixels in storage, 768 pixels on display." Does this mean the pixels aren't really there and the player is supposed to fill them in?

Also, could I ask you guys, Sharc mentioned resizing to quadratic pixels ( square pixels?) to keep down player resize / flags errors. Would I just put Spline36resize(768,576) into the avisynth script to resize while keeping aspect ratio correct?

[ndjamena]

If you think your video is ITU, you should remove the 8 pixels from each side AND NOT PUT THEM BACK, keep it at 704x576... According to ITU specs the extra 16 pixels should simply be discarded on playback, since your files will most likely be displayed through non-ITU compliant equipment keeping those pixels is just a waste of bitrate and will cause unnecessary black bars on playback.

To be honest, I would never add any of the black borders back. From my experience players that ignore aspect ratio tend to fill the entire screen with whatever they're given, since you're processing 4:3 content and are most likely to play it on a 19:6 screen that means you'll have to fiddle with ZOOM every time you switch between old 4:3 and new 16:9 content. It would be better to just get a new player if you're stuck in that kind of situation, but that's up to you.

The DVD specs actually contain the option for 704x576 native encoding, it's just the people that author the DVDs don't use it when they probably should. The whole ITU on DVD issue is a mess that will never be cleared up until DVD is history.

-edit-

Also, I'd add AssumeFPS(25) to the end of your script. FFVideoSource is terrible for maintaining MKV frame rates, it would be better to extract the video track to an m2v and use MPEG2Source on it or use DGSourceNV or DGSourceIM on the MKV instead.

[Logan9778]

Thanks. I'm beginning to think this DVD is an UnHOLY mess. The circles in the TARDIS only look completely circular when I am viewing the video in AvsPmod, and that is at STORAGE Aspect! When it stretches to 768 horizontal, the circles look more eliptical.

I think you can kind of see that in the circles at the far right of the screen.

I don't understand what is going on with the --sar and X264, or why its stretching to 785 at 12:11

I will try again with 704x572, 12:11 and no black bars added, as you suggest.

Should I resize it to square circles as sharc suggested? And how would I do that and keep the aspect ratio?

Yeah, I've seen some weird frame rates showing on MPC, like it couldn't keep it right.

[ndjamena]

(720/11)*12 = 785.45454545454545454545454545455
(704/11)*12 = 768

It's because you left the ITU padding in. The actual active picture is 786 wide, but since you've left the padding in that takes up an extra 17 pixels. If you remove the ITU padding, leave the video at 704x576 and set the SAR to 12:11 you'll wind up with an output exactly 768 pixels wide.

You can resize to square pixels if you like, it's generally what I do. The problem with that is that like any other filter, resizing filters destroy detail by blending pixels leaving the output of lower quality than if you just left it the size it was. It depends on if you care about that or not. While I was fixing Doctor Who it became apparent that the necessary cropping would change from scene to scene and there was no one set of cropping parameters that would suit any particular episode without overcropping most of the scenes. Cropping per scene though would leave each of the scenes with different frame sizes, so it became necessary to resize all of the scenes to uniform dimensions in order to append them to a single video clip.

But that's just me, there's no correct answer on how to deal with all of this.

Keeping aspect ratio...

The easiest way for ITU would be to crop the 16 pixels off, then for every 1 pixel you crop from the vertical plane, crop 1.222222_ pixels from the horizontal, then resize whatever is left to 768x576.

for Non-ITU it's 1.25 horizontal pixels for each vertical pixel or 5 horizontal pixels for every 4 vertical.

Otherwise you can just... well...

Spline36Resize((2 * ceil((float(width)/11.0)*12.0)/2.0)), height)

[Logan9778]

Thanks! That makes it a little clearer. AvsPmod won't let me stick in Crop(10.44, 2, -10.44, -2) though. It just gives me an invalid argument error. Then after it, I would add Spline36resize(768,576), right?

[hello_hello]

I'm with ndjamena, I just resize to square pixels, and for interlaced PAL it's a similar idea to 1080i vs 720p. You can resize 1080i down to 720p and any loss of detail would usually require bionic eyes to see, because the extra resolution is temporal, so if the the source is interlaced you should give FPSDivisor=2 the flick and encode at 50fps, then you could probably resize down to 640x480 and you'd have to pause the encode and compare identical frames to see any difference between 640x480 and 720x576. When the pictures are moving you won't. In fact EzDenoise=2 probably steals a little detail anyway so resizing down will probably make very little difference. I'm not saying you shouldn't use EzDenoise, only that like all noise removal it potentially removes some fine detail.

BBC, 4:3 video source ..... I'd say it's very likely to be ITU, so without cropping you'd resize to 656x480. If you crop the sides and a little top and bottom you might have to fiddle with the cropping for exactly 4:3. According to the Yoda Resize Calculator (https://www.videohelp.com/software/Yodas-Resize-Calculator) if you crop 4 pixels from the height you need to crop a total of 22 from the width if you want exactly 4:3.

Or of you want to resize to square pixels, give this script a spin. CropResize (https://forum.videohelp.com/threads/382601-CropResize-Script)

For your source (I use mpeg4 SARs/PARs these days, because there's only two display aspect ratios and they're easy to remember), try this:

CropResize(640,480, CThresh = 100, InDAR = 15.0/11.0) # the default cropping threshold is 30 but it usually needs a boost for video sources). Or 768x576 etc if you prefer

Here's a list of PARs (SARs). The mpeg4 PARs translate to a display aspect ratio of 15/11 (4:3) and 20/11 (16:9) for both PAL and NTSC (before cropping obviously) http://forum.doom9.org/showthread.php?p=1058927#post1058927

[hello_hello]

Thanks! That makes it a little clearer. AvsPmod won't let me stick in Crop(10.44, 2, -10.44, -2) though. It just gives me an invalid argument error. Then after it, I would add Spline36resize(768,576), right?

Crop has to be multiples of 2 for YV12.
The resizers can also crop, and they can crop mod1, so for example if you wanted to crop 11 pixels from left and right, and two top and bottom, you can do the "even" cropping with Crop() and the rest with the Resizer.

Crop(10, 2, -10, -2)
Spline36Resize(640, 480, 1, 0, -1, 0)

When resizing to square pixels it's often not easy to crop and resize for a zero aspect error, because the resizing has to be whole pixel dimensions. If you use a calculator you can keep it very low (I aim for less than 0.1%) and it's no big deal because the same sort of thing happens when upscaling on playback. It has to be resized/upscaled to whole pixel dimensions.

If you open an anamorphic MKV with MPC-HC and use the File/Properties menu, it'll often display two aspect ratios. The aspect ratio next to the video stream will be the stored aspect ratio, and the aspect ratio next to "video size" is the aspect ratio after resizing to whole pixels. If there's no aspect ratio displayed the video has square pixels.

[Sharc]

Looking at the picture I would also assume that your source is ITU. Now we are back to discussing the 2.4% AR difference.... which apparently continues to cause sleepness night to the purists..... ;-)

Borders or no borders:
As it is most probably (99%) ITU you can crop left and right 8 pixels and leave it at 704 width as ndjamena suggested, and encode with --sar 12:11 (the exact value would actually be 1150:1053, the practical (mpeg4) approximation is 12:11). While a 704 wide picture is for example DVD standards compliant, is is NOT compliant with blu-ray which only accepts 720, 1440 or 1920. So if you should ever have the intention to author the encoded video to a blu-ray disc later, you have to add the borders back to make it 720 overall. Most HW Blu-ray players will spit a 704 disc out.
Alternativley, resizing the cropped picture to 720 and encode it with --sar 16:15 would be another option (resizing the cropped picture to 720 changes the pixel aspect ratio from ITU to "generic"). But unfortunately, --sar 16:15 is not blu-ray compliant.

So long story short: I recommended to add the borders back for the benefit of a "robust" format which will play correctly (or almost correctly) in most playback scenarios, at the risk of a residual 2.4% AR error. But of course x264 and SW players allow a lot of other "options", the final choice is always yours.

And no, I did not recommend to resize to square pixels. My strategy is to neither deinterlace nor resize the originals unless I have a very specific reason. If I re-encode I try to stick to standards rather than to some "free" format - which may work in certain configurations / playback scenarios and fail in others. But that's of course just me.

[Ghitulescu]

To me 1211 (right) is the right DAR.

As you noticed, there is not a single answer to solve it all. Some of the reasons have been discussed in the other thread of yours.
In my humble opinion, the mess with ARs is usually caused by the use of many intermediate steps when the ARs were not properly defined or within large tolerances. For instance, taking the common 4:3 DAR. It originates from film (24mm x 36mm, PAR=1 initially), however the TV (and consequently the tape recordings) were not. The introduction of tape in TV meant another change, the addition of borders. Each small change in formats changed the AR and means to correct that to the right DAR came into place. Even more confusing was the introduction of digital, as now not only the lines were fixed (and different from the original ones, 482 plus 2 halves became 480, thus again a minor change in AR) but also the number of points on the line. And, if ths was not enough, there are film formats far from 4:3 and 16:9, eg the Russian films.

Anyway, finding the right SAR/PAR/DAR by blindly employment of a formula, whatever it may be, is usually wrong. I do myself some tests, trying to figure out on the PC screen (square pixels, PAR=1) what is the best image - I look eg for car wheels or other round objects, compare the face with the correct photos etc etc etc. then crop and add borders as needed to fit 4:3 or 16:9 frame size.

[hello_hello]

Thanks. I'm beginning to think this DVD is an UnHOLY mess. The circles in the TARDIS only look completely circular when I am viewing the video in AvsPmod, and that is at STORAGE Aspect! When it stretches to 768 horizontal, the circles look more eliptical.

Don't trust your brain, it gets used to something and compensates.
The only way to know for sure is to find a straight-on shot of something round or square, save the frame as an image, open it in an image editor and draw a circle or square around it to see which resizing gives you a nice square or circle, but it's easier said than done because unless it's a straight-on shot it won't be perfectly round or square,

That's the problem with the TARDIS circle thingies. Finding a shot where the camera was pointed directly at one of them wasn't always easy.

It'll be ITU, but feel free to drive yourself nuts... I certainly do. When I encoded the PAL 16:9 Buffy DVDs I became convinced the episodes themselves were 16:9 but the opening title sequences were 16:9 ITU, so I resized the title sequence differently. It was a lot of work to cater to my aspect ratio OCD, and even then I could be wrong.....

[Sharc]

Crop has to be multiples of 2 for YV12.

Be careful. For YV12 (normal for DVD) the vertical crop should be mod4 for INTERLACED sources due to the Chroma Interlace Problem.

[hello_hello]

And no, I did not recommend to resize to square pixels. My strategy is to neither deinterlace nor resize the originals unless I have a very specific reason. If I re-encode I try to stick to standards rather than to some "free" format - which may work in certain configurations / playback scenarios and fail in others. But that's of course just me.

Most players support High Profile level 4.1 so everything from 360x240 to 1920x1080 and any combination in between should be fine.... as long as the player supports anamorphic MKVs/MP4s. Via USB mine doesn't so there's a square pixel limitation.
Unless of course you want to be Bluray/DVD compliant, but does anybody do that any more?

That's also just me though. Whatever works for Logan9778.

[hello_hello]

Be careful. For YV12 (normal for DVD) the vertical crop should be mod4 for INTERLACED sources due to the Chroma Interlace Problem.

True, but in this case he's de-interlacing first.

[Sharc]

Most players support High Profile level 4.1 so everything from 360x240 to 1920x1080 and any combination in between should be fine.... as long as the player supports anamorphic MKVs/MP4s. Via USB mine doesn't so there's a square pixel limitation.

Well, all the if...then....else's are exactly my point why I normally try to stick to standards :D

[ndjamena]

Thanks! That makes it a little clearer. AvsPmod won't let me stick in Crop(10.44, 2, -10.44, -2) though. It just gives me an invalid argument error. Then after it, I would add Spline36resize(768,576), right?

You'd have to round the 1.2222 of course. If you add the cropping to the resize filter like Spline36resize(768,576,11,2,-11,-2) you can crop to one pixel precision, otherwise if you use the crop filter (crop(10,2,-10,-2)) you'd need to crop to 2 pixel precision because of the way YV12 stores its colour information.

Spline36Resize was just an example resize filter, I myself tend to use NNEDI3_Resize16 but again, for the most part resize filter choice is mostly down to personal preference and there are plenty to choose from.

[hello_hello]

Most players support High Profile level 4.1 so everything from 360x240 to 1920x1080 and any combination in between should be fine....

By "most" players, I was referring to players that aren't first generation iPhones or iPods, and they don't have disc drives anyway.
I'll officially withdraw the "should" and offer "will" as a replacement as I've not had any problem playing video of any resolution from 1080p down, and if a player won't play a particular video, it's not going to be because the resolution is 1280x544.

....as long as the player supports anamorphic MKVs/MP4s. Via USB mine doesn't so there's a square pixel limitation.

You're aware that if you play a standards compliant 720x576 anamorphic PAL DVD encode via USB it's still anamorphic, and it's the anamorphic part of the standard the player doesn't support? It's the cause, not the cure.
Admittedly TVs have a 16:9 and 4:3 mode for stretching the picture or squishing it as required, and 4:3 mode even overscans so you won't see the black bars you removed and then added back, but you have to stick to exact 16:9 and 4:3 aspect ratios for that not to distort the picture, whereas square pixel encodes will always display correctly without having to switch TV modes.

The Samsung Bluray player in this house assumes MKVs and MP4s have square pixels, but the choice is still between resizing when encoding, or resizing on playback. The only reason I can think of for sticking to "standards" is if you eventually want to create a compliant Bluray disc, but then of course you have to use the restrictive Bluray compatible encoder settings for that, and if you do want to deinterlace to 59.94fps/50fps you have to upscale to 720p because the standards don't support those frame rates for PAL or NTSC resolutions, and I suspect upscaling would involve resizing to square pixels too.

There's no point sticking to standards for playing video with a device without a disc drive, which is almost everything that's not a Bluray player these days. Unless you're wanting to create compliant video discs it's rather unnecessary in my opinion. Possibly even a little silly. Do you know of specific scenarios where non standard complaint encodes will fail to play?

[Sharc]

@hello-hello
No need to defend anything. There are alternatives and options and personal experiences, no doubt. I just wanted to give my reasons to the OP as to why I recommended him to add the borders back, mainly to avoid (confusing) calculations and conversions - take it as my simplistic approach :)

[Logan9778]

Thanks Guys! Let me try to digest all this new info. :eek: :D