Why do mplayer/VLC/MPC-HC/WMP12 still have wrong aspect-ratio with DVDs?

[shh]

Hello!
I just recognized, that mplayer, VLC, MediaPlayerClassic-HC and also WMP 12 still scale my DVD-VOBs wrong on my PC-screen.

I've got several DVDs which are 720x576 anamorphic (16:9).
PAR or SAR should be 128/117*4/3
http://lipas.uwasa.fi/~f76998/video/conversion/
or as a rounded interpretation since MPEG4: 16/11
http://en.wikipedia.org/wiki/Pixel_aspect_ratio

To my understanding the DVD should be played at 1047x576, or perhaps 1050x576, but all four software-players scale to 1024x576. WHY? :confused:
- WMP12 uses the internal MPEG2-filters of Win7
- MPC-HC uses an actual ffdshow-version
- VLC 1.05 uses ... (internal MPEG2-decoder?)
- mplayer rc1 uses ... (internal MPEG2-decoder?)

I can't believe that after 10 years the scaling is still wrong, so maybe you can point out my error. :p

[setarip_old]

HI!

Perhaps they all require resolution factors of MOD16 for proper playback...

[Keiyakusha]

1024x576 is a right resolution. It's not like "they still have wrong", its more like no one cares about those specs. And not only players but the ones who authors dvd too. Reality is different.
There should be black borders to the left and to the right of the video so if you'll resize picture to ~1050 then actual picture will be 1024x576 excluding borders. But often there is no borders to begin with. ~2px doesn't counts.

[shh]

... its more like no one cares about those specs.

That's what I think, too.
But all my checked hardware-players do scale to about 1047x576:
- 2 DVD-Players [via SCART]
- internal TV-media-player
- Media Player Box (Labo-110) [via HDMI]

So, it's just the software-players, what do it wrong.
I can't believe the movie-makers just check with software-players and don't check if it looks correctly on TV (for what a DVD is actually created).

