ffprobe and AVI audio delay

[DCTing]

Summary of the bug:

When trying to obtain the (non zero) audio delay from an AVI file through ffprobe, 0 seconds is the result. Same result in Linux and Windows.

Other applications like Media Player Classic show the right non zero value, see image: ​https://i.stack.imgur.com/bl7CI.png

How to reproduce:

(Using ffprobe v3.2.10-1~deb9u1+rpt1).

Run a ffprobe command over an AVI file that has audio delay:

ffprobe -show_entries stream -i "(My_AVI_file_path)"

The result is like this (no audio delay can be found, AFAIK...):

index=0
codec_name=mpeg4
codec_long_name=MPEG-4 part 2
profile=Advanced Simple Profile
codec_type=video
codec_time_base=1001/24000
codec_tag_string=XVID
codec_tag=0x44495658
width=720
height=384
coded_width=720
coded_height=384
has_b_frames=1
sample_aspect_ratio=1:1
display_aspect_ratio=15:8
pix_fmt=yuv420p
level=5
color_range=N/A
color_space=unknown
color_transfer=unknown
color_primaries=unknown
chroma_location=left
field_order=unknown
timecode=N/A
refs=1
quarter_sample=false
divx_packed=false
id=N/A
r_frame_rate=24000/1001
avg_frame_rate=24000/1001
time_base=1001/24000
start_pts=0
start_time=0.000000
duration_ts=179064
duration=7468.461000
bit_rate=1804834
max_bit_rate=N/A
bits_per_raw_sample=N/A
nb_frames=179064
nb_read_frames=N/A
nb_read_packets=N/A
DISPOSITION:default=0
DISPOSITION:dub=0
DISPOSITION:original=0
DISPOSITION:comment=0
DISPOSITION:lyrics=0
DISPOSITION:karaoke=0
DISPOSITION:forced=0
DISPOSITION:hearing_impaired=0
DISPOSITION:visual_impaired=0
DISPOSITION:clean_effects=0
DISPOSITION:attached_pic=0
DISPOSITION:timed_thumbnails=0
index=1
codec_name=ac3
codec_long_name=ATSC A/52A (AC-3)
profile=unknown
codec_type=audio
codec_time_base=1/48000
codec_tag_string=[0] [0][0]
codec_tag=0x2000
sample_fmt=fltp
sample_rate=48000
channels=6
channel_layout=5.1(side)
bits_per_sample=0
dmix_mode=-1
ltrt_cmixlev=-1.000000
ltrt_surmixlev=-1.000000
loro_cmixlev=-1.000000
loro_surmixlev=-1.000000
id=N/A
r_frame_rate=0/0
avg_frame_rate=0/0
time_base=1/56000
start_pts=0
start_time=0.000000              <- NOTE!!!
duration_ts=N/A
duration=N/A
bit_rate=448000
max_bit_rate=N/A
bits_per_raw_sample=N/A
nb_frames=418233816
nb_read_frames=N/A
nb_read_packets=N/A
DISPOSITION:default=0
DISPOSITION:dub=0
DISPOSITION:original=0
DISPOSITION:comment=0
DISPOSITION:lyrics=0
DISPOSITION:karaoke=0
DISPOSITION:forced=0
DISPOSITION:hearing_impaired=0
DISPOSITION:visual_impaired=0
DISPOSITION:clean_effects=0
DISPOSITION:attached_pic=0
DISPOSITION:timed_thumbnails=0

Is there a way to obtain the audio delay via command line?

[Carl Eugen Hoyos]

Please test current FFmpeg git head and please provide an input sample file.

[DCTing]

Unfortunately the original AVI file is 1.98Gb length, unless you point a way for me to upload it.

I've tried to trim it and get a shorter test file to upload, but the operation doesn't inherit the strange delay property.

For example if I trim it with...

ffmpeg -i InputFile.avi -t 30 -c:v copy -c:a copy OutputFile.avi

...I get an invalid video, with the delay "burned" and clearly audible, in spite of the copy order, that should keep it intact. In the input file delay is not audible.

Somehow the metadata that informs about the delay is cleared in the trimming process (and in any process, I dare to say). Depending on the tool used to trim, sometimes the delay gets burned in (ffmpeg, Avidemux), and sometimes not (because corrected by the tool, as Handbrake).

But always the final result looses the metadata about the delay info, that is the one we want to measure with ffprobe.

[Carl Eugen Hoyos]

Replying to DCTing:

I've tried to trim it and get a shorter test file to upload, but the operation doesn't inherit the strange delay property.

For example if I trim it with...

ffmpeg -i InputFile.avi -t 30 -c:v copy -c:a copy OutputFile.avi

ffmpeg generally cannot be used to trim files, use dd.

[DCTing]

Finally I got a clean test file, thanks for the trimming idea.

Steps to reproduce:

1-Download sample TEST1.AVI file (just 8Mb size): ​https://drive.google.com/open?id=1qsnv7cbWyc3z5mao98dgUpO7venMJkRH

2-Play it. Note that in t=00:00:28:345 audio pronounces the word: "TOKYO". This is the correct time where it must appear.

3-Do a simple process with ffmpeg, for example with command:

ffmpeg -i TEST1.AVI -c:v libx264 -c:a mp3 TEST2.AVI

(An error appears at the end, caused by the trimming operation, I don't think its critical).

4-Play "TEST2.AVI" and note that the word "TOKYO" appears at t=00:00:25:800, i.e. 2.5 seconds before it should. Compressed video gets unusable!

So there must be a hidden delay in the original AVI file that neither ffmpeg can't see nor ffprobe, as states this ticket.

[Carl Eugen Hoyos]

Replying to DCTing:

2-Play it. Note that in t=00:00:28:345 audio pronounces the word: "TOKYO". This is the correct time where it must appear.

3-Do a simple process with ffmpeg, for example with command:

ffmpeg -i TEST1.AVI -c:v libx264 -c:a mp3 TEST2.AVI

(An error appears at the end, caused by the trimming operation, I don't think its critical).

4-Play "TEST2.AVI" and note that the word "TOKYO" appears at t=00:00:25:800, i.e. 2.5 seconds before it should. Compressed video gets unusable!

The conversion needs -async 1 (or an equivalent audio filter) because audio is missing. Are you sure that the avi header explicitely contains the delay?

[Carl Eugen Hoyos]

For both streams in your provided sample file, strh->start is 0.

[DCTing]

Replying to cehoyos:

Are you sure that the avi header explicitely contains the delay?

Well, not quite sure (may be it's a defective video), but 2 symptoms point to it:

1- When processed through ffmpeg, audio rewinds 2.5 seconds back from its correct position.

2- Incidentally Media Player Classic also informs about a 2.5 seconds delay. Please see this capture: ​https://i.stack.imgur.com/bl7CI.png These is the delay I expected ffprobe to inform me.

The conversion needs -async 1

Thanks for the tip, I will test it.

[Carl Eugen Hoyos]

Replying to DCTing:

Replying to cehoyos:

Are you sure that the avi header explicitely contains the delay?

Well, not quite sure (may be it's a defective video), but 2 symptoms point to it:

The symptoms only indicate that FFmpeg (and other software) is able to correctly read the initial timestamps of the file, but their difference is not what multimedia developers usually call delay.