More mp4 aspect ratio woes (MeGUI/x264)

[charleski]

Is anyone able to give a clear guide of how aspect ratio works in mp4? I'm thoroughly confused.

Let me provide an example. I'm currently working on moving over to doing h.264 encodings instead of using xvid. One of my aims in this has been to avoid resizing so it's the correct AR at a 1:1 ratio which obviously loses a lot of resolution. My input consists of ~4Mbps MPEG2 streams from a Hauppage terrestial digital receiver (annoyingly b0rked - I wasted a lot of time on sync issues until I remembered that de/remuxing is a must, grr). The input is 16:9 and flagged as such, DGdecode recognises this and the d2v file reflects it.

Now, if I specify a SAR of 16x9 in MeGUI when encoding the video ends up playing at an aspect ratio of ~2.35:1 (hmm, that's 1.33*16:9). If I specify an AR of 1:1 the video plays without any anamorphic sqeezing (I've tested this with a few different players - Nero Showtime, vlc, bsplayer etc [using ffdshow for decoding]) . In order to get the encoded AVC mp4 file to play back at the correct 16:9 AR without doing any manipulation in the player I have to specify a SAR of 14:10 in MeGUI (which, I know, is just a front-end for x264).

So I've found a solution, but why? I don't think this is limited to x264, as I noticed similar weirdness when altering the AR of encodes made using Nero Recode (I've since moved to using MeGUI/x264 - MUCH faster and more transparent). It looks like the player is deriving the final AR from a mixture of the SAR signalled in the mp4 AVCc atom and something else, what else is it? I should add that all these encodes have been ca 704x520, so some extra squashing is clearly going on.

[stephanV]

SAR is not DAR.

This question has come up before.

[charleski]

Are you referring to this (http://forum.doom9.org/showthread.php?p=728960&highlight=DAR#post728960) ?

Well ok, if DAR=SARxPAR, then why does it come out wrong when SAR=1:1 and PAR (signalled in the input MPEG2 video stream) is 16:9? This is what needs to be cleared up.

[Edit]Hmm, ok, did a few more calculations. So you're saying that the MPEG2 signal just doesn't play any role? You have an absolute pixel aspect ratio of ~1.3 and the player just multiplies that by the SAR. OK, that would account for what I've seen. Damn confusing though!

[stephanV]

*sigh* (those posts should be deleted)

Because DAR is not SAR*PAR, SAR is not storage aspect ratio, but sample aspect ratio and therefor equal to PAR, and what is signaled in the MPEG video stream (16:9) is not PAR but DAR. So basically you got just about every value wrong and thus not surprisingly a wrong result.

Check the x264 sticky in the h264 forum for correct information, in the FAQ there SAR is being discussed.

[charleski]

Ah, you're referring to this (http://forum.doom9.org/showthread.php?t=100519).

Which would accord with what I worked out in my edit (probably while you were posting the reply). So basically you should forget about any signal in the input steam as it will be discarded. All that matters is the actual width/height pixel ratios of the input stream, which will be multiplied by the value set as SAR in the mp4 to produce the final display aspect ratio.

Ok, that makes sense now, though I still think the term SAR is damn confusing! It should be Aspect Ratio Multiplier or something like that.

[stephanV]

[Edit]Hmm, ok, did a few more calculations. So you're saying that the MPEG2 signal just doesn't play any role? You have an absolute pixel aspect ratio of ~1.3 and the player just multiplies that by the SAR. OK, that would account for what I've seen. Damn confusing though!

The MPEG2 signal is what you want to achieve, its the DAR, so it shouldn't be discarded cause you need it to calculate the SAR.

The term sample aspect ratio is correct as it describes the aspect ratio of one sample, AKA pixel. Not confusing at all.

[charleski]

The MPEG2 signal is what you want to achieve, its the DAR, so it shouldn't be discarded cause you need it to calculate the SAR.Yeah, but it's discarded by the encoder, right? The encoder just sees the actual pixels and doesn't take into account what DAR is signalled. The MPEG2 DAR signal is just there for reference so you know what DAR you should aim at.

The term sample aspect ratio is correct as it describes the aspect ratio of one sample, AKA pixel. Not confusing at all.In a strict engineering sense, yes... But what you're actually dealing with here is a multiplier that's applied to the actual pixels which has only an indirect relationship to the result you want to achieve. The SAR is not an aspect ratio at all, it's merely a multiplier.

I suppose if you've been dealing with the oddities of mp4 encoding for a while this is all perfectly obvious, but for me it wasn't, even after rooting around in the forums. I suppose these are things that need to be spelt out. I'd offer to help write the guides, only I clearly don't know what's going on :) .

Anyway, thanks for bearing with me on this, the discussion helped me work out what my misconceptions were.

[stephanV]

Yeah, but it's discarded by the encoder, right? The encoder just sees the actual pixels and doesn't take into account what DAR is signalled.
This is true yes.

In a strict engineering sense, yes... But what you're actually dealing with here is a multiplier that's applied to the actual pixels which has only an indirect relationship to the result you want to achieve. The SAR is not an aspect ratio at all, it's merely a multiplier.
No, SAR is the aspect ratio of a pixel. Not just a multiplier, but the actual aspect ratio. You see it as a multiplier because a PC screen only has square pixels, so instead of using the correct pixel shape, the frame dimensions are adjusted to correct for differences in AR.

[SeeMoreDigital]

Well ok, if DAR=SARxPAR, then why does it come out wrong when SAR=1:1 and PAR (signalled in the input MPEG2 video stream) is 16:9? This is what needs to be cleared up. There's nothing wrong using the above mentioned formula to calculate DAR ratios....

The thing that seems to piss most people off is the use of the "SAR" acronym because the MPEG-4 specs refer to this as meaning Sample Aspect Ratio (and not "Storage Aspect Ratio). So with this in mind I guess what we need is an alternate acronym for SAR?

So how about, "SHV" (Source Height Width)... And for those who have just dosed off..... it could be incorporated into a formula as follows: -

SHV x PAR = DAR.....or even, SHV x SAR = DAR


That should give the purits something else to argue about :)


Cheers

[charleski]

No, SAR is the aspect ratio of a pixel. Not just a multiplier, but the actual aspect ratio. You see it as a multiplier because a PC screen only has square pixels, so instead of using the correct pixel shape, the frame dimensions are adjusted to correct for differences in AR.Well the point I'm making is that it's far more intuitive and useful to regard the SAR value as a multiplier which the player applies while constructing the video frame to be output. Obviously PC displays under certain circumstances can have pixels that are not square and the SAR would need to be altered to provide correct playback under those conditions (though it makes sense to standardise on a pixel ratio of 1:1 and then add in a further multiplier in the player to handle special circumstances).

To state it more explicitly: a) you have a video stream with certain fixed xy dimensions, b) you know the aspect ratio at which you want it displayed (DAR), what you need to know is how to get from a) to b), and you do that by deriving a multiplier that will do the job for you so that DAR=SAR*x/y.