- SAR 16/11 is also recommended for encoding with x264
- Adobe says 12/11 (1,091) is the right PAR: Link (http://help.adobe.com/en_US/AfterEffects/9.0/WS3878526689cb91655866c1103906c6dea-7f3aa.html#WS082E922A-A5D7-4de1-9A0E-1EFC401EA6D1) (before, they had 16/15)
- Lurker's guide (http://lurkertech.com/lg/pixelaspect/)
...
All guides I find recommend 12/11 or 16/11, and hardware-players do use that aspect-ratio anyway. I understand, that some companies are too lazy to change something.
But even open-source players with active development should have recognized, that their players don't scale as the hardware-players do. :rolleyes:

[Ghitulescu]

Hello!
I just recognized, that mplayer, VLC, MediaPlayerClassic-HC and also WMP 12 still scale my DVD-VOBs wrong on my PC-screen.
To my understanding the DVD should be played at 1047x576, or perhaps 1050x576, but all four software-players scale to 1024x576. WHY?
Because 1024x576 is 1.78:1, you have quadratic pixels on your PC.
I can't believe the movie-makers just check with software-players and don't check if it looks correctly on TV (for what a DVD is actually created).
For what I know, they don't test it on software players, but they run the result through certain "conformity checkers" (like Eclipse), it's the mastering facilities that test the test DVDs against a series of SAP DVD players (it's just optional, an extra convenience, as long as eg Eclipse said OK it should be OK).
It's the responsability of both software and hardware manufacturers to ensure the compatibility of their products with the specs.

So when the DVD authoring/mastering guys manufacture a DVD according to the specs, and the DVD makers do the same for their products, then the combination should work - this is how a standard works.

[shh]

Indeed 1024x576 is 1.78:1 (=16:9), but the MPEG is coded with non-square pixels and it's questionable how to decode that back to square-pixels.

I just notice, that the MPEG2-specs talk about a display-aspect-ratio (DAR) in the sequence-header, so a 720x576-16:9 MPEG should be scaled to 1024x576.
But:
- My PAL-TV (tube) doesn't do this: DVB-streams via RGB are stretched to ~1047x576 (hardware-MPEG2-decoder on DVB-card)
- My DVD-Player stretches 720x576 to ~1047x576
- 704x576 and 720x576 are treated with the same sample-aspect-ratio (SAR), not DAR, so they're scaled by the same factor, not to the same destination size.
- 720x576 DV-AVIs are Rec.601, with coded PAL-SAR. Correct display-size is ~786x576. Proof (http://shildebrand.de/other/cap.avi)
- if DAR is correct, the recommended 12/11 and 16/11 SAR for x264 is wrong

I still must check all formats on my new FullHD-TV. Maybe it's doing something else, because it has to up-scale nearly all sources.
Maybe some hardware-designers already noticed, that the MPEG2-specs talk about a display-aspect-ratio.
But the label "display-aspect-ratio" in the MPEG2-spects is strange anyway: Why did they standardize 704x576 and 720x576 picture-sizes which would have different sample-sizes, if playback-size is const display (e.g. 768x576 for non-anamorphic 4:3)? Different SARs never existed on hardware for 576i50.

[TinTime]

I agree with you - I don't know why software players scale SD MPEG-2 incorrectly but they all seem to.

Perhaps it is just as has already been pointed out. Nobody cares enough to correct it.

I've even tried muxing MPEG-2 streams to MKV and setting the correct DAR at container level (20x11 for PAL 16x9 material) but it doesn't seem to make any difference. I thought container level aspect ratio trumped stream level but perhaps I'm wrong.

[Ghitulescu]

Indeed 1024x576 is 1.78:1 (=16:9), but the MPEG is coded with non-square pixels and it's questionable how to decode that back to square-pixels.

I just notice, that the MPEG2-specs talk about a display-aspect-ratio (DAR) in the sequence-header, so a 720x576-16:9 MPEG should be scaled to 1024x576.
But:
- My PAL-TV (tube) doesn't do this: DVB-streams via RGB are stretched to ~1047x576 (hardware-MPEG2-decoder on DVB-card)
- My DVD-Player stretches 720x576 to ~1047x576
- 704x576 and 720x576 are treated with the same sample-aspect-ratio (SAR), not DAR, so they're scaled by the same factor, not to the same destination size.
- 720x576 DV-AVIs are Rec.601, with coded PAL-SAR. Correct display-size is ~786x576. Proof (http://shildebrand.de/other/cap.avi)
- if DAR is correct, the recommended 12/11 and 16/11 SAR for x264 is wrong

I still must check all formats on my new FullHD-TV. Maybe it's doing something else, because it has to up-scale nearly all sources.
Maybe some hardware-designers already noticed, that the MPEG2-specs talk about a display-aspect-ratio.
But the label "display-aspect-ratio" in the MPEG2-spects is strange anyway: Why did they standardize 704x576 and 720x576 picture-sizes which would have different sample-sizes, if playback-size is const display (e.g. 768x576 for non-anamorphic 4:3)? Different SARs never existed on hardware for 576i50.

So you managed finally to find out what DAR is. You should have started first learning this, my mistake, I thought you know already what DAR is and how it's used.

How can you count the pixels on a PAL TV? Precisely when the PAL standard does not talk about pixels, well it says something about the samples, but all this is just timing ....

You'd be surprised but the PAL analog signals are absolutely perfect in displaying the image as it should be (for NTSC it's again a different story).

And finally, when you talk about pixels and PC you talk about a PAR=1. Don't mix the things up. If a software player gets confused (or its programmers ;)) it's their problem. The algorithm for PC is so simple yet many programmers (and users) are confused.

PS: the MPEG standards call SAR storage aspect ratio for what I know.

[nurbs]

PS: the MPEG standards call SAR storage aspect ratio for what I know.
I think you are mistaken. http://forum.doom9.org/showpost.php?p=1365378&postcount=35

[shh]

Ghitulescu> So you managed finally to find out what DAR is. You should have started first learning this, my mistake...

This is funny! :)
I'm encoding MPEG over 11 years now (and also have the specs for that time) and have wrote several tools that especially deal with correct DAR/SAR/PAR.
I just posted this here in "Newbies", because I've been absent for some time and may have overseen something concrete.

These MPEG2-specs exist for a long time, but there never was a display_aspect_ratio implemented on some hardware. That's the point why all of those guides rely on Rec.601 video with a const SAR, not DAR (and also recommend coding a sample-aspect-ratio according to Rec.601).
We already had the problem as DVDs came out and only a few computers were capable to playback a DVD without any jerking. That time hardware-YUV-scaler just came up, but also scaled to 1024x576 (as hardware-player showed a wider image). But probably just to save CPU-time (17" tubes @1024x768 were common, and additional vertical scaling for a correct aspect ratio may have cost too much CPU-time for the software-decoders)

> How can you count the pixels on a PAL TV? Precisely when the PAL standard does not talk about pixels, well it says something about the samples, but all this is just timing ....

I can measure my MPEGs how they are played back on my TV. You too. :) It's accurate enough to tell if I got a 1047 or 1024 resolution.
I already gave the link to http://lipas.uwasa.fi/~f76998/video/conversion/ what talks about sample-timings. I chose a display-size-talking, because I thought that's "translated" sample-timings which everyone could cope with. I can also talk about sample-width in µsec if you like that more.

> You'd be surprised but the PAL analog signals are absolutely perfect in displaying the image as it should be (for NTSC it's again a different story).

I'm sorry, but that sentence is telling nothing. What do you mean with "should be"?
Of course "PAL analog signals are absolutely perfect", but that doesn't tell anything of the MPEG2-decoding, aspect-ratio flag interpretation, scaling of hardware-players that show a PAL picture. I already pointed out, that there are severe differences in interpreting the aspect-ratio flag.
How do you proof your "absolute perfect picture"?

Summing it up again:
Hardware-player conform to Rec.601 and don't do any display-aspect-ratio. They decode using a const sample-aspect ratio for 704x576, 720x576 and the same SAR*4/3 for anamorphic 720x576.
But the software players still like a DAR for the MPEGs. Why? Just to be correct, also when all others do something else? :confused:
Also, why should I transcode my MPEGs to H.264 with SAR12/11 or 16/11? If I pull a VOB in MKVMerge it shows me display-aspect of 1024x576. Why would 16/11 be correct for this?? :rolleyes:

[Ghitulescu]

Ghitulescu> So you managed finally to find out what DAR is. You should have started first learning this, my mistake...

This is funny! :)
I'm encoding MPEG over 11 years now (and also have the specs for that time) and have wrote several tools that especially deal with correct DAR/SAR/PAR.
I just posted this here in "Newbies", because I've been absent for some time and may have overseen something concrete.

