Am I just really bad at mathematics?

[Bruce Wayne]

I was embedding a QuickTime player on another forum using a video that was 720x400. 720x400 were its actual dimensions. According to MediaInfo, its display aspect ratio was 1.92:1. 720/1.92=375. So I put controller=false, width=720, and height=375, and I ended up with white space on the top and bottom of the video. It took me several tries to get rid of the white space. Eventually, I had to make the height of the video 366. 720/366=1.97, not 1.92. So why did MediaInfo tell me that the video's display aspect ratio was 1.92:1 when it was actually 1.97:1?

EDIT: Actually, 720/1.97=365.something so I should really make the height of the video 364.

[KarMa]

Were you re-encoding this video to these different sizes or trying to display the video at different resolutions.

If you want an AR of 1.92, it probably would be better to do 768x400. But I know nothing about the source of this video so idk.

[hello_hello]

How were you obtaining the aspect ratio from MediaInfo? I don't think the GUI's terribly accurate.
You could double check the video with MPC-HC by opening it and using the File/Properties menu. If the resolution and aspect ratio are different it'll display the aspect ratio quite accurately.

Having said that, the aspect ratio written to the video stream and the aspect ratio written to the container might be different or one might not have an aspect ratio, and a player has to choose.

[DB83]

Ok, as stated we do not know the nature of the video.

Neither do we know any quirks of the forum for embedding - maybe it uses a set size e.g 720*480

But why did you not simply try to embed at 720*400. If the embedding player dimensions are fixed then some letter-boxing is inevitable.

Otherwise you might be resizing and the display is not quite right.

[Bruce Wayne]

Were you re-encoding this video to these different sizes

Nope, I was merely using this video as a test. It's dimensions and display aspect ratio were exactly as they were when I first downloaded the video. I didn't touch them.

or trying to display the video at different resolutions.

No. All I wanted to do was display the video at its own resolution but in the aspect ratio MediaInfo told me it was displayed in which was 1.92:1.

If you want an AR of 1.92, it probably would be better to do 768x400. But I know nothing about the source of this video so idk.

I don't want an aspect ratio of 1.92. That's what MediaInfo told me the display aspect ratio was. So I was simply trying to display it the way MediaInfo told me.

[Bruce Wayne]

How were you obtaining the aspect ratio from MediaInfo? I don't think the GUI's terribly accurate.

I right-clicked on the video and selected MediaInfo from the menu. It said width 720, height 400, display aspect ratio 1.92

You could double check the video with MPC-HC by opening it and using the File/Properties menu. If the resolution and aspect ratio are different it'll display the aspect ratio quite accurately.

Thanks! This is what solved the problem for me. Under Properties, it says 720x400 (AR 393:200). 393/200=1.97, NOT 1.92 as MediaInfo told me. Thanks again.

[Bruce Wayne]

Ok, as stated we do not know the nature of the video.

Neither do we know any quirks of the forum for embedding - maybe it uses a set size e.g 720*480

It's my own forum, in phpBB. Here's the HTML code I'm using.

<center><object classid="clsid:02bf25d5-8c17-4b23-bc80-d3488abddc6b" width="{NUMBER1}" height="{NUMBER2}"
codebase="http://www.apple.com/qtactivex/qtplugin.cab">
   <param name="src" value="{URL}">
   <param name="autoplay" value="false">
   <param name="loop" value="false">
   <param name="controller" value="true">
   <embed src="{URL}" width="{NUMBER1}" height="{NUMBER2}" autoplay="false" loop="false" controller="true" pluginspage="http://www.apple.com/quicktime/download/">
   </embed>
</object></center>

But why did you not simply try to embed at 720*400. If the embedding player dimensions are fixed then some letter-boxing is inevitable.

Otherwise you might be resizing and the display is not quite right.

720x400 means a display ratio of 1.8:1. The proper display ratio of this particular video, as it turns out, is 1.97:1. At 1.8:1, the people in it look slightly squeezed.

[Jerome7573_3]

NOT 1.92 as MediaInfo told me. Thanks again.

Please provide a sample file so I can say what is wrong (MediaInfo or your mathematics), here there is an accusation without any way to defend myself.

Jérôme, developer of MediaInfo.

[DB83]

^^ Except your said in the OP that the actual dimension of the video were 720*400.

I accept that mediainfo is saying different but where did the 720*400 come from ?. Unless, of course, the pixels in the video are non-square.

