I stand corrected. First, I did find a reference to Pixel Aspect Ratio (PAR) and down sampling uncompressed NTSC video in the joint Forensic Imaging and Multi-media Glossary (PDF) published by the IAI and LEVA, the final version of which was released in July, 2006. Second, in an effort to simplify this discussion, I’ve over simplified the Interpolation Methodology I described in Part 2. I will be expanding on that in this post, in far more detail than I had originally intended.

I was hoping I’d be able to wrap this series up with this post, but it’s clear to me now that I won’t be able to. There’s simply too much to cover and I’m certain that at least a few are still scratching your heads (like I was), wondering why we shouldn’t just rely on the pixel matrices to calculate Pixel Aspect Ratio (PAR) from analog sources. It is critically important to understand that I am approaching this topic from a forensic perspective, with the goal of standardizing the methodology used for forensic processing, interpretation, and presentation.

The multimedia evidence community has been really buzzing the last couple of years in regards to how useful FFmpeg and Libav can be for dealing with proprietary video formats. Both tools are extremely useful in several aspects of a forensic DME workflow. With that said, however, whether it’s FFmpeg, Libav or another 3rd party tool, there are limitations and causes for concern when using them to process proprietary video file formats.

This brief (approx. 9min.) introduction into the world of digital video evidence is intended to provide law enforcement professionals with a better understanding of the basic concepts and related issues.  It was geared towards first responders, who in many cases are the ones initially seizing video evidence.

FFmpeg is a great tool to have in your toolbox if you’re a multimedia geek. If you live mostly in the world of Microsoft Windows and have dozens, hundreds, or thousands of files to process though they lose a little luster. Sure, there are tons of free applications built on FFmpeg that provide some limited batch processing capability, but usually they're just that; limited. Here’s a simple way you can process hundreds of files from one format to another, using the full capability of your FFmpeg install.

First, which scripting languages do you know? Great, we won’t need those, but that’s really cool that you know them. Given that you’re reading this, I’m going to assume you can write plain text into a text file. I don’t like to assume anything, but I’m feeling pretty good about that one. Alright, let’s get started.

I posted a new page last week under our Professional Community menu called Free DME & FVA Tools. Hope you find it helpful.

It’s sometimes difficult for traditional Computer Forensic (CF) examiners to understand why they should treat video and multimedia any differently than other types of digital evidence. After all, a bit is a bit, and a byte is a byte. Right? CF examiners are typically highly trained and highly technical people. If anyone is going to understand how to recover and interpret multimedia data, one would think that a traditional CF examiner would be at or near the top of your go-to list. The problem with this assumption is that multimedia data is fundamentally different than most other types of data, and in more than one way.

Understanding video standards is fundamental to aspect ratio correction. Back in the predominantly analog days we had three main standards referenced or used for most video recordings; NTSC, PAL, and SECAM. Then in the early ‘90’s came the first digital multimedia frameworks to reach the average consumer; QuickTime and, shortly thereafter, Video for Windows (VfW).

Today we have dozens of multimedia frameworks, digital video and digital display standards, all of which lead to a great deal of confusion regarding the plethora of acronyms and what they truly mean. AVC or H.264? HEVC or H.265? CIF or SIF? Don’t even get me started on the profiles and parameters available for each standard, as the combinations are truly mindboggling. When it comes to proper Display Aspect Ratio (DAR) though, it really boils down to “Are the originally recorded pixels square or non-square?”

I 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.

Let’s talk a little more about aspect ratio. Always a lively topic everywhere I go, and regularly misunderstood by industry leading CCTV equipment manufacturers, engineers, and other video professionals. Should we correct, when do we correct, how do we correct, and of course the why. I’ve done a few short posts on the topic in the past (here's one), but this will be in a little more detail. Still writing on the fly, just going to break it down into a few posts over time.

Several other things I should be doing on a Saturday morning, but I find myself anxious to continue this discussion. Maybe it’s because although multiple industry Best Practice documents talk about correcting Aspect Ratio, none of them discuss the proper way to do it. It could also be my new coffee maker, which I'm hypothesizing has increased my caffeine intake substantially, although I have not increased my coffee intake. Who knows. Anyway, let’s start by recapping Part 1.

Want to know what to encode with for great H.264 files? Robert Reinhardt, founder of VideoRx.com, is happy to tell you. One minute into his recent Streaming Media West presentation on how to evaluate H.264 encoders he gave the big reveal: FFmpeg is the best choice around.

Full story

At the 2011 Consumer Electronics Show today, Intel announced the release of its new series of processors, codenamed "Sandy Bridge." Loaded with features catering to games- and video-hungry users, the changes reflect that fact that consumers are responsible for 66 percent of Intel's revenue, a reversal from 2000, when enterprise consumers provided 71 percent of revenues.

Full story:
http://www.technologyreview.com/blog/editors/26226/

There ARE Non-square samples, and their shape IS NOT dependent on the # of scanning lines. There are also Non-Square picture elements in CCD and CMOS image sensors, but their electrical charge is never converted to digital in an analog CCTV camera.

Back in the day there actually were Non-Square pixel-based displays, but they were only used for special applications and are not found in the wild today.

If you are aware of a standard that defines the shape of 480i (NTSC) or 576i (PAL) non-square samples differently than through the use of the luminance sampling frequencies, please bring that to my attention. Thank you.

Until about two years ago, it wasn't that often that I’d encounter Variable Frame Rate (VFR) video evidence, unless of course the case included video recorded by mobile phones. Times, they are a changing my friend.

DVR/NVR manufacturers are leveraging the advantages of VFR more often these days. And why shouldn't they be, especially when we’re seeing even the high-end professional video recording equipment start to use VFR more frequently. Throw in the want/need to get to Ultra HD before the next guy, and suddenly you've got a decent argument for VFR.

You can just press play if you want to, but if you're forensically processing evidence, I wouldn't advise it. Know the playback software, as it is just as important to proper playback and interpretation as the hardware. Take Windows Media Player, for instance.

In the following video I discuss a few quirks about Windows Media Player v12, a shortcoming of the popular metadata tool MediaInfo, and more.

"VirtualDub is a video capture/processing utility for 32-bit Windows platforms (95/98/ME/NT4/2000/XP), licensed under the GNU General Public License (GPL). It lacks the editing power of a general-purpose editor such as Adobe Premiere but is streamlined for fast linear operations over video. It has batch-processing capabilities for processing large numbers of files and can be extended with third-party video filters. VirtualDub is mainly geared toward processing AVI files, although it can read (not write) MPEG-1 and also handle sets of BMP images."

As you may know, version 1.10.4 of Avery Lee's video capture/processing utility was released a little over a month ago. I've packaged it with several of the input plugins I regularly use, with one notable exception; the FFmpeg input plugin. I've had nothing but issues w/version 0.7 of the FFmpeg input plugin when used with version 1.10.4 of VirtualDub, so I've provided the source but did not install the plugin in my v1.10.4 package.

The v1.9.11 package contains all of the same input plugins, and version 0.7 of the FFmpeg input plugin is loaded automatically as well. Head past the break for the links to download.