Sorry, I missunderstood your real point, it was not very nice of me.

The PAR for any PC was and still is 1:1 (with the notable exception of EGA). You have an aspect ratio of X:Y and a frame size of AxB. To display a correct image (as it was supposed to be displayed) in such a simple coordinate system you'll end with these values (768 or 1024 for PAL), irrespective of 720 or 704 or more like analog PAL samples 702 (maximum distinct points). The job of a MPEG-2 player programmer is not to resize the horizantal value to 1024/768, but to make sure the image will look as intended.
These MPEG2-specs exist for a long time, but there never was a display_aspect_ratio implemented on some hardware. That's the point why all of those guides rely on Rec.601 video with a const SAR, not DAR (and also recommend coding a sample-aspect-ratio according to Rec.601).
We already had the problem as DVDs came out and only a few computers were capable to playback a DVD without any jerking. That time hardware-YUV-scaler just came up, but also scaled to 1024x576 (as hardware-player showed a wider image). But probably just to save CPU-time (17" tubes @1024x768 were common, and additional vertical scaling for a correct aspect ratio may have cost too much CPU-time for the software-decoders)
MPEG-2 standards evolved the same way it does today. Besides a recomandation has not the legal force a standard has.
> How can you count the pixels on a PAL TV? Precisely when the PAL standard does not talk about pixels, well it says something about the samples, but all this is just timing ....

I can measure my MPEGs how they are played back on my TV. You too. :) It's accurate enough to tell if I got a 1047 or 1024 resolution.

