SWGDE Technical Notes on FFmpeg v2.0

As noted yesterday, I want to take a moment to examine a current document, SWGDE Technical Notes on FFmpeg v2.0.

I have a couple of big problems with this document. But first, what is FFmpeg?

FFmpeg is a freeware tool. It's also a tool that underpins many of the big platforms used in digital / multimedia analysis. But, what is important to know is that FFmpeg is not a tool of "forensic science." I've had concerns with the forensic science use of FFmpeg for some time. You can visit these posts to get caught up: 5/19/2014, 12/18/2018, & 3/23/2019 are a few key posts.

Point 1, there's a section missing in this document.

There is a need for a section describing what FFMPEG does, as a program, when data is missing or non-standard in reporting essential fields for playback. If yes, report. If null, then (x). 

As an example, the frames per second field / data entry. There are many Chinese manufacturers that feature a non-standard or empty tag for this field that is interpreted within the DVR for playback via other programatic information. In this case, FFMPEG (as a European product), may report the fps as 25 because there needs to be a value for fps in order to play the video. If the retrieval report notes that the recorder is expecting to place 30fps into the container, and the result of FFMPEG's work is 25 fps because of non-standard tag use, then the examiner should at least be aware that (a) this can/does happen, (b) how to address the results from a scientific standpoint (what it "is" vs. what is "should be").

This basic limitation in the data should be known by those that use this tool. In many cases, the practitioner takes what is output at face value, without further enquiry. Thus, a bit of a warning is necessary that this situation exists and that there are steps that can be taken to either ascertain the correct value or list it in a limitations section of the report as an unknown variable.

Point 2, the output of the Macroblock Analysis function is incorrectly described.

Section 8.2 graphic (see below) incorrectly describes the Grey output block.

Grey doesn't "generally" mean “no change.” Grey means that the block does not meet a defined condition. From the source, "Note that these are parsed in order (from top to bottom), and if one condition matches, the color will be chosen. If none matches, the macroblock will be rendered as grey.” As they are parsed in order, the display order of the graphic should follow the guidance from FFMPEG.

Here's what FFmpeg's version of the flow chart looks like.

Not only is Grey incorrectly described, the description of the conditions represented by the various colours is incomplete.

The first line of SWGDE's chart shows purple as "new data." That colour in FFmpeg's chart is noted as 16x16 Intra Prediction. "New data" can be interpreted in several ways. But, "Intra Prediction" makes it quite clear that the block represents predicted data taken in some way from that frame.

A similar problem exists with the next line. Again, the "new data" description isn't accurate. It actually represents 4x4 Intra Prediction.

You'll also note that there are more conditions present in the latter chart (FFmpeg) than the former (SWGDE). Why should this be?

Thus it is that the information in the current document is incomplete and inaccurate. I have no idea why my suggestions weren't addressed during the revision. I received no communication from SWGDE - either acknowledging receipt of my correspondence or rejecting my suggestions. I'll address that issue in a later post.

As always, if you care to comment, please do so (politely) below.

Be well my friends.