Are we using the correct PAR settings?

[iamdamosuzuki]

Hi, I recently had a convo with somebody on the Black Magic forums about the DAR/PAR/SAR of our files. The dude was a bit curt, but his concern seems to be that we're not using the correct values for these. You can see the post here.

Just to be clear, I'm using PAR to refer to PIxel Aspect Ratio, where a value of 1 would be square pixels. I know that FFmpeg uses SAR (sample aspect ratio) to refer to what others generally called PAR (pixel aspect ratio), but in this post i'm saying PAR is pixel aspect ratio and SAR is (storage aspect ratio)

The argument is that in D1 video files should have the following attributes:

Frame Size: 720x486 / SAR: 720/486 Clean aperture (active video): 704x486 DAR: 4:3 PAR: 10/11

This is what vrecord uses: Frame Size: 720x486 Clean aperture (active video): 720x486 DAR: 4:3 PAR: 9/10

My understanding is that what we're doing is correct because we got a 4:3 DAR, and we have the entire frame as active video since we don't want to crop and potential content and can't control the size of the frame that's coming in from the tapes. Is this correct? Should we have an option to capture the other way?

[privatezero]

I'm a little confused by his assertion Even if you use 486 then you should not change PARs as those 6 lines should be "forgotten", as if we used the PAR for 720x480 and were generating 720x486 files then we would be at a 400:297 DAR rather than a 4:3 (if I am doing my sample commands right).

So yeah - is his argument that we should be cropping to 720x480 and then using 10/11 for PAR?

[iamdamosuzuki]

Yeah his argument is that we should be cropping to 486, and I think most archivists would argue that we don't want to do this. However, it might be worth asking the community whether or not they want this as an option.

More interesting is that he claim the PAR of 9/10 is made up and doesn't exist. I guess the claim is that there has never been any sort of standard or best practice that used a 9/10 par to make a 720x486 frame size 4:3. I find this a little hard to believe, but if it's true then we're imposing a new format into an already mixed up situation. That said, I think the 9/10 makes perfect sense as far as access, but is it causing problems for long-term preservation?

[bishbashbackup]

Hiya,

I've only worked with PAL, but this article has always provided the best explanation of PAR issues, to my knowledge: https://web.archive.org/web/20110926221502/http://lipas.uwasa.fi/~f76998/video/conversion

I'd also like to see more manual control of pixel aspect ratio in Vrecord. At the moment for PAL it doesn't seem to be taking the horizontal blanking into account, which is resulting in the active video getting squashed.

[iamdamosuzuki]

Thanks for that link, I finally got around to reading it enough times to understand it. If I'm reading it correctly the author is basically saying that the full 720x486 pixels shouldn't actually be 4:3, and that instead the active video portion (710.85 x 486) should actually be 4:3, and this is done with a 0.91 PAR.

If this is correct then vrecord is handing aspect ratio incorrectly. The assumption that vrecord makes is that entire 720x486 frame is active video, and thus we use a PAR of 0.9 to get a 4:3 aspect ratio. So, from a technical standpoint we are doing this wrong. However, in my experience it's exceedingly rare that the active video portion of archival content conforms exactly to 710.85 pixels across. It's typically all over the place, with the horizontal position of content varying during shots. However, this doesn't necessarily change the fact that in order to render the content with the correct geometry we should be using a SAR of 4320/4739 and a PAR of 0.91 (according to this article at least).

[bishbashbackup]

Yes, this matches my understanding and seems to be confirmed by my reading of video standards. This is how it works for PAL:

ITU-R BT.470 states that each line of PAL video has length period of 64µs. Of this, roughly 52µs constitutes active video. ITU-R BT.601 states that SD video should be sampled at 13.5MHz. Therefore:

52µs x 13.5MHz = 702 pixels of active video per line.

BT.601 also states that 720 pixel samples should be allocated to each line, which allows for analogue timing deviations. This results in a total 18 additional pixels of horizontal blanking bookending each line. This all means that the pixels must be non-square (stretched width ways), so that the active video is displayed with a 4:3 aspect ratio. Therefore:

(576 ÷ 3) × 4 = 768 768 ÷ 702 = 128:117

So, if I’ve understood correctly. A freshly digitised PAL tape should have a resolution of 720x576, and a pixel aspect ratio of 128:117.

