ASF video file: replicated frames and probable tampering

Hi, Calimelo.

Thanks for replying!

I´ve just partially experimented your suggestion (executed only ffmpeg.exe) and it was output JPG files with distinct scenes, no repeated content at all, as if there weren´t replicated frames.

1) Now a question arises what are those absolute frames that Vegas Pro shows?
2) What´s the need of a video file has (so many) repeated frames?

I´ve inspected other WMV files with Vegas Pro in order to check if repeated frames is something usual (although I can´t guess why it would be…) but, not, only 1 absolute frame for each scene.

"Absolute frame", I guess, is how Vegas Pro call frames, starting numbering on 0.

I spent all day studying it and some progress has occurred

This WMV file presents a new scenario each 0,5s (2 Hz).
It has a 30FPS rate, according to the specific field in the file header (ASF format) and has a 15-frame extent for each scene, sometimes 7 frames. With a 30FPS specification in the file header and 15 frames per scene, yes!, you see a movie that changes scenes each 0.5, or 2 scenes per second. That´s makes sense.

But what DOESN´T make sense is a movie (allegedly original) that shows 2 images per second has been recorded with 14 repeated frames (1 frame with a useful image and 14 more frames with the same image), this way wasting media room and processing time.

So, I´ve got 2 hypothesis, and that considers that this WMV file is not the original one
1) the original video was 15, 30, whatever (much) more than 2 FPS, but was converted to a file taking frames with a 14-frame interval. In other words, taking 1 frame and skipping 14. Most dash cam records on the market records at a 30FPS rate, some at 15FPS, others at more than 30FPS.
2) the original recording was really done with a 2 FPS rate (although I don´t know if some dash cam recording system allows such recording rate) and a new file was created after the original has been edited, and saved with a different quality, that increased FPS (thus, resulting the replicated frames)

Hi, Calimelo.

In another forum, someone told me that dash cam recording system that records WMV there was in the past, what empowers hypotesis of a processed file, like some resulted of a video editor, likely a Windows Media Player (WMP is just a conjecture, not important at all).

Yes, I´ve already checked metadata. If you mean to do this in order to get information about camera maker and other complimentary info, they are not there. The only "technical" material I´ve got was provided by Windows Media ASF View 9 Series. The lines below are only a fraction of what this software can show

ASF File (20160206135501.WMV)
File D\Temp\20160206135501.WMV
EOF Position 161298668 ( 0x99D38EC )

File Properties Object (104 bytes)
Object ID 8CABDCA1-A947-11CF-8EE4-00C00C205365
Object Size 104 ( 0x68 )

Version 2
MMS ID AECA96BA-574D-4E3D-8912-2DC22A9B74F9
Total Size 161298668 ( 0x99D38EC )
Creation Time 2016-2-11 102312.686
Packets 20160
Duration 3656.193
Send Duration 3654.175
Preroll 0005.000
Flags 0x00000002
Broadcast 0
Seekable 1
Use Packet Template 0
Live 0
Reliable 0
Recordable 0
Unknown Data Size 0
Max Packet Size 8000 ( 0x1F40 )
Min Packet Size 8000 ( 0x1F40 )
Max Bitrate (bit/sec) 1680932

Data Object (not loaded) (161280050 bytes)
Object ID 75B22636-668E-11CF-A6D9-00AA0062CE6C
Object Size 161280050 ( 0x99CF032 )

MMS ID AECA96BA-574D-4E3D-8912-2DC22A9B74F9
Packets 20160
Alignment 1
Packet Aligment 1

Stream Properties Object [1] (114 bytes)
Object ID B7DC0791-A9B7-11CF-8EE6-00C00C205365
Object Size 114 ( 0x72 )

Stream Number 1
Version 1
Offset 0
Encrypted False
Security ID 1865290003 ( 0x6F2E1113 )
Stream Type Specific
Stream Type Audio Media
Format Tag 353
Channels 2
Samples / Seconds 44100
Average Bytes / Second 8005
Average Bitrate (bits/sec) 64040
Block Align 1487 ( 0x5CF )
Bits / Sample 16
Extra Data Size 10
Extra Data 0000 00 88 00 00 0F 00 79 2E-00 00 y.
Error Concealment
Strategy Audio Spread
Span 1
Virtual Packet Length 1487 ( 0x5CF )
Virtual Chunk Length 1487 ( 0x5CF )
Silence Data 0000 00

Extended Stream Properties Object [1] (88 bytes)
Object ID 14E6A5CB-C672-4332-8399-A96952065B5A
Object Size 88 ( 0x58 )

Stream Number 1
Start Time 0000.000
End Time 0000.000
Avg. Time / Frame 0000.1853203
Avg. Frames / Second 5.40
Max. Object Size 1487 ( 0x5CF )
Avg. Data Bit Rate 64040
Max. Data Bit Rate 64040
Avg. Buffer Size 0001.579
Max. Buffer Size 0001.579
Avg. Initial Buffer Fullness 0000.000
Max. Initial Buffer Fullness 0000.000
Flags 0x00000002
Reliable 0
Seekable 1
No Clean Points 0
Resend Live Clean Points 0
Language Index 0

