AVF Files and Frame Timings

What started out to be a standard use of FFmpeg turns into something slightly different.

Most Digital Video Recorders are designed to capture an event. Unfortunately, the analysis of a recorded event is often hindered by the type of recording method and format used. Whilst working with some AVF Files, this issue was clearly displayed.

The Disk came with a common structure of files, player and codec-install.

diskContentsFor some reason the folder containing the video files was named AVI rather than AVF.

avf files

Running the player loads a common user interface, but asks for a ‘floder’!!

Interface-floder

I am not going to attempt to use that instcodec.exe – I have no idea what its going to do!

Playback of the video worked fine, but I needed to know more – time to understand it….

MediaInfo revealed that they were mpeg4 files and the FFprobe report confirmed this, reporting 1212 frames, and their true recorded size.

[STREAM]
index=0
codec_name=mpeg4
codec_long_name=MPEG-4 part 2
profile=unknown
codec_type=video
codec_time_base=1/25
codec_tag_string=[0][0][0][0]
codec_tag=0x0000
width=704
height=288
has_b_frames=1
sample_aspect_ratio=1:1
display_aspect_ratio=22:9
pix_fmt=yuv420p
level=-99
timecode=N/A
quarter_sample=0
divx_packed=0
id=N/A
r_frame_rate=25/1
avg_frame_rate=0/0
time_base=1/1200000
start_pts=1200000
start_time=0:00:01.000000
duration_ts=N/A
duration=N/A
bit_rate=N/A
nb_frames=N/A
nb_read_frames=1212
nb_read_packets=N/A
[/STREAM]

After this I attempted a common FFmpeg rewrap. Unusually, it failed with an error.

cmd

A few tests were completed and although it was possible to transcode, all attempts to keep the original codec but just drop the duplicates failed.

An uncompressed RGB file was created. This served the purpose of creating a file that could be utilised further. Secondly, it was possible to extract all the I frames from the video.

ffmpeg -i input.avf -vsync drop -vf select='eq(pict_type\,I)' 
-f image2 -pix_fmt rgb24 framesfolder\frame%05d.tiff

However, during the analysis, there were questions raised regarding the motion in the video and the nature of how it was being presented. In order to understand more we need to go back to the original AVF file.

gSpot reveals some interesting frame level analysis:

Gspot

To understand and verify what this is telling us, an why its saying a lot more frames than MediaInfo,  it is necessary to use some other tools, namely Defraser and FFprobe.

Defraser confirmed and verified all the Keyframes that had been extracted using FFmpeg but also mirrored the pattern of the GOP structure as identified by Gspot.

defraser

Lastly, by completing a full frame report using FFprobe, the entire structure was output.

ffprobe -show_frames -print_format xml -v quiet inputfile.avf > out.xml

To explain why the original rewrap was failing and then to understand the strange motion being presented by the video is a little hard to do – but I will do my best!

codedPic-gspot

It is not, as was previously reported by gSpot, a 25 frame GOP. It doesn’t actually have 2524 frames. It is a 12 Frame GOP with only 1212 Frames. The frames after each coded picture are not coded frames. They are markers to hold the previously coded frame for a period of 40 milliseconds each.

The unusual thing is the pattern.

PTS

I have only shown the PTS (Presentation Time Stamp) here as the Decode Time Stamp shows the same pattern but obviously prior to the PTS.

Each GOP lasts 1000 milliseconds. The encoding states that each frame is 40 milliseconds. However, the times between each PTS are not all 40 milliseconds. Some are 80, some are 120 and one is 160 milliseconds. In this case, the video holds the frame until the next one has been decoded and is due to be presented. This is why there are 25 40ms frames identified.

The reason why FFmpeg suffered errors when trying to drop duplicates from the file during the rewrap, is that these ‘duplicates’ actually form part of the video and as such, trying to get rid of them but keep the encoding will not work.

The pattern of frame presentation now makes it clear why motion in the video appeared erratic. Being able to identify this timing structure may be rare when dealing with proprietary video but having an awareness of it will help when analysing an object in motion.

There is a fair bit online regarding mpeg4 and PTS / DTS and I have found some good technical documents available from Textronix, in particular MPEG Fundamentals.

July 2013 Update: Be careful if using the inbuilt convert to AVI function that comes with a few of these AVFplayback.exe’s. Although the DVR’s are set to PAL, they only record at field level to save space. I have seen both 720 x 288 and also, as in the case detailed above, 704 x 288. The problem though, and the reason for this update, is that some of the AVI converters then turn your PAL footage into NTSC. Obviously this can can cause you all sorts of problems!!

Advertisements
By Spreadys Posted in EEPIP

0 comments on “AVF Files and Frame Timings

  1. Pingback: Samsung Mpeg4 AVI & SMI Files | Spreadys Space

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s