For Reference: ITU-R BT.470 - https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.470-6-199811-S!!PDF-E.pdf ITU-R BT.601 - https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.601-7-201103-I!!PDF-E.pdf EBU R92-1999 - https://tech.ebu.ch/docs/r/r092.pdf Quick Ref for other tape formats - https://web.archive.org/web/20110926221502/http://lipas.uwasa.fi/~f76998/video/conversion

This also has relevance when converting to square pixels. For access we convert PAL video files to square pixels with a 4:3 resolution (768x576). This requires the horizontal blanking to be cropped. As @iamdamosuzuki points out, there can be timing deviations between different sections, which causes the active video to move about horizontally. So, sometimes the 18 pixel crop has to be done differently on different sections.

[privatezero]

I'm curious how other commonly used capture software treat this - looks like (at least according to this) Premier will set pixel aspect ratio to 0.9 for 720 x 486 capture, @iamdamosuzuki do you know what the Blackmagic capture soft is pumping out?

[bturkus]

had the same thought yesterday. Media Express giving this in MediaInfo:

[bishbashbackup]

For PAL:

-Premiere sets the PAR to 1.094 (128:117). See: https://helpx.adobe.com/uk/premiere-pro/using/aspect-ratios.html -Media Express seems to go for 1.093. Just tested:

---

