Aspect ratios: 720 (not 704) x 576 = 16:9 ?

[2Bdecided]

There's a relevant sticky in the DV forum, but this discussion is probably better here...


The FAQs (and ITU specs!) say ~704x576 (arguably 575) is the active display, equal to the full 4:3 or 16:9 image - the rest (up to 720) is "extra" to allow for digital sampling. You can see the ~8 pixel black bars on many older recordings.

So far so good. However, I've been looking at various content that's created in HD, and downconverted to SD for broadcast or sale. As we know, HD is usually square pixel (1920x1080 or 1280x720) or 1.33 anamorphic (1440x1080), but it never has those "extra" pixels either side - there is no accommodation in HD systems for content beyond 16:9.

That means HD content "correctly" converted to 720-pixel-wide SD should have neat 8 pixel borders down either side. It doesn't. As far as I can tell, no one does it that way. Those extra pixels contain picture information that, if the conversion was "correct", could not have existed in the original HD image.

So, are they expanding the image slightly to fill those pixels, and cropping the top and bottom to keep the "correct" aspect ratio? I don't think so.

The only conclusion I can come to is that the broadcast world is simply resampling 1920x1080 to 720x576, and not giving a damn about the aspect ratio. Therefore, 720x576 = 16:9, and 704x576 is actually slightly less wide and not used.

If anyone can shed any light on this, I'd be interested.


There are people on these forums who worry about 704 vs 720 and the possible aspect ratio error introduced by "incorrect" methods. It seems to me that the professional world doesn't care, and software that displays 720x576 as 16:9 is probably displaying HD-sourced content correctly - two wrongs do make a right! Whereas people who carefully crop to HD-sourced content to 704x576 and resize it to 1024x576 (i.e. "correctly") are getting the wrong aspect ratio as a result.

Cheers,
David.

[Wilbert]

That means HD content "correctly" converted to 720-pixel-wide SD should have neat 8 pixel borders down either side.
No, why? When leaving your DV at 720x576 or converting your HD to 720x576, you just use a different PAR in your encoder.

Btw, it might very well be that DVDs or DVs don't following ITU, but we don't have much evidence one way or another.

[SeeMoreDigital]

Since the birth of DVD you've been able to find the odd few movies that have had the "image" encoded to all 720 width-ways pixels.

Nowadays most DVD's (labelled as being wide-screen anamorphic) have their "images" encoded using all 720 width-ways pixels, rather than just 704 width-ways pixels.

For all those people who like to play/view their DVD's using their PC's/monitors, I guess it's preferable not having to see vertical black bands to the left and right of the displayed image.

However, when the same DVD's are spun in a stand-alone player and viewed on a TV (connected via composite/S-video/component), some of the image will of-course be lost to over-scan. Unless you have a DVD player (or TV) that has an option to eliminate over-scan ;)

Either-way, there'll always be those who'll bring up the "is the circle still a circle" debate.... For me though, the difference is so slight it's not worth bothering about.

[Wilbert]

Nowadays most DVD's (labelled as being wide-screen anamorphic) have their "images" encoded using all 720 width-ways pixels
Ok, but the question is whether that part of the image (the stuff outside the 704 part) is a part of the 4:3/16:9 image.

[SeeMoreDigital]

Ok, but the question is whether that part of the image (the stuff outside the 704 part) is a part of the 4:3/16:9 image.Well... my personal point of view is, since it's there it must be!

I guess another thing to consider is. All commercial DVD's are authored at a resolution of 720x480/576 pixels (regardless of whether the stuff outside the 704 part is to be considered part of the 4:3/16:9 image). They are not authored at a resolution of 704x480/576 pixels. Even though the DVD spec allows this resolution.

[smok3]

what is the aspect ratio error if you go to 720 (without cropping)?
edit: eh, right, you don't have to do any cropping, you can just encode straight to 704*576.

[niknik]

And then it would take us to the anamorphic debate SeeMore has in his sig links. :)

(btw, is that link still working? the other day I tried to show it to a friend and it didn't work - and today's the same)

[SeeMoreDigital]

(btw, is that link still working? the other day I tried to show it to a friend and it didn't work - and today's the same)Sorry no, not at the moment.

I'm in the middle of building myself a new home media server, which will also store my web site ;)

[Mug Funky]

this is a tricky one... i might have to do some tests if i get the equipment to myself for long enough.

i know HDCAM or HDCAM SR decks will downscale and use the full 720 width, but i've not checked to see if they crop the top and bottom to accomodate. my guess is they don't.

