DME ResourcesI probably should’ve just dropped the mic after the last post, but we’re going to continue on. I’m not one for dropping names, and in this case I don’t have to either. Everyone has gotten this wrong at some point, and I mean everyone. The people working on related standards; the people making the world’s leading non-linear professional editing systems; the people who make a living professionally processing and transcoding video; the people making multimedia playback software; the people making DCCTV systems; the people making operating systems; and yes, even forensic video and digital evidence technicians and analysts. We’re all human, my friends. It is a long, convoluted, complex process with its very foundation based on sampling an analog signal.
Sample & Line Doubling
Being the clever mathematicians that they are, some of these same folks realized that if they only stored half of the samples, it only took half the space! And then somewhere in some boring standards committee meeting, Joey piped up and said, “Hey, we could do that with the number of horizontal lines too!” I hope Joey got a raise at least, because I have no clue what his real name is. Let’s look at a few examples of what I’m talking about though. Below I’m using yet another set of DVD-Video standard pixel matrices:
NTSC DVD-Video: 352/480 = 0.733 SAR. 0.733 (SAR) x .909 (PAR) = 0.666 (DAR)
Wait, what? That can’t be right. Of course it’s not. We need to double the number of samples first, then try again.
NTSC DVD-Video (w/Samples Doubled): 704/480 = 1.467 (SAR). 1.467 (SAR) x .909 (PAR) = 1.333 (DAR)
PAL DVD-Video: 352/576 = 0.611 (SAR). Oh, wait a second. I see where this is going.
PAL DVD-Video (w/Samples Doubled): 704/576 = 1.222 (SAR). 1.222 (SAR) x 1.092 (PAR) = 1.334 (DAR)
So, in the above NTSC example our square pixel matrices are 640 x 480. In the PAL example, 768 x 576. Simple enough, Joey just applied it to the number of lines. As in the 2CIF and 2SIF examples below:
2CIF (NTSC and PAL): 704/288 = 2.444 (SAR). 2.444 (SAR) x 1.092 (PAR) = 2.668 (DAR)
Crap, forgot what I was doing. I need to double the lines before correcting aspect ratio.
2CIF (NTSC and PAL, line doubled): 704/576 = 1.222 (SAR). 1.222 (SAR) x 1.092 (PAR) = 1.334 (DAR)
Common Intermediate Format (CIF) was designed to be NTSC and PAL compatible without separate references for each. In the 2CIF example above our square pixel matrices would be 768 x 576. How about a couple more from the Source Input Format (SIF):
2SIF (NTSC): 704/240 = 2.933 (SAR)
Well I can tell you right now that’s not going to work. Double the number of horizontal lines.
2SIF (NTSC, line doubled): 704/480 = 1.467 (SAR). 1.467 (SAR) x .909 (PAR) = 1.333 (DAR)
Our square pixel matrices would be 640 x 480 for 2SIF NTSC.
2SIF (PAL): 704/288 = 2.444 (SAR)
Double the lines:
2SIF (PAL, line doubled): 704/576 = 1.222 (SAR). 1.222 (SAR) x 1.092 (PAR) = 1.334 (DAR)
Our square pixel matrices for 2SIF PAL are 768 x 576.
Notice anything else? Right, no cropping is going to be necessary in any of these CIF or SIF examples, as we started with only the visual information, either 704 or 352 samples. In the latter, we simply duplicate the number of samples before correcting aspect ratio. Same applies to the number of horizontal lines. In the examples above we have both 240 (NTSC), and 288 (PAL), which we simply need to duplicate before correcting aspect ratio. Done.
Other Variables
Well, I started this post saying that from a programming and forensic perspective everyone has gotten this wrong at some point, and yes many still do. How is your software dealing with your non-square pixel data? Does is use different PAR values than I've derived with this methodology? What about your players; when they try to help you by correcting aspect ratio, are they considering the actual PAR? Encoders and Presets? Does the container or stream metadata take care of this properly more often than not? Etc...
Sorry folks, but I’ve resigned to that fact that there are way too many variables for me to describe in my free time via this series of posts. I feel horrible about that, but I decided to stay up all night last night after sending a notification out to my peers asking them to review this methodology. I no sooner hit the send button and thought, Oh man, I need to at least wrap up the story. I hope you've found the series interesting and helpful, despite that snarky voice in my head. I have no doubt we'll be discussing this more in the future. I have a big project this weekend, and I’m going to need some sleep to do it.
I want to thank my employer, Ocean Systems, for providing me the opportunity to research, test, and explore these issues more thoroughly for you. Thanks to you and them, I get to do what I love every single day. All the best my friends.