If your TV is PAL, it won't go beyond the maximum of 702 samples per line (or a max. 13.5 MHz). A sample is not a pixel, it's the place one measures a value. Most people confound the resolution with pixels. Amiga outputs (NTSC) 640 pixels but the samples are still ~711, because it's NTSC. It's like converting CD (44.1) to DAT (48) using the analog way, you simply put more markers where you test the values (which are now samples). So you actually measure what outputs your HW player to your TV (Kell-factor it's beyond the discussion).

I already gave the link to http://lipas.uwasa.fi/~f76998/video/conversion/ what talks about sample-timings. I chose a display-size-talking, because I thought that's "translated" sample-timings which everyone could cope with. I can also talk about sample-width in µsec if you like that more.
I knew that for long. The only problem is the interfacing of digital with analog devices, as the only "digital" aspect of the PAL/SECAM/NTSC is the number of scanlines, which is fixed. The same goes for fps.
> You'd be surprised but the PAL analog signals are absolutely perfect in displaying the image as it should be (for NTSC it's again a different story).

I'm sorry, but that sentence is telling nothing. What do you mean with "should be"?

The TV image should represent the world as we see it. And the human eye has the coordinates system corresponding to a PAR of 1:1. It simply doesn't matter how many pixels are on a particular scanline, the image, geometrically, as displayed should have PAR=1, otherwise the human viewer notices that is something wrong.
The 4:3 format came from cinema - and is measured in meter, feet, miles, lightyears whatever, the same unit on both heigth and width, ie PAR=1. All the TV systems were designed to reproduce a PAR=1, since that was normal and naturally. We are not here at Magic Mirrors at circus or fairs. It doesn't matter what kind of signal it receives. The displayed image should be a copy of reality, and the reality is 1:1.
A VHS in LP (considered to represent some 200-220 lines) displays exactly the same image as a S-VHS (considered to have 400+ lines) concerning the geometry, however the details differ greatly. Even if the VHS-LP yields an image having ca. 250x576 [useful] pixels while the S-VHS yields the same image but having ca. 500 pixels, the image should have in computer 768x576 pixels, 250/500 -> 768 being done either in analog domain (768 samples during aquisition) or in digital (720 samples during aquisition or whatever the capture window is, then using DAR/PAR/SAR to upscale to 768). It's like an ink-jet printer that has 1200x600dpi but still prints according to PAR=1.


Of course "PAL analog signals are absolutely perfect", but that doesn't tell anything of the MPEG2-decoding, aspect-ratio flag interpretation, scaling of hardware-players that show a PAL picture. I already pointed out, that there are severe differences in interpreting the aspect-ratio flag.

We agree however that some HW solutions are far from ideal. Which is why HDTV came to PAR=1 (yes, yes, HDV was an intermediate solution, too much money involved).


Summing it up again:
Hardware-player conform to Rec.601 and don't do any display-aspect-ratio. They decode using a const sample-aspect ratio for 704x576, 720x576 and the same SAR*4/3 for anamorphic 720x576.
But the software players still like a DAR for the MPEGs. Why? Just to be correct, also when all others do something else? :confused:
Also, why should I transcode my MPEGs to H.264 with SAR12/11 or 16/11? If I pull a VOB in MKVMerge it shows me display-aspect of 1024x576. Why would 16/11 be correct for this?? :rolleyes:
Yes, this is really the point, and I fully agree. However I still consider the display intent (analog TV, HDTV TV, PC and the player) as determining what reencoding PAR/SAR/DAR are needed - but only in theory, because I don't do transcoding for PC (be it music, video, whatever).

[TinTime]

@shh

I've now found a partial solution to this problem - see this thread (http://forum.doom9.org/showthread.php?t=156329).

Doesn't help with DVD playback but at least I can now get correct aspect ratios (i.e. the ones I choose) after remuxing to mkv.

[TinTime]

And I've now got a full solution using ffdshow. In the AVISynth filter section in ffdshow add the following code:
ffdshow_setSAR(ffdshow_sar_x * 45, ffdshow_sar_y * 44)
crop(8, 0, -8, -0)
NB This is for SD video. This would need to be skipped for HD.