as far as SD DVDs having a correct aspect ratio and also using full width, this is definitely possible on film transfers - aspect ratio is set up on the telecine by running a film loop with a test pattern through it - with a big circle in the middle. this is then matched to an electronically generated circle in the monitoring chain. this means the pixel aspect is correct no matter what the actual width of the picture is, as there's plenty of room on film to zoom in slightly.

but then... i couldn't say if the 16:9 or 4:3 circle that's generated actually corresponds to 704 or 720...

[2Bdecided]

At the end of the day, all "standards" must be treated with caution, but one part of the MPEG-2 standard is very clear (even though many here may consider it wrong!)...

MPEG-2 aspect_ratio_information Codewords:
0001 = source aspect ratio 1:1
0100 = display aspect ratio 4:3
0011 = display aspect ratio 16:9
0100 = display aspect ratio 2.21:1
all other values forbidden

For all streams without the optional sequence_display_extension, that's it. Unless it's 1:1, the pixels in the stream should be stretched to fit one of those 3 displays. MPEG-2 says nothing more on the matter.

That implies that either 704x576 or 720x576 are equally valid for 16:9 (or 4:3)! This can't work in reality, since TVs and DVD players don' resample 720 to fit in the space of 704, or 704 to fit in the space of 720 - though some PC software does (apparently).

So some software follows the standard, but the standard is wrong ;) .



FWIW I think this is slightly wrong too...

http://lipas.uwasa.fi/~f76998/video/conversion/

He discards the two half lines too quickly. In the "real" analogue days, the 4:3 raster would have been what we now call 702x575 exactly. Rounding it up to 576 and saying that's 4:3 is wrong. If we're going to be as picky as Jukka Aho, 702x576 is not the definition of 4:3.

If we take 702x575 (instead of 576) as defining 4x3, the following comes out when we try to use that with full lines, whole pixels, and preferably mod 16 values...

704x576 is used because it's convenient, it gives us digital pixels to light up all the analogue pixels, and saying it's 4:3 is only a 0.1% aspect ratio error (less than one pixel!).

702x576 has almost the same magnitude error (less than one pixel), in the other direction, and would be equally fine if it was mod 16. Since it's not, it's rarely used.

703x576 is only 0.03% wrong (much less than one pixel!), but isn't even mod 2 ;) .


The idea that 768x576 isn't square pixel is not really fair either. It's only wrong because we can't have 1/3rd pixels! 767x575 is the "real" 4:3 square pixel, a mere 0.04% (1/3rd of a pixel) away from ideal when using the original 14.75MHz sample rate.

768x576 is the nearest useable resolution. If sampled in the original 14.75MHz sampling rate, it also has that 0.04% error. Today, it's much more often used by a simple horizontal re-size to/from one of the 702, 704 or 720 formats, and assuming 768 = true square pixel - in which case, it has (only) the aspect ratio error of whichever (702, 704, or 720) is the source/target, and no error of its own.


Put simply, if you handle the half-lines properly in the calculations, then all the "aspect ratio errors" in 625-line (576-line) video are less than one pixel. I think a "dirty little secret" of less than one pixel is not worth worrying about!


What I started this thread with is an aspect ratio error of 16 pixels (2.2%!). The industry doesn't even seem to care about that, but I'd be interested if you could figure out what the pro equipment does Mug Funky.

Cheers,
David.

[2Bdecided]

stunned silence?

I'm sure most people find this boring, but if anyone "gets" it, I'd love to know what's really happening.

Cheers,
David.

[niknik]

stunned silence?

I'm sure most people find this boring, but if anyone "gets" it, I'd love to know what's really happening.

Cheers,
David.

I find it interesting, but am not "expert" enough to answer you. :)

[smok3]

well, 2% is not really a small error, it is hardly noticebale, but can be annoying, especially if it is a footage that you know well, also this error may get larger when converting to something else...

[niknik]

Bad IVTC, de-interlace, and a lot other issues are a lot more annoying than a 2% AR adjustment. ;)

[J_Darnley]

I get that aspect ratios are a horrible mess and that everything should be square pixel. But until everything is I will continue to use the generic pixel aspect ratio reported by ffdshow to resize/signal my videos. It reports 16:15 or 64:45 for my ripped vobs so I use those to either resize to 1:1 or signal my videos with those ratios.

I think I would probably only know that AR was slightly wrong if I had a black on white circle to look at. The only times when I do notice is if I flag a video incorrectly or if my digital TV channel is flagged incorrectly. Nat Geo is appalling for that.

