AVIHeader is suspicious after encoding a video

[KoolAidMan]

Video Encoder: x264
Audio Encoder: CopyAudio (MPEG-PS, AC3 Source)
Muxer: AVI Muxer
Muxing Format: AUTO

After encoding a test video, the header is suspicious. I looked in op_aviwrite, but nothing stood out as being necessarily wrong. I'll continue to investigate, but I am currently at a loss for why the header is blank.

[styrol]

Use MKV as format or re-encode audio.

AVI is deprecated. H.264 and/or AC3 in AVI is problematic (and dealing with it a hack). To avoid non-standard combinations look here.

[KoolAidMan]

Use MKV as format or re-encode audio.

AVI is deprecated. H.264 and/or AC3 in AVI is problematic (and dealing with it a hack). To avoid non-standard combinations look here.

I realize that AVI is a container which is on life-support; however, it is still often the most compatible and most widely supported container. Personally, I would rather go with MP4 before MKV as the support for MP4 is most certainly better as well. That being said, AVI is more than capable of doing what I want it to do-- as a matter of fact, the video itself is fine (albiet filled with hacks). I'm just trying to determine why the header is blank. I'll continue looking through the code...

Update: Re-encoding the audio to MP3 did not resolve the issue. The header is still blank.

[styrol]

Personally, I would rather go with MP4 before MKV as the support for MP4 is most certainly better as well.

Yep, but AC3 in MP4 is not officially supported (by MPEG) and not very widespread. MP4 (h.264/aac) would be state of the art if we talk about compliance and compatibility.

it is still often the most compatible and most widely supported container

Well there are a lot of pirated movie files in this format, mainly AVI (MPEG-4 ASP ("DivX")/MP3), which is indeed well supported. AVI support of h.264 encoded files by standalone players is another case.

[KoolAidMan]

Anyway, I am going outside of the specs for AVI, but that is not the reason why the header is not getting set. It appears to be a code issue. I am investigating.

[KoolAidMan]

Update: It does not look like bool    ADMMemioAvi::writeMainHeaderStruct(const MainAVIHeader &hdr) is being called.

Actually, that function is being called, but it is the function at the bottom of the preprocessor directive because I am building x86. I added some logging, and it looks like the MainAVIHeader is indeed being populated. This is the logging:

[Avi] Updating headers...
dwMicroSecPerFrame: 16683
dwMaxBytesPerSec: 8000000
dwPaddingGranularity: 0
dwFlags: 272
dwTotalFrames: 0
dwInitialFrames: 0
dwStreams: 2
dwSuggestedBufferSize: 65536
dwWidth: 720
dwHeight: 480

After further research, it looks like after we seek to 32, we do not actually write to the file. We then seek to 0x6c.

Okay, I think I finally get it-- in the function uint8_t AviList::Write(const uint8_t * p, uint32_t len), we actually do write the header to _ff... I still do not know why the header appears to be blank.

[KoolAidMan]

Header for video file encoded with 2.5.6-1. Both video details in the properties window and thumbnail show for the file.

