Open markfilipak-windows opened 3 years ago
I understand that some people are passionately committed to "PAR" being "Pixel Aspect Ratio", but that's just plain wrong (according to the MPEG spec).
I've never heard of "Picture-AR" and "Sample-AR". There are multiple sources on Doom9 and even wikipedia says that DAR is display apect ratio and SAR is storage aspect ratio.
I can't respond with quote because the [...] menu malfunctions for me, so I hope this will do.
Yes, you'll read all sorts of nonsense. In the MPEG-TS specification it is very clear. DAR is indeed Display Aspect Ratio (display total width in dots)/(display total height in dots) -- not Data AR as some folks presume -- and which assumes that the display has square dots, or translates what it has into square dot equivalents. SAR is Sample AR (sample apperture width in mm)/(sample apperture height in mm) -- not Storage AR as some folks claim. I have tables of sample appertures for flying spot scanners in various 35mm and 70mm film frames (e.g. Fox Movietone, Academy, 1.66 Vistavision, 1.85 Vistavision 35, 1.85 Vistavision 70, Cinemascope 1, 2, 3, and 4, Panavision 70, ...well, you get the idea). PAR is not defined by the MPEG-TS specification. Instead, there's an equation. But make no mistake, it's Picture AR that's computed in the equation. The reason it's "Picture" is that in the spec a Picture is the dataset, the assemblage of samples, not what your eyes see (which is DAR). The units of PAR is (dataset samples per column)/(dataset samples per row). Some knowledgable folks agree with me that confustion hurts novices and others don't care or don't think it matters. Both are probably correct at various times and with various novices.
I tried to convince the ffmpeg folks that this was all quite important and I offered to completely document all of it. They attacked me. Oh, well.
Correction upon rereading: "The units of PAR is (dataset samples per column)/(dataset samples per row)" should be " The units of PAR is (dataset samples per row)/(dataset samples per column)". That is, (horizontal)/(vertical) or x/y, as are all the others. As aspects, they carry the units. As aspect ratios (i.e. x:y) they are dimensionless.
Regarding Wikipedia and video, I estimate that about 1/4 of everything written is wrong.
Found it!
In section 3.44, the ITU H.262 specification defines DAR as "The ratio of height divided by width (in spatial measurement units such as centimetres) of the intended display". The ITU definition is upside down (i.e. it is 1/DAR). That is, it is H/W as a ratio (H:W) instead of the more common W/H.
Likewise, in section 3.114, the ITU H.262 specification defines SAR as "the vertical displacement of the lines of luminance samples in a frame divided by the horizontal displacement of the luminance samples". Once again the ITU definition is upside down. Note that sample-to-sample "vertical displacement" is generally the same as sample aperture height, and that sample-to-sample "horizontal displacement" is generally the same as sample aperture width. I think the authors of H.262 used "displacement" so that the actual sample aperatures may overlap somewhat and still be okay per the specification.
The ITU H.262 specification does not define PAR, however, section 6.3.3 includes a definition of sorts: "SAR = DAR x (horizontal size)/(vertical size)". Note that horizontal/vertical is not upside down. Also note that "(horizontal size)/(vertical size)" is actually PAR.
So, using the ITU upside down definitions for SAR and DAR plus its right side up definition of PAR, the H.262 equation becomes 1/SAR = 1/DAR x PAR which, when rearranged, becomes DAR = PAR x SAR.
That equation is really what matters. It works only if DAR is Display AR, PAR is Picture AR, and SAR is Sample AR.
I am going to ignore the "how do you call a thing" part of this, and just going to note that the issue that seemed to be underlying here is that this user's build seems to somehow override the default video aspect ratio when running the mpv binary in a specific way. Seemingly setting the value to zero (interpreted as 1:1) instead of the default -1 (original). Also apparently in that state his mpv binary would also not load up his input.conf.
I did note that he should try another binary (since it could be a toolchain or specific build's issue) or see if there was something funky he was in that specific way (his extension registration). I have not had this issue myself, but I can of course try it later with an up-to-date master build.
As for the aspect ratio that mpv shows in stats, the definition of that is simple. It is the actively utilized display aspect ratio by mpv. At the end of the day, that is what matters (for a player). Which includes any overrides the user may have done (with video-aspect-override
being the primary thing that overrides that):
{"aspect", SUB_PROP_FLOAT(d_w / (double)d_h)},
https://en.wikipedia.org/wiki/Pixel_aspect_ratio
You even mention non-square pixels in your original post here, @markfilipak-windows Are you gonna pretend that this is not a thing or what? It does not matter what a single spec says.
Well, I submitted a feature request and stated why it's important to me and others. That's that. It would be great if MPV provided the information regarding PAR & SAR, regardless how you define them.
An example of MPV's utility: MPV is the only tool I've found that provides an easy-to-see clue that differentiates soft telecine from hard telecine -- yes, I know to look at repeat_first_field, but most people wouldn't know how.
I should also note 2 other related items: 1, FFPROBE sometimes (rarely) get's it wrong, and 2, My abilities are limited because, while I know how to parse MPEG-TS fully for VOBs, I don't know how to parse any of the other transport streams.
Regarding the problems that JEEB rightly mentions, I'm working on it but it's unrelated to this feature request. A side note about that though: I noticed the problem with the 2018 version of MPV only occasionally but it seems to have gone hard in the latest version (at least in the build I downloaded).
Thanks All. Over and out.
Oh, one last thing -- I'd edit my last posting but github won't let me do that...
@ValZapod: I read the links you provided -- thanks -- and I have a comment. The case cited was for a video having SAR=1:1. In that case, the values of PAR & DAR are equal (i.e. |PAR|==|DAR|) but they are not the same thing (i.e. PAR!=DAR).
Before requesting a new feature make sure it hasn't been requested yet.
I tried searching on this: "Aspect Ratio" type:meta:feature-request and could not find Joy. I appologize if this request is redundant. I'm trying my best.
Expected behavior of the wanted feature
Please, I beg, instead of "Aspect Ratio", display at least PAR, e.g. 3:2 (or 1.50), and SAR, e.g. 8:9 (or 0.89), and maybe also DAR, e.g. 4:3 (or 1.33) so that DAR=PAR*SAR. I need to know what a video actually is but MPV reports differing "Aspect Ratio" depending on the command line arguments. That also determines whether (and how) MPV scales screenshots.
Some people think DAR is "Data AR" and PAR is "Pixel AR" and SAR is "Screen AR". Some working with Blu-ray discs think that DAR and PAR are the same thing -- that, only because Blu-ray feature films have square pixels (i.e. SAR=1:1), and thus DAR=PAR -- the same value but not the same thing.
Please, I beg, report at least DAR & SAR as found in the MPEG-TS so to remove the mystery of what "Aspect Ratio" (as reported by MPV) is. Of course, this assumes that you developer folks can agree that DAR is Display-AR (of the current display, which is consistent with the MPEG spec), and PAR is Picture-AR (as the word "Picture" is used in calculations in the MPEG-TS (ITU) spec), and SAR is Sample-AR (i.e. individual W:H aspect of samples, which is consistent with the MPEG spec). I understand that some people are passionately committed to "PAR" being "Pixel Aspect Ratio", but that's just plain wrong (according to the MPEG spec). The reason this is needed is because MPV scales screenshots to match what it displays as "Aspect Ratio", so I can't even rely on a screenshot to confirm the dimensions of raw video.
Alternative behavior of the wanted feature
None.
Log file
Not applicable for a feature request.
I appologize if this post has any typos. There's no preview, and after submission, I can't edit because clicking [...] in github gets no response other than a spinner that never ends.