It's just a more effective way of thinking about it than worrying about the aspect ratio of the device used to transduce the original photons into RGB samples:), though the two may be intimately related.

[Sharktooth]

I wonder why ppl doesn't read the FAQs....
Q17 on the sticky thread: http://forum.doom9.org/showthread.php?p=696689#post696689

[SeeMoreDigital]

Reading between the lines here.... I think what some of our forum members might like is a reliable method of altering the aspect ratio of their encodes after they've been encoded.

I think there may be many people around here who have spent hours generating cropped and resized encodes, only to find the aspect ratio is either way off (or a bit off) upon playback :scared:

All of which can be corrected by calculating and applying the appropriate level of aspect ratio signalling ;)


Cheers

[charleski]

I wonder why ppl doesn't read the FAQs....
Q17 on the sticky thread: http://forum.doom9.org/showthread.php?p=696689#post696689
With respect, Sharktooth, although perfectly correct, the explanation given in the FAQ isn't really the most intuitive. I certainly did read through all the posts I could find before starting the thread.

Reading between the lines here.... I think what some of our forum members might like is a reliable method of altering the aspect ratio of their encodes after they've been encoded.Well that's certainly how I started on it. hhanh's archange does seem to work as long as the AVCc atom has the structures that it expects. I'd love it to be able to insert those structures if they're missing, but I haven't been able to find any documentation on how the bit-fields in that part of the atom are laid-out (typing AVCc SAR into google gives you a lot of pages on the Australian Vice-Chancellors Committee :/ )

[SeeMoreDigital]

Well that's certainly how I started on it. hhanh's archange does seem to work as long as the AVCc atom has the structures that it expects. I'd love it to be able to insert those structures if they're missing, but I haven't been able to find any documentation on how the bit-fields in that part of the atom are laid-out (typing AVCc SAR into google gives you a lot of pages on the Australian Vice-Chancellors Committee :/ )You might be please to know that the newest version of YAMB (with MP4Box) now provides the ability to change the aspect ratio of MPEG-4/SP/ASP and AVC streams in MP4 ;)

[Elias]

You might be please to know that the newest version of YAMB (with MP4Box) now provides the ability to change the aspect ratio of MPEG-4/SP/ASP and AVC streams in MP4 ;)Now this is very nice! Is it done right, like the same as in XviD (before encoding) and MPEG4Modifier?

[SeeMoreDigital]

