<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<br>
<div class="moz-cite-prefix">Den 19.01.2024 21:42, skrev Terje J.
Hanssen:<br>
</div>
<blockquote type="cite"
cite="mid:58e0f881-050f-4130-b76c-a7f01f140372@gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<br>
<br>
<div class="moz-cite-prefix">Den 19.01.2024 17:56, skrev Andrew
Randrianasulu via Cin:<br>
</div>
<blockquote type="cite"
cite="mid:CA+rFky6sFUn7UG1KkVwbLLkewBmv6wiZHcSOQ7RDVdX3hjXLow@mail.gmail.com">
<pre class="moz-quote-pre" wrap="">On Fri, Jan 19, 2024 at 7:54 PM Andrea paz via Cin
<a class="moz-txt-link-rfc2396E"
href="mailto:cin@lists.cinelerra-gg.org" moz-do-not-send="true"><cin@lists.cinelerra-gg.org></a> wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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).
<a class="moz-txt-link-freetext"
href="https://stackoverflow.com/questions/18877243/why-ffmpeg-print-sar-instead-of-par"
moz-do-not-send="true">https://stackoverflow.com/questions/18877243/why-ffmpeg-print-sar-instead-of-par</a>
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?
<a class="moz-txt-link-freetext"
href="https://www.mail-archive.com/ffmpeg-user@ffmpeg.org/msg27522.html"
moz-do-not-send="true">https://www.mail-archive.com/ffmpeg-user@ffmpeg.org/msg27522.html</a>
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</pre>
</blockquote>
</blockquote>
I don't know the video format in the last (fourth) line above; the
third line is FHD<br>
<font face="monospace">
-------------------------------------------------------------</font><br>
But I think the two HDV formats are forgotten in the table - so I
add them below (?):<br>
<br>
<font face="monospace"> <strike>16:9-1080: 1920 X 1080 16:9
: 1440 X 1080 (4:3) : 1:1</strike><br>
16:9-720: 1280 x 720</font><span
style="white-space: pre-wrap"><font face="monospace"> 16:9 : 1280 x 720 (16:9) : 1:1</font></span></blockquote>
<font face="monospace">Just for testing, the first HDV should be:)<br>
<br>
16:9-1080: 1920 X 1080 16:9 : 1440 X 1080 (4:3) : 4:3<br>
</font><span style="white-space: pre-wrap"><font face="monospace">
</font></span>
<blockquote type="cite"
cite="mid:58e0f881-050f-4130-b76c-a7f01f140372@gmail.com"><span
style="white-space: pre-wrap"><font face="monospace"> -----------------------------------------------------------
</font>
</span>
<blockquote type="cite"
cite="mid:CA+rFky6sFUn7UG1KkVwbLLkewBmv6wiZHcSOQ7RDVdX3hjXLow@mail.gmail.com">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap=""> 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:
</pre>
</blockquote>
</blockquote>
<br>
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.<br>
<br>
The most important table colums with regards to ffmpeg and CinGG
use, are Picture format, SAR and DAR.<br>
<br>
But look at CinGG's Set Format window, if and when user want to
define and control the output format himself:<br>
<ul>
<li>Canvas size: Width and Height is there (the frame format)</li>
<li>Display Aspect Ratio is there (DAR)</li>
<li>Imo the calculator fields are of no importance(?) </li>
</ul>
But where to enter the most important SAR correction factor for
anamorphic format?<br>
<br>
<br>
<br>
<blockquote type="cite"
cite="mid:CA+rFky6sFUn7UG1KkVwbLLkewBmv6wiZHcSOQ7RDVdX3hjXLow@mail.gmail.com">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">"> 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 image <a class="moz-txt-link-freetext"
href="https://stackoverflow.com/questions/18877243/why-ffmpeg-print-sar-instead-of-par"
moz-do-not-send="true">https://stackoverflow.com/questions/18877243/why-ffmpeg-print-sar-instead-of-par</a>
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:
<a class="moz-txt-link-freetext"
href="https://web.archive.org/web/20140816103129/http://lipas.uwasa.fi/~f76998/video/conversion/"
moz-do-not-send="true">https://web.archive.org/web/20140816103129/http://lipas.uwasa.fi/~f76998/video/conversion/</a>
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:
<a class="moz-txt-link-freetext"
href="https://encodingwissen.de/hintergrund/videobild/anamorph/itu-r-bt601/"
moz-do-not-send="true">https://encodingwissen.de/hintergrund/videobild/anamorph/itu-r-bt601/</a>
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?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">yes, by same equations as ffprobe does, hopefully
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">In other words: does CinGG use SAR like ffmpeg or does it have an even
different way?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">It only written/named like this there because we must interface with ffmpeg ...
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">PS: In my opinion, it would be better to change W/H Ratio to "W/H multiplier"
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">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
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">--
Cin mailing list
<a class="moz-txt-link-abbreviated moz-txt-link-freetext"
href="mailto:Cin@lists.cinelerra-gg.org"
moz-do-not-send="true">Cin@lists.cinelerra-gg.org</a>
<a class="moz-txt-link-freetext"
href="https://lists.cinelerra-gg.org/mailman/listinfo/cin"
moz-do-not-send="true">https://lists.cinelerra-gg.org/mailman/listinfo/cin</a>
</pre>
</blockquote>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>