[Cin] DAR, PAR and SAR, again

[Terje J. Hanssen]

Den 19.01.2024 21:42, skrev Terje J. Hanssen:
>
>
> Den 19.01.2024 17:56, skrev Andrew Randrianasulu via Cin:
>> On Fri, Jan 19, 2024 at 7:54 PM Andrea paz via Cin
>> <cin at lists.cinelerra-gg.org>  wrote:
>>> I am opening a new post because the previous one, for me, was becoming
>>> too confusing.
>>>
>>> I quote Terje's latest email:
>>>
>>> ==============================================================
>>>
>>> Well, I have prioritized more to understand what happends than
>>> interprete the somewhat ambiguous definitions.
>>> (the order of the factors is indifferent).
>>> https://stackoverflow.com/questions/18877243/why-ffmpeg-print-sar-instead-of-par
>>>
>>> I think of SAR in the FFmpeg output as a correction factor for the
>>> recordered picture frame format resolution (Wp), to get the desired
>>> output display resolution (expanded Wd with square px) at a given DAR,
>>> (or in opposite order).
>>>
>>> I found a useful table at ffmpeg-user that contains information for
>>> practically all SD and HD video formats.
>>> Maybe something for the manual?
>>> https://www.mail-archive.com/ffmpeg-user@ffmpeg.org/msg27522.html
>>>
>>>
>>>                 display     DAR       picture     PAR      SAR = DAR/PAR
>>>               ===========  ====     ===========  ====     =====
>>> 16:9-2160:  3840 x 2160  16:9  :  3840 x 2160  16:9  :   1:1
>>>    4:3-2160:  2880 x 2160   4:3  :  2880 x 2160   4:3  :   1:1
>>> 16:9-1080:  1920 x 1080  16:9  :  1920 x 1080  16:9  :   1:1
>>>    4:3-1080:  1440 x 1080   4:3  :  1440 x 1080   4:3  :   1:1
> I don't know the video format in the last (fourth) line above; the 
> third line is FHD
> -------------------------------------------------------------
> But I think the two HDV formats are forgotten in the table - so I add 
> them below (?):
>
> 16:9-1080:   1920 X 1080  16:9 :  1440 X 1080  (4:3) :  1:1
>     16:9-720:   1280 x 72016:9 : 1280 x 720 (16:9) : 1:1
Just for testing, the first HDV should be:)

     16:9-1080:   1920 X 1080  16:9  :  1440 X 1080  (4:3) :  4:3