Now this is very nice! Is it done right, like the same is in XviD (before encoding) and MPEG4Modifier?Well an MPEG4 Modifier style tool for MP4 files would be the ultimate solution (ie: it's able to calculate the ratios for you).

The current situation with YAMB requires you to calculate the ratios yourself and enter them here: -

http://img495.imageshack.us/img495/1784/yamb8be.png

And I'm happy to report it works perfectly :)

[Elias]

That's okay, all you have to do is to encode a 2 second avi clip with the desired resolution/aspect ratio, and then open it in the latest beta of GSpot, it has a calculator for aspect ratios :) Where did you get this build of YAMB? I have the 1.3.1 version, and I haven't found any aspect ratio settings.

[SeeMoreDigital]

You can find the latest test build here: -

http://forum.doom9.org/showthread.php?p=733250#post733250


Cheers

[stephanV]

Well the point I'm making is that it's far more intuitive and useful to regard the SAR value as a multiplier which the player applies while constructing the video frame to be output.
The point I'm making is that you can derive from seeing SAR as aspect ratio that you need to use it as a multiplier, but you can't go the other way around. If the pixel shape is not 1:1 you will inherently get a screwed up picture if you see SAR just as a multiplier and don't know the true meaning. So just don't do it, you are only adding more confusion to something that's already heavily confused.

So with this in mind I guess what we need is an alternate acronym for SAR?
NO MORE ACRONYMS!!! :scared:


SAR = sample aspect ratio / screen aspect ratio / storage (?) aspect ratio
PAR = pixel aspect ratio / picture aspect ratio


The thing with acronyms is that, instead of looking up what they mean, people will guess what they mean.

What's wrong with spelling out words these days? :(

But if you must have one use FAR: frame aspect ratio.

[SeeMoreDigital]

....But if you must have one use FAR: frame aspect ratio.I was going to suggest FAR... but didn't think you'd go for it :D

But while we are on the subject how about: -

FPR = Frame Pixel Ratio
SPR = Source Pixel Ratio

.... And the list goes on!

[charleski]

The point I'm making is that you can derive from seeing SAR as aspect ratio that you need to use it as a multiplier, but you can't go the other way around. If the pixel shape is not 1:1 you will inherently get a screwed up picture if you see SAR just as a multiplier and don't know the true meaning. So just don't do it, you are only adding more confusion to something that's already heavily confused.Let me explain this more exhaustively. An aspect ratio is a measurement. You take your ruler and measure a physical rectilinear entity, then divide the width by the height. Thus the term Display Aspect Ratio makes sense: you can put a ruler on your screen and measure the dimensions of the image.

On the other hand, the notion of Pixel Aspect Ratio never made any sense to me. A pixel isn't a physical entity. It's a dimensionless point in a matrix. There's nothing to measure, and therefore no aspect ratio. BUT Sample Aspect Ratio does have a meaning: it's the aspect ratio of the area of the focal plane in the camera or telecine machine that was sampled to determine the RGB values of the resulting pixel (assuming that the lens system has circular symmetry and is rectilinear). Fair enough.

The problem comes when, many steps down the chain, someone is faced with solving the DAR=SAR*x/y equation. The number that you plug in for SAR here is NOT a measurement independent of the other terms. You have no idea what the particulars of the orginal sampling system were, and you don't really care. All you want to work out is how to deform the input video stream into something that looks as it 'should'.

That's why the notion of calling SAR an 'aspect ratio' is confusing and non-intuitive when applied in this context. It's not a measurement, therefore it's not an aspect ratio. The number that you derive by solving the equation definitely does bear a relationship to the original Sample Aspect Ratio, but this is indirect. Is that clear?

NO MORE ACRONYMS!!! :scared:Yeah, I assume the term 'SAR' is written into the MPEG4 specs somewhere? (I couldn't find the term on doing a search of mpeg.org or the MPEG Industry Forum websites.) While the terminology is imprecise it would just produce more confusion to try to change it at this stage.

But if you must have one use FAR: frame aspect ratio.Which would unfortunately be just as bad :).

[SeeMoreDigital]

Hi charleski,

At the end of the day, I'm sorry to say you're just banging your head against a brick wall. As I too have been down this road many times before!

I'm of the opinion that when some these ISO, MPEG-4, ITU etc specifications were written, nobody thought to check what existing abbreviations were in current use and more importantly what they stood for and so regurgitated the same abbreviations to mean something completely different :eek:

That said, irrespective of what the acronyms are supposed to mean (depending on the spec you read)....With the appropriate calculation it's possible to introduce anamorphic signalling to any old MPEG-4 encode and make it any DAR shape you like. Such as 4:3 (1.3333:1) or 16:9 (1.7777:1). Or even 1.85:1, 2.35:1, 2.40:1 etc, etc

What's needed though is a simple way of explaining this to people - using abbreviations that everyone can agree on :)

[stephanV]

Is that clear?
No.

You are obfuscating the term sample aspect ratio because you apply it to a specific case: square pixels on a PC screen. Well, in that case you could see it as a multiplier yes. But for screens that are not as flexible, commonly called ordinary TV's, SAR does not function as multiplier at all.

SAR is an aspect ratio because it defines the shape a sample should have for the video to be displayed properly. If a display does not have the correct sample shape, then something else needs to be done. This can mean just multipling the frame width with SAR, but it could also mean add letterboxing.