And as my friend above states, without seeing this video we really are none the wiser.

[hello_hello]

Jerome7573_3,
I didn't mean to offend. I actually thought MediaInfo rounded the aspect ratios it displays in the GUI by design. At least when it's close to an "industry standard" aspect ratio such as 1.77 or 1.85 or 2.35 etc. The same seems to apply to frame rates to a certain extent.
A program such as MeGUI often obtains it's aspect ratios from MediaInfo and it's very accurate, which is why I assumed the way MediaInfo's GUI displays them is by design.

Having said that, MediaInfo made a liar out of me first go.... partly at least. I took an AVI I had handy, remuxed it as an MKV, setting 393:200 for the aspect ratio and changing the frame rate from 25fps to 23.965fps. MediaInfo displayed the aspect ratio fairly accurately, but not the frame rate.

MPC-HC has a MediaInfo tab and displays the same info as MediaInfo's GUI would, but MPC-HC's File/Properties menu doesn't always agree, so for checking frame rates and aspect ratios accurately, I've developed the habit of using MPC-HC's File/Properties menu.





In this case both aspect ratios are pretty close but 1.966 would have been more accurate for the aspect ratio and 1.833 more accurate for the "original aspect ratio", so that's where my "rounding" theory originates. I've never tried to work out if there's rules for how much or when it'll be out, as I just use MPC-HC instead. If I can find an example where the aspect ratio is very inaccurate I'll report back.
When I opened the MKV in question with MeGUI it reported the aspect ratio as 785:384, which is accurate to the nearest whole pixel, but unfortunately it went with 23.976 for the frame rate too. I don't know if it obtains both from MediaInfo for MKVs.

While we're here, can I ask how audio delays are saved to MP4? I'll probably have to try to make an MP4 with an audio delay if you want a sample as I've got very few of them, but I do have a fairly large MP4 on my hard drive and as I remuxed it recently it was fresh in my mind. When I open the MP4 with MediaInfo, it looks like this:



After remuxing as an MKV:



I'm not saying the audio delay reported for the MKV is wrong, in fact I'm confident it isn't, but I've noticed that happen enough to wonder why the original MP4 doesn't seem to have the same audio delay.
Edit: gMKVExtractGUI indicates the audio doesn't have a delay, which I should have realised as it's a negative value, but there is a positive 21ms video delay applied to the MKV, so I guess the same question does apply.

Thanks.

PS Another question (sorry about sidetracking the thread) why does MediaInfo display 5.1ch as Front: L C R, Side: L R, LFE for all the usual formats except Opus, for which it displays Front: L C R, Rear: L R, LFE? I understand the surround channels could be interpreted as either side or rear, and I understand why you went with side (I read the old doom9 thread) but I was just wondering if Opus is interpreted differently for a reason.
There's also a few 5.1ch types MediaInfo gets wrong, if you're interested.
5.1ch ALAC in M4A encoded by ffmpeg is displayed as 6ch, but when created by QAAC, MediaInfo gets it right.
5.1ch Ogg and WMA 10 encoded by WMAEncode.exe are both also identified only as 6ch.

Thanks again.

[Bruce Wayne]

^^ Except your said in the OP that the actual dimension of the video were 720*400.

I accept that mediainfo is saying different but where did the 720*400 come from ?. Unless, of course, the pixels in the video are non-square.

And as my friend above states, without seeing this video we really are none the wiser.

MediaInfo isn't saying different. 720x400 comes from MediaInfo, and from MPC-HC. I'm not arguing over the dimensions. When I said those are the actual dimensions, I didn't mean according to some program other than MediaInfo. All I meant was that the DISPLAY aspect ratio is different from what the video's ACTUAL dimensions indicate.

Here's a sample.

MediaInfo says the display aspect ratio is 1.92. The width is 720. 720/1.92=375. Because the width and height both have to be even, we'll say 374. Adding 16 pixels for the QuickTime controller, that's 390. If I embed the QuickTime player on my forum using the HTML code I posted earlier, a width of 720, and a height of 390, I get a white stripe across the top and bottom of the video, 4 pixels deep.

MPC-HC says the aspect ratio is 393:200. 393/200=1.97. 720/1.97=365.something. So we'll say 364. Adding 16 pixels for the controller, that's 380. If I embed using a height of 380 instead of 390, I get no white space.