> -----------------------------------------------------------
>>>    16:9-576:  1024 x 576   16:9  :   720 x 576    5:4  :  64:45
>>>     4:3-576:   768 x 576    4:3  :   720 x 576    5:4  :  16:15
>>>    16:9-480:   853 x 480   16:9  :   720 x 480    3:2  :  32:27
>>>     4:3-480:   640 x 480    4:3  :   720 x 480    3:2  :   8:9
>>> [...]
>>>
>>> ===========================================================
>>>
>>> My God, I feel like giving up....
>>> The following is my opinion (indeed, my delirium!).
>>> The table is wrong (for ffmpeg!) because it uses PAR. As is also
>>> stated in the thread you cited:
>
> I guess the user did his best on the list.  From a feedback I saw they 
> did like the table, but not the long definitions with reference to and 
> old (abandoned) mpeg standard.
>
> The most important table colums with regards to ffmpeg and CinGG use, 
> are Picture format, SAR and DAR.
>
> But look at CinGG's Set Format window, if and when user want to define 
> and control the output format himself:
>
>   * Canvas size: Width and Height is there (the frame format)
>   * Display Aspect Ratio is there (DAR)
>   * Imo the calculator fields are of no importance(?)
>
> But  where to enter the most important SAR correction factor for 
> anamorphic format?
>
>
>
>>> "> PAR (picture aspect ratio [1]) [noun]: 1, The horizontal-to-vertical
>>>   > size [3] ratio (H:V, e.g. 5:4, 3:2) for pictures.
>>> get rid of this one altogether, because nothing in FFmpeg use it, and
>>> rightly, because nobody should use it."
>>>
>>> Instead of calling it PAR, it should be considered simply the aspect
>>> ratio of W x H of the input. That is, the W/H of the formula DAR=W/H x
>>> SAR (and not DAR=PAR x SAR). PAR and SAR cannot be different since
>>> they are the same thing (i.e. the shape of a single pixel, as seen
>>> from the imagehttps://stackoverflow.com/questions/18877243/why-ffmpeg-print-sar-instead-of-par
>>> that you mentioned). In practice, in my opinion, the PAR in the table
>>> is nothing more than the SAR meant as Storage aspect ratio; in fact,
>>> the author of the table defines it as a Picture aspect ratio, which is
>>> a frame aspect ratio and not a pixel aspect ratio. It seems to me that
>>> in an effort to be precise, it creates even more confusion. Instead,
>>> the SAR in the table is nothing more than the S(ample)AR ( =
>>> P(ixel)AR). If you think I am crazy to keep up with these definitions,
>>> you are right!
>>>
>>> The formula DAR = PAR x SAR was convenient and simple, however, ffmpeg
>>> decided to use "samples" instead of pixels and so PAR should no longer
>>> be used. That is why I was thinking of removing all reference to PAR.
>>> The trouble is that if one searches around one always finds PAR and
>>> never SAR meant as "sample a.r."; including many tutorials on ffmpeg.
>>>
>>> The sample concept is derived from analog video signals and is encoded
>>> in the standards BT. 601 and Digital. It refers to horizontal scan
>>> lines (in MHz) and not simply pixels. From Wikipedia: "analog video
>>> does not have pixels, but rather a raster scan, and thus has a
>>> well-defined vertical resolution (the lines of the raster), but not a
>>> well-defined horizontal resolution, since each line is an analog
>>> signal." S(ample)AR was created precisely to adapt the analog concept
>>> to the digital world.
>>>
>>> To further explore the concept of sample:
>>> https://web.archive.org/web/20140816103129/http://lipas.uwasa.fi/~f76998/video/conversion/
>>>
>>> Your definition of SAR as a correction factor is right and I will use
>>> it in txt. Thank you for the cue.
>>>
>>> To summarize: in the digital domain we can use the concept of
>>> S(ample)AR when we are dealing with digital anamorphic formats (for
>>> example, when transcoding to a format that has different aspect
>>> ratio). But the most frequent use is in "standard-definition
>>> television or with DV, HDV and a few other formats. SAR is used via
>>> the formula DAR = SAR x (W/H), where SAR is the conversion factor
>>> between anamorphic Input and Output.
>>>
>>> Perhaps the clearest treatment is as follows:
>>> https://encodingwissen.de/hintergrund/videobild/anamorph/itu-r-bt601/
>>>
>>> It is in German and therefore needs to be translated (the Italian
>>> translation is not very good...). They seem to me to be similar
>>> concepts to Raffaella Traniello's guide.
>>>
>>> As an additional (my) confusion, in CinGG we also have the W/H Ratio
>>> parameters, which are simple multipliers but, if set only one of them
>>> (with values of the classic aspect ratios, 4:3; 16:9, etc.) and
>>> leaving the other one at 1, they act as a real SAR even though they
>>> are not...
>>>
>>> @Andrew
>>> In CinGG/Info-->Detail is the data reported taken using ffmpeg?
>> yes, by same equations as  ffprobe does, hopefully
>>
>>> In other words: does CinGG use SAR like ffmpeg or does it have an even
>>> different way?
>> It only written/named like this there because we must interface with ffmpeg ...
>>
>>> PS: In my opinion, it would be better to change W/H Ratio to "W/H multiplier"
>> if whole line still fit window .... why not. Just ... you see we have
>> new explainer right there. Old tutorials will be confusing if we
>> change this element
>>
>>> --
>>> Cin mailing list
>>> Cin at lists.cinelerra-gg.org
>>> https://lists.cinelerra-gg.org/mailman/listinfo/cin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20240119/4752bef7/attachment-0001.htm>