Stream Properties Object [2] (133 bytes)
Object ID B7DC0791-A9B7-11CF-8EE6-00C00C205365
Object Size 133 ( 0x85 )

Stream Number 2
Version 1
Offset 0
Encrypted False
Security ID 0
Stream Type Specific
Stream Type Video Media
Window Width 640
Window Height 480
Flags 2
Bitmap Info Header
biSize 44
Width 640
Height 480
Planes 1
Bits 24
Compression TEXT WMV2
0000 57 4D 56 32 WMV2
Image Size 0
X Pels / Meter 0
Y Pels / Meter 0
Colors Used 0
Colors Important 0
Extra Data Size 4
Extra Data 0000 F6 40 AD 00 @
Error Concealment
Strategy No Error Correction

Extended Stream Properties Object [2] (110 bytes)
Object ID 14E6A5CB-C672-4332-8399-A96952065B5A
Object Size 110 ( 0x6E )

Stream Number 2
Start Time 0000.000
End Time 0000.000
Avg. Time / Frame 0000.0333333
Avg. Frames / Second 30.00
Max. Object Size 88526 ( 0x159CE )
Avg. Data Bit Rate 1600000
Max. Data Bit Rate 1600000
Avg. Buffer Size 0005.000
Max. Buffer Size 0005.000
Avg. Initial Buffer Fullness 0000.000
Max. Initial Buffer Fullness 0000.000
Flags 0x00000002
Reliable 0
Seekable 1
No Clean Points 0
Resend Live Clean Points 0
Language Index 0
Payload Extension Systems
System ID Data Size System Info Size System Info
Payload Extension System Sample Duration 2 0

Stream Bitrate Properties Object (38 bytes)
Object ID 7BF875CE-468D-11D1-8D82-006097C9A2B2
Object Size 38 ( 0x26 )
Stream Bitrates
Stream Number Bitrate
1 67271
2 1613661

Codec List Object (246 bytes)
Object ID 86D15240-311D-11D0-A3A4-00A0C90348F6
Object Size 246 ( 0xF6 )

Codec ID Reserved 2
Codecs
Name Description Type Format / FourCC Info Size Info
"Windows Media Audio 9.2" " 64 kbps, 44 kHz, stereo (A/V) 1-pass CBR" WMT_CODECINFO_AUDIO 353 2 0000 61 01 a
"Windows Media Video V8" "" WMT_CODECINFO_VIDEO WMV2 4 TEXT WMV2
0000 57 4D 56 32 WMV2

Extended Content Description Object (168 bytes)
Object ID D2D0A440-E307-11D2-97F0-00A0C95EA850
Object Size 168 ( 0xA8 )

Attributes 3
Attributes
Index Name Stream Type Language Value
0 "WMFSDKVersion" 0 String 0 "12.0.7601.17514"
1 "WMFSDKNeeded" 0 String 0 "0.0.0.0000"
2 "IsVBR" 0 BOOL 0 False

Metadata Object (216 bytes)
Object ID C5F8CBEA-5BAF-4877-8467-AA8C44FA4CCA
Object Size 216 ( 0xD8 )

Attributes 4
Attributes
Index Name Stream Type Language Value
0 "IsVBR" 1 BOOL 0 False
1 "DeviceConformanceTemplate" 1 String 0 "L1"
2 "IsVBR" 2 BOOL 0 False
3 "DeviceConformanceTemplate" 2 String 0 "@"

Language List Object (39 bytes)
Object ID 7C4346A9-EFE0-4BFC-B229-393EDE415C85
Object Size 39 ( 0x27 )

Languages 1
Languages
Index Language
0 pt-br

Header Object (5254 bytes)
< show > Object ID 75B22630-668E-11CF-A6D9-00AA0062CE6C
Object Size 5254 ( 0x1486 )

Header Objects 7
Alignment 1
Architecture 2

Header Extension Object (4421 bytes)
< show > Object ID 5FBF03B5-A92E-11CF-8EE3-00C00C205365
Object Size 4421 ( 0x1145 )

Clock Type Reserved 1
Clock Size 6
Extended Header Size 4375 ( 0x1117 )

Compatibility Object (26 bytes)
< show > Object ID 26F18B5D-4584-47EC-9F5F-0E651F0452C9
Object Size 26 ( 0x1A )

Profile 2
Mode 1

this video is allegedly the original file made by a vehicular video recorder that has a missing extent that would have recorded a traffic accident;

What recorder, precisely? How was it configured?

