[FFmpeg-user] sntsc

Andrew Randrianasulu randrianasulu at gmail.com
Tue Jan 9 12:13:09 EET 2024


вт, 9 янв. 2024 г., 11:35 Mark Filipak <markfilipak.imdb at gmail.com>:

> On 1/8/24 01:46, Andrew Randrianasulu wrote:
> > пн, 8 янв. 2024 г., 09:13 Mark Filipak <markfilipak.imdb at gmail.com>:
> >
> >> On 1/8/24 00:26, Andrew Randrianasulu wrote:
> >>> пн, 8 янв. 2024 г., 05:14 Mark Filipak <markfilipak.imdb at gmail.com>:
> >>>> What is it that you want to know?
> >>>
> >>> I think I like to try and see bigger picture behind acronyms.
> >>
> >> What acronyms?
> >
> > SAR, DAR, PAR .....
>
> DAR is a physical aspect (i.e., a W/H). It is the dots-by-lines aspect of
> the view. Note that I
> don't use the word "display" because that makes many people think of a
> whole screen. I use the word
> "view", instead, as in "lines per view", not "lines per display".
>
> PAR is a physical aspect (i.e., a W/H). It is the pixels-by-rows aspect of
> the 'picture' matrix.
> Note that I use the word 'picture', an alias, because data matrices are
> not really pictures. But
> MPEG and the rest of the world call them "pictures" so I call them
> 'pictures'.
>
> SAR is not a physical aspect, it's an aspect transform. It transforms
> pixels-by-rows to
> dots-by-lines. SAR = DAR/PAR means view(W/H)/'picture'(W/H). For example,
> (1024/576)/(720/576).
>
> Details.
>
> "DAR" means "display aspect ratio" and you probably know all about that.
> It's dpl/lpv, i.e., (dots per line)/(lines per view).
>     DAR
>   dpl/lpv
> 1024/576 = 16/9 for 16:9 'PAL',
>   768/576 =  4/3 for  4:3 'PAL',
>   853/480 = 16/9 for 16:9 'NTSC',
>   720/540 =  4/3 for  4:3 'NTSC'.
>
> "PAR' means "picture aspect ratio".
> It's ppr/rpp, i.e., (pixels per row)/(rows per 'picture').
>    PAR
> ppr/rpp
> 720/576 = 5/4 for 16:9 'PAL',
> 720/576 = 5/4 for  4:3 'PAL',
> 720/480 = 3/2 for 16:9 'NTSC',
> 720/480 = 3/2 for  4:3 'NTSC'.
>
> "SAR" means "sample aspect ratio". That term is from the days of flying
> spot film scanners. Modern
> SAR is actually not an aspect at all. It's a transform.
> SAR transforms pixels-by-rows into dots-by-lines [note1].
> It's dpp/lpr, i.e., (dots per pixel)/(lines per row).
>          'SAR'
>         dpp/lpr
>   (dpl/ppr)/(lpv/rpp) [note2]
> (1024/720)/(576/576) =  1024/720   =  64/45  for 16:9 'PAL'  -- 64 dots
> per 45 pixels,
>   (768/720)/(576/576) =   768/720   =  16/15  for  4:3 'PAL'  -- 16 dots
> per 15 pixels,
>   (853/720)/(480/480) =   853/720   =  32/27  for 16:9 'NTSC' -- 32 dots
> per 27 pixels,
>   (720/720)/(540/480) = 1/(540/480) = 1/(9/8) for  4:3 'NTSC' -- 9 lines
> per 8 rows [note3].
>
> [note1] Though modern SAR is actually a transform -- a 'picture'-to-view
> transform (PVT) -- the
> "SAR" acronym has become so entrenched in the art that it would be
> impossible to get people to
> change to "PVT". I try to get around the issue by calling
> SAR-as-transform, 'SAR' (meaning it's an
> alias, not a real aspect ratio).
>
> [note2] The following is not a 'stupid math trick', it is real.
> 'SAR' = dpp/lpr =  (dpl/ppr)/(lpv/rpp) =  (dpl/lpv)/(ppr/rpp) = DAR/PAR.
> For example,
> 'SAR' = dpp/lpr = (1024/720)/(576/576) = (1024/576)/(720/576) =
> (16/9)/(5/4) = DAR/PAR.
>
> [note3] Why is 4:3 'NTSC' so different? Well, there's two ways to look at
> it:
> 1, for 4:3 'NTSC', 'SAR' is less than one while for the others, 'SAR' is
> greater than one, and
> 2, turning 4:3 'NTSC' into 640x480 would lose resolution whereas 720x540
> preserves resolution.
> The difference is moot because TVs don't use 'SAR' anyway. What they do is
> look at the size of their
> screen (e.g., 1920x1080), look at DAR in the PES header (e.g. 4/3),
> compute the size of the view
> based on that DAR (e.g. 1440x1080), and scale directly (e.g., turn 4-by-4
> pixel blocks into 8-by-9
> dot blocks). That makes 'SAR' a kind of fiction (which it is in a way).
>
> If you're unhappy with 'SAR', then just forget it. Know DAR and PAR
> though. Know them well.
>

it hard to forgot if libav*  internals want it ;)

And I want to fix this little bug of ours when we not setting it (and thus
DAR indirectly) on encoding in some cases ....

https://git.cinelerra-gg.org/git/?p=goodguy/cinelerra.git;a=summary

our git, just in case. (I posted link before but at least on mobile
(Android)  gmail client switching between mails is slow task in itself)

our current ah wondering about and around aspects:

https://lists.cinelerra-gg.org/pipermail/cin/2024-January/thread.html

cinelerra had interesting history down to very early 2000s, so some
"aspects" (pun intended) of it are not very obvious from variable names
used (just aspect_ratio for example)




> -- Mark.
>
>


More information about the ffmpeg-user mailing list