[DB83]

On my version of MPC-HC the AR of the clip is 48:25 which concurs with the info from mediainfo.

I just wonder if there is some space present in the frame which is ignored at playback so reduces the height with some players whereas it is being shown in your embedded player.

[Bruce Wayne]

On my version of MPC-HC the AR of the clip is 48:25 which concurs with the info from mediainfo.

I just wonder if there is some space present in the frame which is ignored at playback so reduces the height with some players whereas it is being shown in your embedded player.

I wouldn't know about that. That's too technical for me. Anyway, here's info on my version of MPC-HC.

MPC-HC (64-bit)
---------------

Build information:
Version: 1.7.10 (d911f14)
Compiler: MSVC 2013 Update 5
Build date: Nov 14 2015 18:25:24

LAV Filters:
LAV Splitter: 0.66.0.0
LAV Video: 0.66.0.0
LAV Audio: 0.66.0.0
FFmpeg compiler: MinGW-w64 GCC 4.9.2

Operating system:
Name: Windows NT 6.3 (build 9600)
Version: 6.3 (64-bit)

Hardware:
CPU: Intel(R) Celeron(R) CPU N2830 @ 2.16GHz
GPU: Intel(R) HD Graphics (driver version: 10.18.10.3496)

[hello_hello]

DB83, what version of MPC-HC are you using?

MPC-HC 1.7.10 is displaying the sample from post #11 as 393:200 for me, which is 1.965. The MediaInfo tab under the File/Properties menu says 1.92.

MPC-BE 1.4.3 says 112:67 which is 1.965. The MediaInfo tab under it's File/Properties menu says 1.92

The MediaInfo GUI says 1.92.

Potplayer 1.6.59347 says 1.97. It's File Info tab, which I assume is pretending not to be MediaInfo, says 1.92.

SMPlayer says 1.9656

When I disable MPC-HC's internal splitter it says 3600:1831 which is 1.966

Fun and games....

MediaInfo definitely seems to be the odd one out here. Not that it proves it's wrong, but the consensus is something different.

[hello_hello]

