VideoHelp Forum
+ Reply to Thread
Results 1 to 27 of 27
Thread
  1. Member
    Join Date
    Jan 2020
    Location
    Harstad - Norway
    Search PM
    I've been Googling for hours and i don't understand how every forum and site refer Pal 720 x 576 as 4:3 when it's clearly 5:4 aspect ratio, i want to upscale and deinterlace my footage in avsynth without stretching or distorting it, wouldn't it be correct to upscale my footage to 1280 x 1024 for HD and then edit and export it in an editing program as regular HD and have it keep the aspect ratio, i feel like no matter where i go forums make it complicated, no one gives a straight answer, assuming my pixels are square i don't see how it could possible be scaled in any other dimension without altering it's original dimension, god why couldn't there just have been one world standard instead of al of these billions of different pixel and display ratios causing confusion.

    Why do i see 720 x 756 listed as 4:3 everywhere? It makes no sense at all, i have the impression that people don't seem to care at all for keeping their true aspect ratio, right now i am just utterly confused as to how to proceed...

    I did a test run and i do think the deinterlaced footage looks a bit stretched vertically, even being it original format size, do i need to convert it to 1280 x 960 in avisynth to get it right?
    Last edited by HansensUniverse; 1st Feb 2022 at 16:10.
    Quote Quote  
  2. May be confusing for newbies, yes. But there are few strong standards like PAL, NTSC, DVD , Blu-ray with standard Display apect ratios of 4:3 or 16:9. Why the heck do users always want to convert, upscale etc. etc. if one world standard should be good enough?
    Quote Quote  
  3. Member
    Join Date
    Jan 2020
    Location
    Harstad - Norway
    Search PM
    Yeah but what is the correct way to upscale my footage? What dimensions do i use? 1280 x 960 to get 4:3??? from my understanding once the footage is interlaced assuming square pixels one should convert to using the 4:3 aspect ratio for Pal since that's what the targeted viewing aspect ratio is (DV) (DVD), i just want to have it confirmed by someone who know for sure.
    Last edited by HansensUniverse; 1st Feb 2022 at 16:29.
    Quote Quote  
  4. If your PAL 720x576 source is from a 4:3 DVD -> resize to 1280x960 for example, or 768x576 to avoid vertical resizing
    If your PAL 720x576 source is from a 16:9 DVD -> resize to 1280x720 for example, or 1024x576 to avoid vertical resizing

    Keep in mind that if your source is interlaced you have to deinterlace before vertical resizing, otherwise you mess the field structure up.

    Or upload a sample.
    Last edited by Sharc; 1st Feb 2022 at 16:48.
    Quote Quote  
  5. Member
    Join Date
    Jan 2020
    Location
    Harstad - Norway
    Search PM
    It's from VHS
    Quote Quote  
  6. Member DB83's Avatar
    Join Date
    Jul 2007
    Location
    United Kingdom
    Search Comp PM
    It can be confusing. If you have mpeg2, a dvd source or DV.avi then you have 720*576 which have a 4:3 DAR flag to display that 720*576 as 768*576 which is now perfect 4:3Other 720*576 sources will report as 5:4If you must upscale you an choose practically any size you desire. But there are caveats. Your source is interlaced and if you crop anything you must de-interlace before resizing.Yes. 1280*960 is valid 4:3 but so is 1440*1080 which can save any ferther scaling in your player/tv
    Quote Quote  
  7. Originally Posted by HansensUniverse View Post
    It's from VHS
    With small black borders left and right? Interlaced? 4:3? If so, bob-deinterlace, crop the left/right borders off (8pixels each) and resize to 1024x768, for example, or 768x576 to avoid vertical resizing and deinterlacing.

    Or upload a sample.

    Bed time now ......
    Last edited by Sharc; 1st Feb 2022 at 17:14.
    Quote Quote  
  8. Member Cornucopia's Avatar
    Join Date
    Oct 2001
    Location
    Deep in the Heart of Texas
    Search PM
    If 720x576 is showing up as 5:4 display aspect ratio, the player app (or your settings) is doing something wrong.
    Do NOT assume your pixels are square. PAL 720x576 (and NTSC for that matter) *ALWAYS* uses non-square pixel (aka sample) aspect ratios. IOW, 5 tall rectangles side by side should NOT look the same as 5 squares of the same height side by side.

    SD PAL (and NTSC) can *ONLY* be 4:3 (most common) or 16:9.

    And if you cannot deinterlace ahead of time (prior to resizing), or use an interlace-aware resizer, best to avoid resizing vertically altogether.
    Sharc's size suggestions are a good place to start.


    Scott
    Quote Quote  
  9. HansensUniverse,
    Given you're using Avisynth, try CropResize. If you follow the link there's pictures showing how to use it.

    5:4 is the storage aspect ratio or resolution. Your capture is anamorphic so it has to be resized to the correct display aspect ratio (or dimensions) on playback. Or in your case, while upscaling.

    The purpose of CropResize is to crop and resize while preventing aspect error, although it's calculations are based on the input display aspect ratio you tell it to use. A VHS capture should have a 15:11 display aspect ratio. It's slightly wider than 4:3 as only 704 pixels of the width should contribute to a 4:3 aspect ratio. The extra 8 pixels each side are probably black or crud.

    This is an example for resizing 4:3 PAL to non-anamorphic dimensions (square pixels). Let's assume you need to crop 8 pixels from the left, 10 from the right and 4 from both the top and bottom to remove all the crud (of course cropping is optional). The first two numbers are the output width and height. If you specify both, the function will crop more picture if necessary to prevent distortion when it resizes, so it's possible to specify only one and zero for the other, which the script will then calculate for you.

    CropResize(768,0, 8,4,-10,-4, InDAR=15.0/11.0)

    If you want an output that's exactly 4:3, specify any exact 4:3 dimensions and the script will crop extra picture if necessary to make it 4:3 before resizing (based on the specified cropping below, it'd only need to crop a few extra pixels for 4:3).

    CropResize(960,720, 8,4,-10,-4, InDAR=15.0/11.0)

    Personally I wouldn't upscale unless there's a need to, but if you do need to, I'd consider converting the colors to the HD standard, although for VHS it probably won't make a noticeable difference.

    CropResize(960,720, 8,4,-10,-4, InDAR=15.0/11.0, ColorMode="601-709")

    If you're mixing the VHS content with 16:9 content, you can also upscale to your desired 16:9 resolution while adding borders to the sides. When adding borders, the script generally won't have to crop much extra picture, if any, in order to resize without aspect error. To add borders you must specify both an output width and height, and Info=true will tell you what CropResize is doing.

    CropResize(1920,1080, 8,4,-10,-4, InDAR=15.0/11.0, ColorMode="601-709", Borders=true, Info=true)

    Of course you need to de-interlace before CropResize in the script. How are you de-interlacing? With QTGMC?

    Oh, and if you think the correct display aspect ratio for the capture is 4:3 rather than 15:11, use 4.0/3.0 for the InDAR instead.

    CropResize(1920,1080, 8,4,-10,-4, InDAR=4.0/3.0, ColorMode="601-709", Borders=true)
    Last edited by hello_hello; 2nd Feb 2022 at 01:51.
    Quote Quote  
  10. Capturing Memories dellsam34's Avatar
    Join Date
    Jan 2016
    Location
    Member Since 2005, Re-joined in 2016
    Search PM
    Yes as hello_hello mentioned your VHS footage is only about 704x576, De-interlace first, crop to 704x576 and resize to 1440x1080 for a perfect 4:3 square pixel, resizing from 720x576 will not give you an accurate 4:3 aspect ratio.
    Quote Quote  
  11. Member
    Join Date
    Jan 2020
    Location
    Harstad - Norway
    Search PM
    Originally Posted by hello_hello View Post
    HansensUniverse,
    Given you're using Avisynth, try CropResize. If you follow the link there's pictures showing how to use it.

    5:4 is the storage aspect ratio or resolution. Your capture is anamorphic so it has to be resized to the correct display aspect ratio (or dimensions) on playback. Or in your case, while upscaling.

    The purpose of CropResize is to crop and resize while preventing aspect error, although it's calculations are based on the input display aspect ratio you tell it to use. A VHS capture should have a 15:11 display aspect ratio. It's slightly wider than 4:3 as only 704 pixels of the width should contribute to a 4:3 aspect ratio. The extra 8 pixels each side are probably black or crud.

    This is an example for resizing 4:3 PAL to non-anamorphic dimensions (square pixels). Let's assume you need to crop 8 pixels from the left, 10 from the right and 4 from both the top and bottom to remove all the crud (of course cropping is optional). The first two numbers are the output width and height. If you specify both, the function will crop more picture if necessary to prevent distortion when it resizes, so it's possible to specify only one and zero for the other, which the script will then calculate for you.

    CropResize(768,0, 8,4,-10,-4, InDAR=15.0/11.0)

    If you want an output that's exactly 4:3, specify any exact 4:3 dimensions and the script will crop extra picture if necessary to make it 4:3 before resizing (based on the specified cropping below, it'd only need to crop a few extra pixels for 4:3).

    CropResize(960,720, 8,4,-10,-4, InDAR=15.0/11.0)

    Personally I wouldn't upscale unless there's a need to, but if you do need to, I'd consider converting the colors to the HD standard, although for VHS it probably won't make a noticeable difference.

    CropResize(960,720, 8,4,-10,-4, InDAR=15.0/11.0, ColorMode="601-709")

    If you're mixing the VHS content with 16:9 content, you can also upscale to your desired 16:9 resolution while adding borders to the sides. When adding borders, the script generally won't have to crop much extra picture, if any, in order to resize without aspect error. To add borders you must specify both an output width and height, and Info=true will tell you what CropResize is doing.

    CropResize(1920,1080, 8,4,-10,-4, InDAR=15.0/11.0, ColorMode="601-709", Borders=true, Info=true)

    Of course you need to de-interlace before CropResize in the script. How are you de-interlacing? With QTGMC?

    Oh, and if you think the correct display aspect ratio for the capture is 4:3 rather than 15:11, use 4.0/3.0 for the InDAR instead.

    CropResize(1920,1080, 8,4,-10,-4, InDAR=4.0/3.0, ColorMode="601-709", Borders=true)


    I wish to upscale to 1440 x 1080, overkill but that's what i want to go for, the black borders don't bother me as they are minimal, so skipping cropping, all i do i just take a 4:3 dimension and resize it? Right? I will convert to the HD color mode thx.
    Quote Quote  
  12. Originally Posted by HansensUniverse View Post
    I wish to upscale to 1440 x 1080, overkill but that's what i want to go for, the black borders don't bother me as they are minimal, so skipping cropping, all i do i just take a 4:3 dimension and resize it? Right? I will convert to the HD color mode thx.
    As has been said: If you resize vertically from 576 to 1080 you must deinterlace your interlaced video before upscaling unless you are using an "interlace aware" upscaler or your tool does it automatically (assuming your source is interlaced of course).
    Note that if you don't crop the small black 8 pixels borders left and right and just upscale to 1440x1080 your picture will be slightly horizontally squeezed by 2.3% (if this should matter to your eyes, it's up to you).
    Last edited by Sharc; 2nd Feb 2022 at 07:36.
    Quote Quote  
  13. Originally Posted by HansensUniverse View Post
    I wish to upscale to 1440 x 1080, overkill but that's what i want to go for, the black borders don't bother me as they are minimal, so skipping cropping, all i do i just take a 4:3 dimension and resize it? Right? I will convert to the HD color mode thx.
    In an ITU rec.601 PAL video capture (virtually all PAL capture devices follow this standard) the 4:3 image is in a ~702x576 portion of the 720x576 frame. So if you want very accurate upscaling you should crop to 702x576 then upscale to 1440x1080. As was pointed out, if you upscale the full 720x576 frame to 1440x1080 the aspect ratio will be about 2 percent off.

    Confusion arises because the DVD spec says the full 720x576 frame constitutes the 4:3 picture. So DVD players will upscale directly from 720x576 to 1440x1080 (then add pillarbox bars to fill out the 1920 pixel wide frame). Commercial DVDs made from analog PAL video tape are usually captured via the ITU spec at 720x576 and written to DVD without compensating for the fact that the 4:3 picture is really in a 702x576 portion of that frame. Nobody in the industry cares.

    704x576 (the frame sizes others have used in this discussion) is supported by DVD and is a nice number for MPEG 2 encoding (which works internally on 32x32 blocks). It's only about 0.2 percent off of the true ~702x576 and is usually considered "close enough" for calculating aspect ratios. Actually, 702 isn't perfectly accurate either -- it's the closest even integer to the true value which I don't remember.
    Quote Quote  
  14. Member Skiller's Avatar
    Join Date
    Oct 2013
    Location
    Germany
    Search PM
    Originally Posted by jagabo View Post
    Actually, 702 isn't perfectly accurate either -- it's the closest even integer to the true value which I don't remember.
    For PAL 702 is actually exact: 13.5 MHz * 52 s = 702 (no rounding at all).


    But really, 704 is good enough. I use 704 for calculations and resizing because it spits out much more practical numbers.
    Quote Quote  
  15. Originally Posted by HansensUniverse View Post
    I wish to upscale to 1440 x 1080, overkill but that's what i want to go for, the black borders don't bother me as they are minimal, so skipping cropping, all i do i just take a 4:3 dimension and resize it? Right? I will convert to the HD color mode thx.
    If you go with a 4:3 display aspect ratio for the entire 720 x 576 resolution, then 1440 x 1080 is right.

    If you go with a 15:11 display aspect ratio instead, which is likely to be very close to correct, then it's
    1080 * 15 / 11 = 1472.72
    and 1472 x 1080 would be a more accurate resize.
    If you want 1440 x 1080 and accurate resizing, crop the width to 704 before you upscale.

    If you go with the likely to be even more accurate DAR jagabo mentioned, where 702 x 576 makes up the 4:3 aspect ratio, you need to crop to 702 x 576 before upscaling to 1440 x 1080.

    Or don't crop and the accurate resizing would be.....

    576 * 4 / 3 = 768
    768 / 702 = 1.094 (pixel/sample aspect ratio)
    1.094 * 720 = 787.69
    787.69 / 576 = 1.367 (display aspect ratio using the whole 720 width)
    1080 * 1.367 = 1476.92

    So the slightly more accurate resize would be 1476 x 1080.
    1472 x 1080 and 1476 x 1080 are close enough to each other not to matter, but you'll obviously see some difference comparing them to 1440 x 1080 (without cropping).

    If you need a plugin for the color conversion, ColorMatrix is easy enough to use.
    ColorMatrix(mode="Rec.601->Rec.709", clamp=0)
    http://avisynth.nl/index.php/ColorMatrix

    Although I can't imagine going to the trouble of upscaling to HD and not cropping the video cleanly before resizing, as there's often half lines and/or noise at the top and bottom I'd get rid of too. Given you can crop while you resize with Avisynth's resizers though, and you at least know how much to crop from the sides to resize to 4:3 properly now.....

    Avisynth's resizers can crop any amount. They're not restricted to mod2 cropping like Crop().

    Spline36Resize(1440,1080, 8,0,-8,0) --- 704 x 576 to 1440 x 1080
    Spline36Resize(1440,1080, 9,0,-9,0) --- 702 x 576 to 1440 x 1080

    Although to crop a little more cleanly, I'd probably do the second cropping this way.

    Crop(8,0,-8,0)
    Spline36Resize(1440,1080, 1,0,-1,0)
    or even
    CropResize(1440,1080, InSAR=768.0/702.0) --- it'll crop to a 4:3 DAR before upscaling for you.

    PS. If you're interested, someone recently created a thread on their upscaling experience with this type of source.
    NTSC.... but their method would be much the same for PAL.
    NTSC VHS summary 6: Hybrid for Conversions, Deinterlacing, Upscaling to MP4
    Last edited by hello_hello; 2nd Feb 2022 at 13:18.
    Quote Quote  
  16. Member Skiller's Avatar
    Join Date
    Oct 2013
    Location
    Germany
    Search PM
    Now I know this is getting super-duper finicky and probably is overkill to anyone just trying to get stuff done, but while we are at it , regarding 702 being more accurate than 704 you guys should consider the following as well: there are two half scan lines added during digitization (first half of the top most line and the second half of the very last line). This is because the digital capture window needs to be rectangular. Analog PAL has 575 lines of image, not 576. So if you use a width of 702 you would also have to crop off one line.

    If we use this ratio (702/575) and extrapolate this to 576 lines we get: 576 * (702/575) ≈ 703.22 which is closer to 704 than 702.

    This is also why I prefer to use 704 ever since I learned that these two half lines should be considered.
    Quote Quote  
  17. Member
    Join Date
    Jan 2020
    Location
    Harstad - Norway
    Search PM
    Originally Posted by Skiller View Post
    Now I know this is getting super-duper finicky and probably is overkill to anyone just trying to get stuff done, but while we are at it , regarding 702 being more accurate than 704 you guys should consider the following as well: there are two half scan lines added during digitization (first half of the top most line and the second half of the very last line). This is because the digital capture window needs to be rectangular. Analog PAL has 575 lines of image, not 576. So if you use a width of 702 you would also have to crop off one line.

    If we use this ratio (702/575) and extrapolate this to 576 lines we get: 576 * (702/575) ≈ 703.22 which is closer to 704 than 702.

    This is also why I prefer to use 704 ever since I learned that these two half lines should be considered.
    So basically: Crop(8,0,-8,0)
    Spline36Resize(1440,1080, 1,1,-1,0)?
    Quote Quote  
  18. Capturing Memories dellsam34's Avatar
    Join Date
    Jan 2016
    Location
    Member Since 2005, Re-joined in 2016
    Search PM
    DVD has actually a legal resolution of 704x576 for PAL/SECAM and 704x480 for all NTSC variants, I haven't seen any mention to 702 being an official standard, But in practice the junk surrounding the frame is never the exact number, it varies from tape format to another and from a standard to another, But when I crop I always base my calculations on 704. It seems to be the most accurate, I even did a circle test in one of the threads to demonstrate it a while back.
    Quote Quote  
  19. Originally Posted by HansensUniverse View Post
    So basically: Crop(8,0,-8,0)
    Spline36Resize(1440,1080, 1,1,-1,0)?
    Code:
    QTGMC() #or a deinterlacer of your choice for deinterlacing before vertical resizing of interlaced VHS footage
    Crop(8,0,-8,-8) #also crop the bottom VHS head switching noise, assumed to be 8 pixels here
    AddBorders(0,4,0,4) #pad and center to 704x576
    Spline36Resize(1440,1080)  #upscale and convert to square pixels, 4:3
    or upload a sample of your source to collect more (academic) comments.
    Last edited by Sharc; 2nd Feb 2022 at 16:27.
    Quote Quote  
  20. Member
    Join Date
    Jan 2020
    Location
    Harstad - Norway
    Search PM
    Originally Posted by Sharc View Post
    Originally Posted by HansensUniverse View Post
    So basically: Crop(8,0,-8,0)
    Spline36Resize(1440,1080, 1,1,-1,0)?
    Code:
    QTGMC() #or a deinterlacer of your choice for deinterlacing before vertical resizing of interlaced VHS footage
    Crop(8,0,-8,-8) #also crop the bottom VHS head switching noise, assumed to be 8 pixels here
    AddBorders(0,4,0,4) #pad and center to 704x576
    Spline36Resize(1440,1080)  #upscale and convert to square pixels, 4:3
    or upload a sample of your source to collect more (academic) comments.
    I did this which worked the best for my footage.

    Crop(8,7,-8,-7)
    AddBorders(0,7,0,7)
    Spline36Resize(1440,1080, 1,0,-1,0)

    This way the top and lower black bars are equal.
    Quote Quote  
  21. Personally, I never add borders (although when combining video with different DARs sometimes it can't be avoided), but the wider the DAR, the more the video fills a 16:9 display. Adding back top and bottom borders to make it 4:3 again does the opposite of that.

    If there's a total of 14 pixels that need cropping from the height and you increase it by 3.

    Crop(8,8,-8,-8)
    Spline36Resize(1488,1080, 0,0,0,-1)

    It's like being given an extra 24 pixels each side for free, and if it helps you feel any better about it not being exactly 4:3, it's only a couple of pixels off the Academy ratio of 1.375.

    Anyway, as how much you actually need to crop is still a secret, you might want to have a play with Yoda's Resize Calculator.
    In order to use the 702 x 576 = 4:3 DAR, you need to select PAL 4:3 as the input, check the custom DAR option and use 160:117 as the custom DAR.
    160 / 117 = 1.367521. It's an exact representation of the DAR I calculated in my last post. To use 15:11 as the source DAR, you can select mpeg4 from the drop down PAR list.

    The output dimensions turn red when you upscale, but it's just to let you know. Nothing to worry about. And using Mod4 for the resizing dimensions it fine.
    And of course you can crop less from the sides if there's not much to crop there, rather than crop more from the height.

    Image
    [Attachment 63166 - Click to enlarge]
    Last edited by hello_hello; 2nd Feb 2022 at 21:35.
    Quote Quote  
  22. Originally Posted by Skiller View Post
    This is also why I prefer to use 704 ever since I learned that these two half lines should be considered.
    I also recall reading somewhere (probably Wikipedia) that a SMPTE square pixel isn't actually square, but it has a 767:768 aspect ratio. Know anything about that one?

    I'd also like to understand this.
    Wikipedia says the exact PAL digital PAR (that nobody uses) is 59:54.
    https://en.wikipedia.org/wiki/Pixel_aspect_ratio#Digital_video_processing
    At some stage I discovered if you take the "almost exact ITU" PAL PARs from this list,
    https://forum.doom9.org/showthread.php?p=1058927#post1058927
    and multiply them by 767/768, you end up with the exact digital PARs mentioned on Wikipedia. For example:

    128/117 * 767/768 = 59:54

    It only works for the PAL "almost exact ITU" PARs in the list though, not NTSC. I don't know why.

    By the way, I just noticed Wikipedia says the exact width is 702.915254 for PAL 4:3, but I'll have to think about that one after I visit the real world for a bit.
    Last edited by hello_hello; 2nd Feb 2022 at 21:54.
    Quote Quote  
  23. Originally Posted by hello_hello View Post
    ....Wikipedia says the exact PAL digital PAR (that nobody uses) is 59:54.... .
    Hmmm, how can you say that "nobody" is using this?
    - Open a video in VirtualDub2, right click into the picture. What values do you find under AspectRatio?
    - Run AvsPmod. Tools-> Resize calculator. Click the ... under Pixel aspect ratio. What values are listed there?
    - See the table in https://www.afterdawn.com/glossary/term.cfm/pixel_aspect_ratio
    The "nobodys" seem to be quite a few

    At some stage I discovered if you take the "almost exact ITU" PAL PARs from this list,
    https://forum.doom9.org/showthread.php?p=1058927#post1058927
    and multiply them by 767/768, you end up with the exact digital PARs mentioned on Wikipedia. For example:

    128/117 * 767/768 = 59:54

    It only works for the PAL "almost exact ITU" PARs in the list though, not NTSC. I don't know why.
    As I understand it, the original luma sampling rate for producing square pixels has been defined as
    12 3/11 MHz for NTSC (defined by whom and rationale I don't know)
    14.75 MHz for PAL (defined by whom and rationale I don't know)

    The luma sampling rate for digital video has then been standardized to 13.5 MHz, same for NTSC and PAL, leading to non-square PixelAspectRatios like
    12 3/11 : 13.5 = 10:11 for NTSC
    14.75 : 13.5 = 59:54 for PAL
    Something more here:
    https://lurkertech.com/lg/video-systems/sd-pixelaspect-derivation.html

    To find the "truth and nothing but the truth" between 702 and 704 for analog transfers one would have to trace and study in depth the full global history of the development from analog to digital video through all standardization bodies, understand the (right or wrong) assumptions, conflicting views, misunderstandings, agreements for (international) standardization, "best" compromises etc., and last but not least practical implementation aspects (the legacy mod 16 is just one of these), .... and eventually build up our own "truth".

    Oh well, so far I felt pretty comfortable with the 704 pixels and 12:11 PAR for 4:3 PAL, for the sake of simplicity or lazyness
    Last edited by Sharc; 10th Apr 2022 at 02:34.
    Quote Quote  
  24. Originally Posted by Sharc View Post
    Originally Posted by hello_hello View Post
    ....Wikipedia says the exact PAL digital PAR (that nobody uses) is 59:54.... .
    Hmmm, how can you say that "nobody" is using this?
    - Open a video in VirtualDub2, right click into the picture. What values do you find under AspectRatio?
    - Run AvsPmod. Tools-> Resize calculator. Click the ... under Pixel aspect ratio. What values are listed there?
    - See the table in https://www.afterdawn.com/glossary/term.cfm/pixel_aspect_ratio
    The "nobodys" seem to be quite a few

    Oh well, so far I felt pretty comfortable with the 704 pixels and 12:11 PAR for 4:3 PAL, for the sake of simplicity or lazyness
    Yeah, I generalized too much, but I was referring to a similar thing.
    59:94 should be the SAR when sampling analogue PAL, but aside from converting analogue to digital, 12:11 is the standard, and as you do, 12:11 is often assumed for sources that began life as analogue too.

    The main reason I use 12:11 is as a by-product of thinking in terms of DAR rather than SAR, because like 4:3 and 16:9, there's only two mpeg4 DARs for both PAL and NTSC... 15:11 and 20:11.
    I almost always resize to square pixel dimensions when re-encoding anyway, so all I need to remember is the two DARs and generally don't need to think about the SAR, which is a good thing because my memory is terrible. Although I suspect 59:54 might have made it all the way into long term memory while I was typing this post. I'll know tomorrow.
    Last edited by hello_hello; 3rd Feb 2022 at 09:40.
    Quote Quote  
  25. Member Skiller's Avatar
    Join Date
    Oct 2013
    Location
    Germany
    Search PM
    Originally Posted by hello_hello View Post
    I also recall reading somewhere (probably Wikipedia) that a SMPTE square pixel isn't actually square, but it has a 767:768 aspect ratio. Know anything about that one?
    Yes, as Sharc said these industry square pixel formats use a different base sampling rate to archive the higher pixel-per-line count to make a 768x576 frame (instead of resizing the 13.5 MHz originated frame to square pixels in the digital domain as we would). AFAIK this format was mostly used in CCTV systems.

    For PAL 14.75 MHz was standardized for this. However, as I'm going to proof in the next paragraph, that sampling rate only does produce a perfect PAR 1:1 768x576 frame if the sampled line length was 52.06780 s (instead of 52 s). This slightly longer line sampling compensates for the two half lines.
    But if the usual standard of 52 s was used instead, the PAR would change from 1:1 to 768:767.

    52.06780 / 52 = 768:767


    Originally Posted by hello_hello View Post
    By the way, I just noticed Wikipedia says the exact width is 702.915254 for PAL 4:3
    It seems this is to take the half lines into account by adding some slight horizontal padding to balance out the vertical padding of the half lines (to keep the resulting frame at 576 lines, rather than 575). It is needed in conjuction with PAR 59:54 or 14.75 MHz sampling rate to produce a 768x576 PAR 1:1 frame, which makes sense I think. See:

    702.915254 * 59:54 = 768
    14.75 MHz * 52.06780 s = 768


    Conclusion: the difference between 52.06780 s and 52 comes from 52.06780 being optimized to spit out perfect square pixels in conjuction with a base sampling rate of 14.75 MHz while keeping the frame's line count at a nice 576 (taking half lines into account), while 52 s is the actual active image.




    59:54
    This PAR seems to be derived from the above mentioned industry square pixel format.
    As Sharc mentioned 14.75 / 13.5 = 59:54
    Again, 14.75 MHz * 52.06780 s = 768
    Makes sense I think!



    128:117
    This PAR is based on 13.5 MHz * 52 s = 702 pixels, but it does not account for the two half lines at all and assumes that analog PAL has 576 active picture lines.

    576 * 4:3 / (13.5 MHz * 52 s) = 128:117



    1150:1053
    This PAR is like 128:117 but it does take the half lines into account (i. e. active PAL = 702x575). It is almost literally the same as 59:54 but with a more practical, straightforward approach that doesn't bother with the industry square pixel 14.75 MHz and 52.06780 s stuff.

    It is derived like this:
    575 * 4:3 / (13.5 MHz * 52 s) = 1150:1053





    My personal conclusion:

    128:117 is flawed and should not be used.
    1150:1053 and 59:54 are equally exact but 12:11 is the sane one to use.
    Quote Quote  
  26. Thanks. Something to bookmark.
    Quote Quote  
  27. Skiller,
    thanks for the info. I'll bookmark this one too.
    Quote Quote  



Similar Threads

Visit our sponsor! Try DVDFab and backup Blu-rays!