[Cin] DAR, PAR and SAR, again
Terje J. Hanssen
terjejhanssen at gmail.com
Fri Jan 19 21:42:33 CET 2024
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
-----------------------------------------------------------
>> 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/b72bbcdb/attachment.htm>
More information about the Cin
mailing list