I suspect Media Express is using 59:54 (as per https://lurkertech.com/lg/video-systems/). This seems to be derived from the so-called "industry standard", of sampling PAL video at 14.75MHz to output a square pixel PAR from the A/D conversion. Instead of sampling at the BT 601 standard of 13.5MHz for non-square pixels:

14.75 ÷ 13.5 = 59:54 (rounds to 1.093)

However, sampling at 14.75MHz does not result exactly result in square pixels:

14.75 x 52 =767

So, you're missing a pixel on each line, if you want 768x576 square pixels. In any case, to then use this to calculate the PAR for non-square seems a bit of a funny way around it. That said the result is pretty close, and it all gets a bit pedantic considering the wobbliness of analogue video.

That said, I think it makes more sense to go 128:117 (1.094) for PAL

[privatezero]

Thanks you both!

Lol - I noticed that the two linked Adobe docs contradict each other - @alexhabgood's looks to be more current so I'd say that it is probably a better source (screenshots for NTSC, but the PAL values were also different)

Older doc:

Newer doc:

[dericed]

Hey everyone, I'm trying to work on this and was chatting with @bturkus about how to present the options. With vrecord you can make two sizes of SD videos: 720x486 and 720x576. If those frames are shown to 4/3 and 16/9 then the SAR, DAR, and PAR is like this:

SAR       * PAR      = DAR
(720/486) * (8/9)    = (4/3)
(720/486) * (6/5)    = (16/9)
(720/576) * (16/15)  = (4/3) 
(720/576) * (64/45)  = (16/9)

However, a lot don't want the 720x486 frame to be 4/3 or 16/9 but want those DAR to apply to the 720x480 within it, so that would add these:

SAR       * PAR      = DAR
(720/486) * (8/9)    = (4/3)
(720/480) * (9/10)   = (4/3)
(720/486) * (6/5)    = (16/9)
(720/480) * (32/27)  = (16/9)
(720/576) * (16/15)  = (4/3) 
(720/576) * (64/45)  = (16/9)

But some say that it's actually the 704x480 of the 720x486 frame that should be 4/3 or 16/9, so then we get:

SAR       * PAR      = DAR
(720/486) * (8/9)    = (4/3)
(720/480) * (9/10)   = (4/3)
(720/486) * (6/5)    = (16/9)
(720/480) * (32/27)  = (16/9)
(720/576) * (16/15)  = (4/3) 
(720/576) * (64/45)  = (16/9)
(704/480) * (10/11)  = (4/3)
(704/480) * (40/33)  = (16/9)

Maybe for readability I can rewrite this as these user-options:

4/3 NTSC options
720x486 @ 4/3; PAR = 8/9
720x480 @ 4/3; PAR = 9/10
704x480 @ 4/3; PAR = 10/11

16/9 NTSC options
720x486 @ 16/9; PAR = 6/5
720x480 @ 16/9; PAR = 32/27
704x480 @ 16/9; PAR = 40/33

4/3 PAL options
720x576 @ 4/3; PAR = 16/15
720x576 @ 16/9; PAR = 64/45

Thoughts? Also for the PAL users, do you have the equivalent madness?

[dericed]

Here's a new draft of user options. Here it emphasizes standards over practice to split recommended and unrecommended values:

Display Aspect Ratio (recommended)
4/3  (NTSC PAR = 10/11; PAL PAR = 12/11)
16/9 (NTSC PAR = 40/33; PAL PAR = 16/11)

NTSC PAR options (unrecommended)
4/3  @ 720x486; PAR = 8/9
16/9 @ 720x486; PAR = 6/5
4/3  @ 720x480; PAR = 9/10
16/9 @ 720x480; PAR = 32/27

PAL PAR options (unrecommended)
4/3  @ 720x576; PAR = 16/15
16/9 @ 720x576; PAR = 64/45

[iamdamosuzuki]

Hi Dave, thanks so much for doing this work. This looks awesome. The NTSC stuff looks great, and I think would do a lot to help normalize vrecord output to what other applications are making. Is there a reason you don't have a recommended PAL PAR setting?

[dericed]

Hey @iamdamosuzuki, in the recommendation I listed the PAR for both NTSC and PAL for either 4/3 or 16/9

Display Aspect Ratio (recommended)
4/3  (NTSC PAR = 10/11; PAL PAR = 12/11)
16/9 (NTSC PAR = 40/33; PAL PAR = 16/11)

[bturkus]

Tested on macOS 14.4.1, capturing NTSC and PAL, 4:3 and 16:9, and everything seems to be working fine (I doubled checked all of the resulting PARs in MediaInfo).

Few things I noticed:

1. It looks like we'll need to update the MediaConch policies
2. Do we want to have 16:9 captures presented as 16:9 during recording?

Thanks for working on this Dave!

[bishbashbackup]

Hey @dericed & @iamdamosuzuki

Thanks both for looking into this. Can't speak for the NTSC side, but have encountered this issue with PAL and BT.601 video.

For digitising standard PAL video signals, I think the recommended aspect ratio settings should be:

------------SAR * PAR = DAR PAL "4:3": (720/576) * (128/117) = (160/117) PAL "16:9": (720/576) * (512/351) = (640/351)

This results in videos with DARs that aren't 4:3 and 16:9 respectively, but I think this is nevertheless correct because the digitised video should (in theory) contain 18 pixels of horizontal blanking. Therefore, with the aspect ratios above, the "active video" within the blanking would be 4:3 and 16:9.

When I last checked, this was how Adobe Premiere sets the PAR for analog PAL video. It also aligns with the recommendations made here: https://web.archive.org/web/20110926221502/http://lipas.uwasa.fi/~f76998/video/conversion. If desired, vrecord users can subsequently crop the 18 pixels of horizontal blanking and convert the video to square pixels, resulting in a video that is 768x576 or 1024x576.

I think it would be good for vrecord to also have the following settings, in the instance of transferring non-standard PAL or BT.601 video that doesn't have horizontal blanking:

---------------SAR * PAR = DAR BT.601 4:3: (720/576) * (16/15) = (4/3) BT.601 16:9: (720/576) * (64/45) = (16/9)

Hope that all makes sense, let me know if anything needs clarifying. :)

[iamdamosuzuki]

d'oh sorry i missed that. Monday vibes. I'll test this out tomorow!

[iamdamosuzuki]

I tested out the branch and it appears to be properly making 10/11 files for NTSC. This matches up with what BlackMagic and Premiere are making. I personally think this is the best way to make files moving forward, but it's worth leaving the question up to the community. It also might be worth having the option to use 10/11, 9/10, 1/1, or even 4320/4739 in the advanced options menu.

[retokromer]

It also might be worth having the option to use 10/11, 9/10, 1/1, or even 4320/4739 in the advanced options menu.

I agree.

[dericed]

Hi everyone, Here's a new draft of an aspect ratio picklist. If we have sufficient rough consensus I'd like the vrecord community to plug a 4/3 and 16/9 value, but I'm thinking we could present a list like this:

Vrecord community recommendations
4/3  (PAR NTSC=10/11; PAL=12/11)
16/9 (PAR NTSC=40/33; PAL=16/11)