It doesn´t make sense to me that a video recorder spends processing time recording either 6 or 14 replicated frames of a same scene. In addition, why this variable number of repeated frames?
So, what is/are hypothesis regarding this frame repetition?

No hypothesis. Not without knowledge of the hardware, and it's associated encoding software, and how it was actually configured.

Questions are another matter.

Is this a product that has been 'tweaked' to meet some artificial benchmark? (Like flatbed scanners with resolution of thousands of ppi?) Is the current configuration default/recommended, or has someone modified it – if so, based on what? A setting covered by the manufacturer's recommendation, or simply by turning everything accessible dial to '11', regardless of if that setting actually makes sense? (More technically, what raw framerate is the hardware capable of, and how is that modified by any encoding software, and how does that compare to the observed framerate of the recorded video?)

Is encoding done by software, or is it done in hardware?

Was the recorder installed according to manufacturer's instructions? By a certified installer? Or is it an amateur job? If it is, what external actors affect the recorder? G-force sensors? Does it feed on external or internal power? (IF external, what affects *that*?) Is it correctly grounded? (Technically Are all requirements for producing a useful recording fulfilled, or not?)

I'd test the recorder, myself, with the same settings does it produce the same artifacts shown in the recording or doesn't it? If it does, and if it wasn't installed as per installation instructions, it is relevant to test *that* particular recorder under as similar circumstances as possible. to see if recording is affected.

Hi, do you have a chance to replicate the video, i mean use that bodycam and compare it with your recording?

Hi, Calimelo.

No way, for while. Some questions to be asked to the other party intend to let me know what´s the recording system maker, model and other information. After this, questions will be asked to the maker.

At this moment, all I got is the wmv file and a report wil have to be written about this.

athulin, thanks for engaging this discussion.

A lot of questions are prepared to be asked to the other party by lawsuit, answers that will help to understand what happened, but for while, the wmv file is the only material available to produce a technical report.

I´ve just discovered that Vegas Pro interpolates (virtual) frames in order to comply to the FPS specified in the project. Vegas Pro is not the appropriate tool for this, so it made me get erroneous conclusions, but not all is lost.
I´ve checked that wmv file with ASFBin 1.8 and discovered that file is indeed 4FPS, 4 encoded frames per second, 4 real frames per second. So, there´s no replicated frames indeed.
I apologize for passing a wrong information, but I didn´t know Vegas Pro had such behavior. I´ve used other video editor that seemed to me they were hiding the replicted frames, but indeed Vegas Pro was the one showing virtual frames.

MediaInfo and others report a "nominal frame rate" of 30FPS. Why such a nominal rate in a 4FPS video file??? What does it mean?

Hi there,
Firstly, when dealing with CCTV, Surveillance Video, Dashcams and any other non-standard video recording device… the use of common sense and standard tools goes out of the window. The manufacturing and the firmware / software design is usually poor and the evidential requirement of the recording is often not even considered.

A consequence of this is that you have many unknown variables to test, and without the device….all you can do is document the unknown variables.

The next best thing is some form of documentation that details what the device was, and then the process used to create the data file in your possession.
Again, without this documentation, there will be many more unknown variables and you will have nothing to compare against.

Dashcams record their data in many ways. Most use a removeable media storage device to save the recorded footage. Thus, the first true recording would be on that device.

Some store onto a storage device but you must connect the camera to a computer, via a data link such as USB, to view and export the data files. Most of this type use a proprietary, stream only, recording method onto the device and then it’s during the export process that the stream gets placed into a container file, such as WMV or MP4 etc.

Some of the more expensive ones have built in Wi-Fi or other wireless transfer methods.

What gets recorded is another important point. Many utilise motion or sudden G-Force recordings. The device will buffer all video but only retain footage if a sudden event occurs.

Some will record all the time at a low frame rate, and then increase the frame rate at an event.
Linked to the video is meta data relating to these events and possibly also GPS Coordinates. This information in data size is very small but if the WMV file is decoded by the manufacturers proprietary playback software, the motion sensors and the mapping would be visualised.

The point to all of this is that you are seeing a stream inside a container. Without knowing exactly how the system works, it is very difficult to identify inconsistencies in the data file you have been presented with.

There are a few suggestions such as analysing the raw hex data to identify unknown data within the video slices that may be indicative of GPS/Force data. You may also see information within the ASCI Text.

Also, analysing the video within a forensic environment, rather than a standards based NLE. I use Amped FIVE. I am a Forensic Image and Video Analyst…and I’m also the International trainer for Amped Software.

That may not be something available to you but whatever options you do consider, you must attempt to get as much information as to the creation of the file as possible.

Hex analysis, Stream analysis, Frame analysis etc.. should highlight areas of interest but there could be a valid reason for them. Having just a bit more information is vital.

So your report could be very brief – you have identified areas of concern but no conclusions can be drawn until you can examine the device and evaluate its recording methods.

Good luck, and if you want to discuss more then just send me a direct message.