I also agree niknik's comment about interlacing being worse than a small AR error. Living in a PAL country, field blending is my biggest problem rather than bad IVTC. Maybe the former is a symptom of the latter.

[SeeMoreDigital]

I get that aspect ratios are a horrible mess and that everything should be square pixel. But until everything is I will continue to use the generic pixel aspect ratio reported by ffdshow to resize/signal my videos. It reports 16:15 or 64:45 for my ripped vobs so I use those to either resize to 1:1 or signal my videos with those ratios.Something that must be pointed out here is...

When playing the same "non-square" pixel MPEG-2 DVD source.... Software player/computer monitor combinations do not display the image in the same way as stand-alone player/TV combinations!


Cheers

[2Bdecided]

One BBC page simply quotes the pixel aspect ratio, and works it all out from there...

http://www.bbc.co.uk/commissioning/tvbranding/picturesize.shtml

...starting from 576 lines high. 702 is the limit of the 16x9 image, 720 is definitively beyond it.

Whether people stick to these measurements is a different thing. It would be interesting to compare an HD programme simulcast on BBC One and BBC HD.

Cheers,
David.

[2Bdecided]

from here:
http://forum.doom9.org/showthread.php?t=136071

I still think that's a "brave" thing to put in your .sig. You should at least mention that you're assuming 720 pixels define the aspect ratio, which is against the ITU specs and against all standard video sampling frequencies (i.e. multiples of 13.5MHz).

http://forum.doom9.org/showthread.php?t=132378I did have a whole rant typed but then I decided I would not de-rail the thread. Basically, I don't care about analogue relics.What's with the "analogue relics"? Digital video has the number of lines it has, the resolution it has, the pixel aspect ratio it has, and (often) the interlace it has because it's a digital version of a pre-existing analogue standard.

Choose to ignore that standard if you want, but you're not being clever - you're just being wrong.


It seems many DVDs are also "wrong" - in my book, that does define a new "informal" standard - in this case, I have no problem with following it. However, I don't think it's wise to advise people to encode all their video in this way - even if it does mean everyone in your home movies magically becomes 2% thinner! ;)


I'd like to use non-interlaced 1:1 pixel aspect ratio sRGB (maybe) images all the time, but when the source takes its parameters from an "analogue relic", you have to work (correctly) with what you've got!


If you really want to discuss, you can PM me.I hope this will do. No chance of derailing the original thread.

Cheers,
David.

[smok3]

here is a nice test pattern, if somebody is up for practical testing;
http://somestuff.org/downloads/resizeCalc_php/test_pat/

the game would be: author different dvds ('4:3', '16:9') and see how they behave on different hardware devices, software players.

p.s. added some dvd isos (720 versions are wrong (pretty damn very wrong) when VLC, mpc or mpui were used for playback - most likely my resizing method is simplified a bit 2 much)

[SeeMoreDigital]

...the game would be: author different dvds ('4:3', '16:9') and see how they behave on different hardware devices, software players. I did this myself around 3 years ago to check to see if MPEG-2 sources and MPEG-4 encodes were displayed at the same shape, when the same level of aspect ratio signalling was applied..... Needless to say they were.

I used the same samples as a benchmark when setting-up and testing the Ziova branded hardware players ;)

[smok3]

SeeMoreDigital, don't want to be a bi***, but really your post will save the world :P

[SeeMoreDigital]

Hmmm...

As I now have a couple of dozen MPEG-2/4 hardware playback devices (some bought, most sent to me for testing by various manufacturers), I thought my post might save you and others on the forum some time.....

I guess not then!

[smok3]

posting some numbers/correct metods would be great.

[SeeMoreDigital]

posting some numbers/correct metods would be great.I've already mentioned how I work out and generate anamorphic encodes in loads of posts on this forum...

[smok3]

the snapshot method?

[SeeMoreDigital]

the snapshot method?Indeed...

That's the method I use to acertain the original movie aspect ratio of the MPEG-2/DVD source. Prior to generating a cropped and resized anamorphic MPEG-4 encode.

[smok3]

but you do realize that 'putsomenamehere' player may have built-in certain 'non-standard' behavior?

[SeeMoreDigital]

but you do realize that 'putsomenamehere' player may have built-in certain 'non-standard' behavior?Are you able to be more specific about what you mean by "non standard" behaviour?

[smok3]

you are bringing at least 2 unknown variables into equation with the usage of the xy player:
a. - unknown resizing method, maybe not valid, who knows
b. - unknown monitor PAR conformation

[SeeMoreDigital]

What do you mean by an "unknown resizing method"?

As for "unknown monitor PAR confirmation"... I fail to see the significance.