Offset(h)    00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000  52 49 46 46 6E E8 E2 00 41 56 49 20 4C 49 53 54  RIFFnèâ.AVI LIST
00000010  4E 21 00 00 68 64 72 6C 61 76 69 68 38 00 00 00  N!..hdrlavih8...
00000020  2B 41 00 00 00 00 00 00 00 00 00 00 10 01 00 00  +A..............
00000030  90 0C 00 00 00 00 00 00 02 00 00 00 00 00 00 00  ................
00000040  D0 02 00 00 E0 01 00 00 00 00 00 00 00 00 00 00  Ð...à...........
00000050  00 00 00 00 00 00 00 00 4C 49 53 54 7C 10 00 00  ........LIST|...
00000060  73 74 72 6C 73 74 72 68 38 00 00 00 76 69 64 73  strlstrh8...vids
00000070  48 32 36 34 00 00 00 00 00 00 00 00 00 00 00 00  H264............
00000080  E8 03 00 00 24 EA 00 00 00 00 00 00 90 0C 00 00  è...$ê..........
00000090  00 00 00 00 10 27 00 00 00 00 00 00 00 00 00 00  .....'..........
000000A0  00 00 00 00 73 74 72 66 28 00 00 00 28 00 00 00  ....strf(...(...
000000B0  D0 02 00 00 E0 01 00 00 30 91 18 00 48 32 36 34  Ð...à...0ââ,¬Ëœ..H264
000000C0  00 D2 0F 00 00 00 00 00 00 00 00 00 00 00 00 00  .Ã’..............
000000D0  01 00 00 00 4A 55 4E 4B 00 10 00 00 41 76 69 64  ....JUNK....Avid
000000E0  65 6D 75 78 00 00 00 00 00 00 00 00 00 00 00 00  emux............

Header for video encoded with 2.6.1 r8392. Both files were encoded from exactly the same source with exactly the same encoding options. Neither file details, nor thumbnail show properly.

Offset(h)    00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000  52 49 46 46 C8 5A EF 00 41 56 49 20 4C 49 53 54  RIFFÈZï.AVI LIST
00000010  52 82 00 00 68 64 72 6C 61 76 69 68 38 00 00 00  Rââ,¬Å¡..hdrlavih8...
00000020  2B 41 00 00 00 12 7A 00 00 00 00 00 10 01 00 00  +A....z.........
00000030  00 00 00 00 00 00 00 00 02 00 00 00 00 00 01 00  ................
00000040  D0 02 00 00 E0 01 00 00 00 00 00 00 00 00 00 00  Ð...à...........
00000050  00 00 00 00 00 00 00 00 4C 49 53 54 84 40 00 00  ........LISTââ,¬Å¾@..
00000060  73 74 72 6C 73 74 72 68 40 00 00 00 76 69 64 73  strlstrh@...vids
00000070  48 32 36 34 00 00 00 00 00 00 00 00 00 00 00 00  H264............
00000080  E8 03 00 00 25 EA 00 00 00 00 00 00 A8 0C 00 00  è...%ê......Ã,¨...
00000090  40 42 0F 00 00 00 00 00 00 00 00 00 00 00 00 00  @B..............
000000A0  00 00 00 00 00 00 00 00 00 00 00 00 73 74 72 66  ............strf
000000B0  28 00 00 00 28 00 00 00 D0 02 00 00 E0 01 00 00  (...(...Ð...à...
000000C0  01 00 18 00 48 32 36 34 00 D2 0F 00 00 00 00 00  ....H264.Ã’......
000000D0  00 00 00 00 00 00 00 00 00 00 00 00 4A 55 4E 4B  ............JUNK
000000E0  00 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00  .@..............

[mean]

The openDML placeholder is bigger in the 2nd case (junk chunk)

[mean]

Is mediainfo happy about the file ?

[KoolAidMan]

MediaInfo didn't help with that, but it did help me find a bug in my x264 GUI change. I mixed up me_range and mv_range. Sorry! Expect a patch from me soon, probably tonight.

[KoolAidMan]

Here are the differences I can see in mediainfo. Looks like the problem is in the inform blocks of avi files. I unfortunately do not know enough about the avi container to know exactly what this means, but I will keep looking.

File with details encoded in 2.5.6-1
(General Tree)
Inform: AVI: 14.2 MiB, 53s 664ms
(Video Tree)
Inform: 1 730 Kbps, 720*480 (16:9), at 59.940 fps, AVC (NTSC) (High@L3.1) (CABAC / 5 Ref Frames)
(Audio Tree)
Inform: 384 Kbps, 48.0 KHz, 16 bits, 2 channels, AC-3 (Dolby Digital)

File Encoded with 2.6.1 r8394
(General Tree)
Inform: Complete name                            : F:\Work Area\test.avi
(Video Tree)
Inform: ID                                       : 0
(Audio Tree)
Inform: ID                                       : 1

[mean]

And they are both openDML ?

[KoolAidMan]

I know the file being saved from 2.5 is opendml. I used the AUTO setting in 2.6, so I do not know. I will save the file multiple times in 2.6 with the various settings.

I found out today that I can rewrite the avi contained in virtualdubmod and the thumbnail works and properties once again show in windows. I will post samples in a minute...

[KoolAidMan]

Turns out it was not OpenDML. Even though the GUI says "AVI/OpenDML" while you are encoding, it looks like that is just a hard-coded string in muxeravi.cpp.

OpenDML file saved with 2.5
2.5.avi.
OpenDML AVI file saved with avidemux 2.5.6-1.
Thumbnail and properties show properly.
Skipping in the video does not cause audio to drop out.

Standard avi file saved with 2.6
2.6-AVI.avi.
AVI file saved with avidemux 2.6.1 r8403
Thumbnail and properties do not show.
Skipping in the video does not cause audio to drop out.
Note: saving the file in 2.6 with mode AUTO produced a file which was bit-by-bit identical to this file.

OpenDML avi file saved with 2.6
2.6-OpenDML.avi.
OpenDML AVI file saved with avidemux 2.6.1 r8403
Thumbnail and properties do not show.
Skipping in the video causes audio to drop out!

Standard avi file saved with 2.6, then resaved as OpenDML AVI by VirtualDubMod
2.6-AVI-VDM.avi.
AVI file saved with avidemux 2.6.1 r8403.
AVI file rewritten with VirtualDubMod 1.5.10.3 using Direct Stream Copy for both audio and video.
Thumbnail and properties show correctly.
Skipping in the video does not cause audio to drop out.
Note: rewriting the OpenDML 2.6 file above will produce a file which is bit-by-bit identical to this file.

I will email the file samples to you.

[mean]

There is nothing obviously wrong with the avis
Still looking into it