Issue with Xvid video in Avideumx 2.7.x

[mederi]

avidemux_2.7.4 r190804_win32 or latest avidemux_2.7.4 r190808_win32 seem to be O.K. Thank you very much.
Just one more catch: Avidemux reports wrong frame type of several frames in P-FRM (04) row of frames in provided video sample. There are 5 more I-FRM (04) frames recognised (each 16 frames) when moved manually frame-by-frame.
--- EDIT ---
Please enable "[v] Use XVID fcc (else DIVX)" checkbox by default in "Mpeg4 ASP (xvid4)" encoder configuration. I tried to play some DIVX or DX50 videos in several TVs (including smart ones), but they were unsupported there. A fcc change to XVID helped. It seems that XVID is a preferred fcc to DIVX and widely supported nowadays.

[eumagga0x2a]

Just one more catch: Avidemux reports wrong frame type of several frames in P-FRM (04) row of frames in provided video sample. There are 5 more I-FRM (04) frames recognised (each 16 frames) when moved manually frame-by-frame.

It would be each 12th frame if you reduce the cache size to 12 decoded pictures, right?

[mederi]

You are right: 12 frame cache => each 12th frame

[eumagga0x2a]

Should be fixed now, thank you for your timely report.

[eumagga0x2a]

Regarding the default xvid fourcc, I would suggest saving the desired encoder and muxer configuration as default settings in Avidemux if you happen to use xvid often. Different from bugs like broken handling of empty frames, corrective actions on user part are readily available here

All smart TVs out there support H.264, this is a codec one would want to use nowadays. Xvid and other obsolete mpeg4 brands are destined to go extinct.

[mederi]

O.K., no problem. I have just suggested that Xvid encoder deserves its own XVID FourCC by default and a fix would be probably simple (false -> true) somewhere in Avidemux code. I really prefer the H.264 as a modern and better compression, but recenly I just used the Xvid to encode some videos to match the rest ones archived long time ago.

I can nonfirm that avidemux_2.7.4 r190810_win32 has solved the reported issues.

Next I would like to ask you, whether it is a correct behaviour (not a bug) that Avidemux is always "Unpacking bitstream" when loading an mpeg4 video even if it does not contain a packed bitstream. Avidemux 2.5 contains a detection of PB.

[eumagga0x2a]

I have just suggested that Xvid encoder deserves its own XVID FourCC by default and a fix would be probably simple (false -> true) somewhere in Avidemux code.

This change would be even utterly trivial, but I'm just not yet convinced that it were necessary. While we're at it, it would rather make sense IMHO to add an option to the xvid plugin to enable frame dropping.

I can nonfirm that avidemux_2.7.4 r190810_win32 has solved the reported issues.

Thanks. A few corrections are still to be done.

Next I would like to ask you, whether it is a correct behaviour (not a bug) that Avidemux is always "Unpacking bitstream" when loading an mpeg4 video even if it does not contain a packed bitstream. Avidemux 2.5 contains a detection of PB.

It is just a debug message which is always printed when the function which checks for PB is not about to return an error.

[mederi]

While we're at it, it would rather make sense IMHO to add an option to the xvid plugin to enable frame dropping.

Well, the more options the better and it would be more universal program. Currently Avidemux offers simplified version of Xvid encoder. There are missing some ASP options (PB, QPel, GMC), but I also would not recommend to use them as there are shitty hardware players, that would refuse to play such files, but it can be useful for somebody.
I checked some more recent AVI files. GSpot program indicates a presence of AVID and a tooltip says:

Indicates presence of AVI"[D]" (dup or dropped) frames: zero length AVI chunks that instruct the player to "repeat previous frame".

So it seem that there are 2 types of frame dropping: Xvid stream (NVOP DF) and AVI container related (AVID). Probably AVID is better supported nowadays.