MPC 6.4.9.1 (the classic version) says 393:200. It says 786x400 for the video size (it doesn't display an aspect ratio for that).

I found an old version of MPC-HC (1.6.0.4014) that displays 393:200 as the video aspect ratio and 48:25 for the video size. I'm pretty sure "video size" is how it'll be displayed rather than the actual aspect ratio, so it's sometimes slightly different as the video must be displayed using whole pixels. It shouldn't be that different though.

393:200 at 720x400 is a display size of 786x400 so the two should be the same if 393:200 is correct.

There was some sort of bug in MPC-HC a while back regarding the calculation of display aspect ratio, or video size. I think it was the video size calculation but I can't remember for certain. It was a fair while ago and it was fixed and I think it was fairly minor anyway. Not such a huge difference. It seems like a strange co-incidence the older MPC-HC is displaying the video size as MediaInfo does though. I wonder what's going on there?

Edit.... I discovered if MPC-HC 1.6.0.4014 is decoding (it's a pre LAV Filters version) it shows the video size as 720x400 (48:25). If I disable it's internal decoding and give ffdshow a shot at it, MPC-HC 1.6.0.4014 displays the video size as 720x400 (393:200). ffddshow's on-screen-display claims 6707:3412, which is 1.966.

[hello_hello]

A couple of updates later and MediaInfo still says 1.92 while MPC-HC says 1.95.

Anyone know how to work out which is correct? How do you dig the aspect ratio information out of the mpeg2 video stream?

[poisondeathray]

I've never seen a 720x400 MPEG1 video before. Where was it from originally?

(Maybe posting the next few seconds would be good for morale hahahaha )

[jagabo]

MediaInfo was probably assuming an ITU cap and making it's calculations based on the inner 704x400 portion of the frame. Guessing it's cropped from a 4:3 PAL source with a sampling aspect ratio of 12:11:

704 / 400 * 12 / 11 = 1.92

[hello_hello]

I've never seen a 720x400 MPEG1 video before. Where was it from originally?

I'm not sure, as it's Bruce Wayne's sample.

MediaInfo was probably assuming an ITU cap and making it's calculations based on the inner 704x400 portion of the frame. Guessing it's cropped from a 4:3 PAL source with a sampling aspect ratio of 12:11:

704 / 400 * 12 / 11 = 1.92

That makes sense. Whether it's right or wrong, or whether there is a right or wrong, I don't know.
I thought there must be "this is the correct aspect ratio" information buried in the video stream somewhere. I assume not?

[jagabo]

I thought there must be "this is the correct aspect ratio" information buried in the video stream somewhere.

When it comes to MPEG 2 video there is a lot of hand waving going on because of a disagreement between the ITU spec for analog video capture (720x480/576 is usually captured but only the inner 704x480/576 represents the 4:3 or 16:9 image) and the MPEG 2 spec where the entire frame represents the DAR. Some programs go by one spec, some by the other. And when the frame isn't one of the standard DVD sizes there's no telling what they will do.

[poisondeathray]

This is MPEG1 video. But with standardized, valid MPEG1 and 2 streams, there is a value in the sequence header that denotes the aspect ratio information. That value is actually missing in this stream

Some streams also have an additional sequence display extension, but as jagabo says there are different interpretations even on standarized streams with or without the display extension. 16:9 and 4:3 have different meanings according to ITU vs. non ITU. And different software and hardware might ignore or pay attention to some or all of that information

But I'm saying that this is a non standardized stream that is missing that sequence header information. The value is actually "8" which means "error". For example, "1" is square pixel, "2" is 4:3, "3" is 16:9 etc..

[hank315]

There's a sequence header in the source starting at 2E (hex):
00 00 01 B3 2D 01 90 83 0A 00 21 40

which is:

Horizontal size value:   720
Vertical size value:     400 
Aspect Ratio code:       8 (= 0.9375, PAL 4:3)
Frame Rate code:         3 (= 25 fps)

I guess the Display aspect ratio in Mediainfo is calculated as 720 / (400 * 0.9375) = 1.92

[poisondeathray]

@hank - I thought "8" meant undefined, or reserved, or error . Do you have a different reference chart ?

[hank315]

There's a difference between MPEG1 and MPEG2 for the aspect ratio, here is some more info about it.

[poisondeathray]

There's a difference between MPEG1 and MPEG2 for the aspect ratio, here is some more info about it.

Thanks!

[hello_hello]

So if MediaInfo is reading the PAR info and getting it right with a 1.92:1 DAR, which it seems to be, why is the general consensus for software players to claim it's 1.96? I don't understand how that DAR is calculated. Maybe I'm just being dense.

I'm also curious regarding my posts #14 and #15 and why the same media player (MPC-HC) would change it's mind about the aspect ratio according to the splitter or decoder being used? Is the splitter responsible for interpreting the aspect ratio information, or passing it along correctly etc?

[jagabo]

why is the general consensus for software players to claim it's 1.96?

The players are using the standard PAL 704x576 MPEG 4:3 DAR pixel aspect ratio of 12:11, but using the full 720 frame width in their calculation:

720 / 400 * 12 / 11 ~= 1.96

It's a jungle out there with MPEG aspect ratios.

I don't understand how that DAR is calculated.

DAR = FAR * PAR

DAR = display aspect ratio
FAR = frame size aspect ratio
PAR = pixel aspect ratio

I'm also curious regarding my posts #14 and #15 and why the same media player (MPC-HC) would change it's mind about the aspect ratio according to the splitter or decoder being used? Is the splitter responsible for interpreting the aspect ratio information, or passing it along correctly etc?

Yes, each filter along the way must pass on AR information.

[hello_hello]

Thanks, although when I said I didn't understand how the aspect ratio was calculated, I just meant I didn't understand where the pixel aspect ratio was coming from.

Maybe the developers of software players don't think it's worth teaching them to read mpeg1 PARs properly because it's not all that common now, and so they assume the standard mpeg PARs instead?

Whatever the reason, it seems MediaInfo was getting it right.

[jagabo]

Thanks, although when I said I didn't understand how the aspect ratio was calculated, I just meant I didn't understand where the pixel aspect ratio was coming from.

With analog video capture they come from the ITU.601 spec (AKA BT.601). With DVDs you aren't given a pixel aspect ratio, only the frame size and the display aspect ratio. Officially, you derive the pixel aspect ratio with PAR = DAR / FAR. The problem is that DVDs made from analog video tapes are usually captured via the 601 spec and written directly to DVD, ignoring the ~2 percent difference between the two specs. So some software assumes DVD PAR, some ITU PAR.