Other fun aspect ratios
4/3  (PAR NTSC=8/9; PAL=16/15)
4/3  (PAR NTSC=9/10; PAL=16/15)
4/3  (PAR NTSC=4320/4739; PAL=128/117)
16/9 (PAR NTSC=6/5; PAL=64/45)
16/9 (PAR NTSC=32/27; PAL=64/45)
16/9 (PAR NTSC=5760/4739; PAL=512/351)

In the GUI, this would like this:

Essentially the user would be picking a sample aspect ratio rather than a display aspect ratio, but I suggest each option start with a display aspect ratio as a cosmetic label for each option.

[kieranjol]

I can only chime in on PAL, good to see that 16:15 is still in there. Has anyone seen 12:11 used in any other capture tool? The closest I’ve seen is 59:54 in probably media express but if 12:11 is coming from bt601 then that’s attractive. Is it more accurate (not sure if it’s more or less helpful) to say that the recommendations are coming from a specific standard rather than the vrecord community?

[bishbashbackup]

@dericed That all looks fine to me. :)

@kieranjol Would be interested to hear your view on this.

My understanding is that BT.601 doesn't provide a direct definition of what pixel aspect ratio is correct. Instead it defines a standard for digital video that uses a 13.5MHz sampling rate and a resolution of 720x576.

So if all the 720 horizontal pixels are active, for a 4:3 DAR you'd use 16:15 PAR:

(720÷576)x(16÷15)= 4:3

However, all 720 horizontal pixels wouldn't normally be active when digitising analogue PAL tapes. This is because BT.470 states that each line of active video is around 52µs:

52x13.5=702 active pixels per line

As a result, for digitised analog pal (active) video to achieve 4:3 DAR would require a par of approximately 128:117:

(702÷576)x(128÷117)= 4:3

I think in the early days of digital video, some systems (like dvd) supported a 704x576 resolution. In those instances, the 12:11 dar might be appropriate I suppose, if the active video uses all 704 horizontal pixels. I don't think I've ever come across this though:

(704÷576)x(12÷11)= 4:3

So I guess you could attribute standards,something like:

16/15 - BT.601 128/117 - BT.470 12/11 - Non-standardised

But it may be misrepresenting the standards, since they don't strictly prescribe certain pixel aspect ratios.

¯\(ツ)/¯

Please correct me if I'm mistaken on any of this btw. Am eager to learn!

[iamdamosuzuki]

Hi all, thanks for taking the time to discuss this! Considering that there doesn't seem to be a strong consensus as to which one of these values is absolutely correct, I think it would be best to allow the user the ability to change the PAR setting independently of the DAR setting. However, since the PAR settings may cause confusion and be overkill for most users, these settings should be put in the advanced settings tab, rather than the main tab. My suggestion is that the advanced settings tab allows the user to pick a PAR for each of the following modalities:

• NTSC 4:3
• NTSC 16:9
• PAL 4:3
• PAL 16:9

There can also be a "recommended" note on whichever PAR value is considered by the community to be the recommended value. My argument for the recommended values would be:

• NTSC 4:3: 10/11
• NTSC 16:9: 40/33

I can't personally make a recommendation on PAL, but from @bishbashbackup 's post above it seems like the recommended values could be:

• PAL 4:3: 128/117
• PAL 16:9: 16/11

Those recommendations can be changed at any time, at this point I think it's best to find a way to allow the user to make these selections based off their preference.

[bishbashbackup]

I agree @iamdamosuzuki

Just a slight correction on the 16:9 tho, I would recommend:

PAL 4:3: 128/117 (1.094) PAL 16:9: 512/351 (1.459)

From my understanding of the standards (BT.601 & BT.470), those should be correct when converting from analog pal video source.

These are also the same pixel aspect ratios used/recommended by adobe premiere. See: https://ppro-plugins.docsforadobe.dev/universals/pixel-aspect-ratio.html

[dericed]

Hey all, I updated the PR, see a screenshot at https://github.com/amiaopensource/vrecord/pull/799#issuecomment-2173156919. In the main decklink page the user picks either 4/3 or 16/9 but the config page has the SAR options for fine-tuning. Anyone up for doing some documentation updates to https://github.com/amiaopensource/vrecord/blob/main/Resources/Documentation/settings.md#options-for-video-capture?

[privatezero]

@dericed - I can update the docs, but I'll wait until we push a new release so the docs don't point to features not available in current release version

[dericed]

@privatezero I'm good to do a new release. Otherwise I won't get to too much new til next month.