Then I found out, that Avidemux produces a bit strange AVI files. If I check such a file in AVI FourCC Code Changer program, then there is a weird entry in the second row FourCC Used Codec, a character followed by a long space. One sample even causes an error in MediaInfo program. Please check what is different from the standard produced by Virtual Dub (Virtaul Dub Mod widely used as AVI muxer at its best times).
https://we.tl/t-k9kbWrJGKa

It is just a debug message which is always printed when the function which checks for PB is not about to return an error.

I mean that Avidemux always unpacks bitstreams also with files without PB. If an mpeg4 stream does not contain the Packed Bitstream, then what is Avidemux unpacking? The progress bar [Unpacking bitstream: 0% ---> 100%] appears on the screen and the process can take quite a long time. Does it really do something useful for Avidemux or waste it just time with non-PB mpeg4 streams? Avidemux should detect a presence of PB, then only if it is present, it should unpack it, otherwise skip the unpacking as the stream is already unpacked. Or do I misunderstand it?

[eumagga0x2a]

MediaInfo tool which is available for my Linux distribution doesn't have any difficulties handling any of the two samples you provided. The first apparent difference is audio fcc handler which Avidemux sets to 0 while VirtualDub sets it to 1. I don't think I have time to inspect the source of avic to find out what makes it fail.

Avidemux checks the entire video for packed bitstream, it doesn't unpack it if there is nothing to unpack. I don't know yet whether there is a way to rule out presence of PB without actually checking it.

[mederi]

Thank you for your reply. A MediaInfo guy replied:

I confirm the issue, it is a bad one (crash on Win10 too), trying to fix
that ASAP.

There is just another version of AVI that other softwares have to cope with.

[eumagga0x2a]

There is just another version of AVI that other softwares have to cope with.

It would be very helpful if you could point to exact aspects of the output of the AVI muxer in Avidemux which break the specs (if there are any).

Calling or enumerating things differently is not unusual even in perfectly documented formats like MP4. Recently, a user reported that HEVC videos in MP4 as produced by Avidemux could not be played with QuickTime (yeah, on macOS this still matters). It turned out to be that there are two possible valid fourcc sequences to mark HEVC in MP4 and practically every piece of software supports both. Except QuickTime. We were on the wrong side, now changed to QuickTime's liking.

In general, AVI is a legacy format which should go sooner rather than later. Unfortunately, there are some codecs around which libavformat can't mux into MKV, so we still need the ability to output AVI.

[eumagga0x2a]

So it seem that there are 2 types of frame dropping: Xvid stream (NVOP DF) and AVI container related (AVID). Probably AVID is better supported nowadays.

Avidemux drops true zero-length frames in the AVI (OpenDML) demuxer, which may be not always the right way to handle them (this may result in a highly irregular frame rate, which may pose a bigger problem). I played with disabling this function, identified and fixed some issues I encountered shortly before the 2.7.4 release.

Adding N-VOP support to Xvid encoder is possible and easy, but I don't think this feature really matters nowadays, while a VP9 encoder is sorely missed.

[mederi]

Hi! AVI is still aroud, still alive . I will try to find some information about its structure and implementations. I think, that Xvid/DivX+MP3 in AVI container is a legendary classic that ruled the media world for over a decade at least here in Europe. I think that all techniques and hacks (MP3 with variable bitrate, multiple audio and subtitle streams, packed bistream, B frames, OpenDML AVIv2) of Microsoft AVI are already well known (VirtualDub Mod, AVI-Mux GUI). I wish I could fix it myself, but I am not C/C++ programmer, so I cannot help much here. Nowadays I really prefer free MKV that can store almost any combination of multimedia streams.
I agree with you, that now the fixed Avidemux 2.7.4 can properly decode empty frames and it is not necessary to add them to Xvid encoder since its current implementation is all simplified and sufficient for most users. Thanks.

Avidemux could be one of the first to support a VP9 successor, free codec AV1 and thus help to spread it. VLC already supports AV1 decoding since v3.0.5 (they have developed fast dav1d decoder) and VLC 4 nightlies should already support its decoding and encoding.