XviD 1.3.7 is out!

[hajj_3]

https://downloads.xvid.com/downloads/Xvid-1.3.7-20191228.exe

XviD Codec 1.3.7 changelog:

xvidcore


Fix for a regression in initializing the Inter matrix with MPEG


Quantization

XviD Codec 1.3.6 changelog:


Fix for various, long-standing and potentially critical security vulnerabilities in the decoder (credit to OSS-Fuzz)


Always use .text sections in nasm code for macho target

[filler56789]

I will compile and release the VfW stuff "as-soon-as-possible".

Too bad they have chosen an installer so stupid that cannot be unpacked -_-

[Liisachan]

I will compile and release the VfW stuff "as-soon-as-possible".

Too bad they have chosen an installer so stupid that cannot be unpacked -_-

You mean it's a known problem that VfW doesn't work well with this installer? After I installed 1.3.6 using the above link, XviD.avi (both encoded by 1.3.5 and 1.3.6) becomes blurry and sometimes very blocky. So I re-installed 1.3.5, and the problem is gone.
Encoded with 1.3.6 (Bitstream Version 68) + Decoded by 1.3.5 (Bitstream ver 67) = seems fine (at least not blocky).

[filler56789]

@Liisachan:

I actually meant «an installer so stupid that cannot be unpacked».

In the goode olde days the Xvid "bundles" contained only the core DLL, the VfW applet and the DirectShow decoder. Today the installer contains additional garbage and cannot be unpacked because the inventors of that stupid installer (Bitrock InstallBuilder) are really stupid.

But thanks for reporting the encoding (¿or decoding? :confused:) issue in the newest Xvid, I wasn't aware of that. Probably this time I won't even try to compile it, since it's buggy :(

I stopped using Xvid years ago, for encoding to MPEG-4 ASP I will keep using DivX 6.9.2 "forever". But there are many people who still prefer Xvid, this is the reason why I used to build and release only what really matters to the Windows folks — i.e., the core DLL, the VfW applet and xvid_encraw.exe.

[blob2500]

You mean it's a known problem that VfW doesn't work well with this installer? After I installed 1.3.6 using the above link, XviD.avi (both encoded by 1.3.5 and 1.3.6) becomes blurry and sometimes very blocky. So I re-installed 1.3.5, and the problem is gone.
Encoded with 1.3.6 (Bitstream Version 68) + Decoded by 1.3.5 (Bitstream ver 67) = seems fine (at least not blocky).

Xvid 1.3.7 is out. Xvid bitstream version 69. It fix the issue.

https://downloads.xvid.com/downloads/Xvid-1.3.7-20191228.exe


Xvid-1.3.7-20191228 _Final Release_


This is Xvid 1.3.7 bugfix release. It replaces the previous 1.3.6 stable release.

Changes since 1.3.6:

* xvidcore
- Fix for a regression in initializing the Inter matrix with MPEG
Quantization

Changes since 1.3.5:

* xvidcore
- Fix for various, long-standing and potentially critical security
vulnerabilities in the decoder (credit to OSS-Fuzz)

- Always use .text sections in nasm code for macho target

https://www.xvid.com/

[Liisachan]

In the goode olde days the Xvid "bundles" contained only the core DLL, the VfW applet and the DirectShow decoder. Today the installer contains additional garbage and cannot be unpacked because the inventors of that stupid installer (Bitrock InstallBuilder) are really stupid.

But thanks for reporting the encoding (¿or decoding? :confused:) issue in the newest Xvid, I wasn't aware of that. Probably this time I won't even try to compile it, since it's buggy :(

I stopped using Xvid years ago, for encoding to MPEG-4 ASP I will keep using DivX 6.9.2 "forever". But there are many people who still prefer Xvid, this is the reason why I used to build and release only what really matters to the Windows folks — i.e., the core DLL, the VfW applet and xvid_encraw.exe. Okay. While of course many people are now using newer codecs like x264, I personally like the simple VfW interface e.g. for subtitle typesetting, so AVI is the simplest choice, and I appreciate it that a few people like you are still maintaining those now old-fashioned things.

Xvid 1.3.7 is out. Xvid bitstream version 69. It fix the issue.

https://downloads.xvid.com/downloads/Xvid-1.3.7-20191228.exe

Thanks for addressing the problem quickly. I'll test that shortly. Was that a decoder-side problem? I.e. if someone encoded AVI using 1.3.6, they don't have to re-encode?

EDIT (2020-01-01)
The installer writes bitrock_installer*.log in %TEMP% (or %TMP%), and creates a lot of "rollbackBackupDirectory*" in Program Files\Xvid (at least on my Win7). Like filler56789 said it's not exactly a simple, minimalist installer, although it works fine for me.

[blob2500]

Thanks for addressing the problem quickly. I'll test that shortly. Was that a decoder-side problem? I.e. if someone encoded AVI using 1.3.6, they don't have to re-encode?


The problem was encoder-side (too), In MPEG matrix quantization internal settings.
( view here: http://websvn.xvid.org/cvs/viewvc.cgi/branches/release-1_3-branch/xvidcore/src/quant/quant_matrix.c?view=log )

If you encode with 1.3.6 and you set a MPEG matrix (custom or standard), the inter-matrix values in encoded file are wrongly changed. This reflects it to decoder-side too, because decoder use another matrix values, instead correct values to decode a file ( all MPEG-4 ASP files).

If you used H.263 quantization in your encodings with 1.3.6 I think re-encoding is not necessary. If you used MPEG... I think yes because quantization is wrong.
You can analyze your 1.3.6 encoded files with very well known Avinaptic free software, if you want see their conditions (matrix primarily) :)

[FranceBB]

Although seeing a new release of xvid in 2020 it's a bit weird, I thank you for this bugfix release.
I gotta say that I still use .avi and xvid when I release several version of a file once a week on a website I've been working on ever since 2006 in my spare time.
Back in 2006 there was SD only and I used to release SD xvid BT601 version muxed in .avi and I kept that release.
Nowadays I encode the very same file in SD BT601 SDR xvid, H.264 BT709 SDR HD, H.264 BT709 SDR FULL HD and H.265 BT2020 SDR 4K.
Since it's a fan-based thing from my early age when I was young and I kept it going "for fun", xvid is still totally fine. ;)

[manolito]

Gimme One Good Reason...

Still using XviD VFW from time to time, my preferred version is a Celtic Druid build from 2008:
http://esby.free.fr/CelticDruid/mirror/XviD/XviD.cvs.head.MTKVAQ.exe

I never liked Koepi's builds at that time. They had memory leaks and crashed DVD2SVCD when used together with the CCE SP encoder. Switching to Celtic Druid's builds solved it, and the latest of his builds even has the VAQ patch.

I use it under the latest stable 32-bit StaxRip version which uses VDubMod as the host application. My settings are for max compatibility with HW DVD players (Advanced Simple L5, H.263, VAQ ON, QP and GMC OFF, BVOPs ON at 2, Packed Bitstream OFF). With these settings I never had any problems, with a quantizer of 3 the quality was always pretty good.

Now this latest version 1.3.7 got me curious, I made a few tests using identical settings to my old setup. But I could not see any advantage. The resulting files were a little bigger, encoding time was a little slower, and visual quality was the same.

So why in the world should I switch to this latest version? Because newer is always better? Just give me one good reason... :devil:

[estir]

Why not make PSNR-HVS-M the default metric? Better quality for only slight performance penalty.

[blob2500]

My settings are for max compatibility with HW DVD players (Advanced Simple L5, H.263, VAQ ON, QP and GMC OFF, BVOPs ON at 2, Packed Bitstream OFF). With these settings I never had any problems, with a quantizer of 3 the quality was always pretty good.

AS@L5 is not good for max compatibility with all (and olds) standalone player, because it has VBV maxbitrate: 8.000Mbit/s; For max compatibility VBV bitrate must be 4.854 Mbit/s ;)
For this there are "sub-profiles" of AS: (DivX)Home Theater and Xvid Home profiles (Xvid Home set to max consecutive b-frames = 1 or 2, and Quantization matrix set to MPEG standard/H.263 only); Celtic's and Jawor's builds have good and similar MTK profiles too.

With 2 B-vops: Packed bitstream must be OFF to play fine in most player, but must be ON to play fine in others...
Max compatibility is: 1 B-vops with packed bitstream ON.

--

I use Xvid (1.3.7 now) for my HD encodings/rips (source: usb of DVB-S2 TV decoder) for many years.
I use Xvid HD 720 profile set to compatibility with 720 HD profile of DivX: Max 2 B-vops, packed bitstream (is forced) and I set VAQ, no qpel, standard PAR etc...Custom Matrix and PB are not never a problem in HD DVD/BR player (at least in certified DivX, and in most multimedia players), and I use Sharktooth EQM V3LR matrix: quality is very good. It's a HVS full compliant matrix too :)
I don't use HVS PSNR metric: encoding is too much slow :( , relate to quality that produces.



So why in the world should I switch to this latest version? Because newer is always better? Just give me one good reason... :devil:
IMHO 1.3.2, and newer versions, make best quality (slightly) in 2-pass encoding, in relation to the file size.

[kalehrl]

Has anyone compiled the latest version of xvid encraw for use in, for example, MeGUI?

[estir]

Isn't PSNR-HVS-M is pretty much mandatory with a custom HVS matrix and/or VAQ?

[Liisachan]

The problem was encoder-side (too), In MPEG matrix quantization internal settings.
( view here: http://websvn.xvid.org/cvs/viewvc.cgi/branches/release-1_3-branch/xvidcore/src/quant/quant_matrix.c?view=log )

If you encode with 1.3.6 and you set a MPEG matrix (custom or standard), the inter-matrix values in encoded file are wrongly changed. This reflects it to decoder-side too, because decoder use another matrix values, instead correct values to decode a file ( all MPEG-4 ASP files).

If you used H.263 quantization in your encodings with 1.3.6 I think re-encoding is not necessary. If you used MPEG... I think yes because quantization is wrong.
You can analyze your 1.3.6 encoded files with very well known Avinaptic free software, if you want see their conditions (matrix primarily) :)

Thank you. I did use the standard MPEG matrix when I experienced the problem. So it was an accidental typo in source code, i.e. while changing elem>>1 to max(1,elem)>>1 to make sure the value is non-negative (?), it happened to become max(1,elem>>1). If I understand correctly, the value was 1 for elem<=1 when it should have been 0.

AVI/xvid is still handy and useful for me, as there are a few applications that use VfW (although one can load MP4/MKV e.g. via AVS/ffms2.dll, AVI is simpler, lighter, using less memory). I do still routinely use AVI/xvid e.g. when working internally like typesetting subs, and AVI/Lagarith; even when the final encoding will be in MKV or MP4 with a newer codec. I guess this is like MP3 is still commonly used for some purposes, even though there are Vorbis, AAC, etc.

@manolito
The name Celtic_Druid brings back memories... Many years ago our sever was mirroring Celtic_Druid binaries, though mainly ffdshow.

PS 1.3.5 vs 1.3.7 Quick Tests:
"MPEG" and "H.263" are tested separately. For each:

The .pass files are identical with 1.3.5 or with 1.3.7, except for the comment-header lines.
The final results of 2-pass encoding are bit-identical, except for the bit-stream version strings.
Outputs seem deterministic, i.e. if you encode twice with the exact same settings, then the final results are identical.

The test conditions are old-fashioned: a 640x480 anime episode (~25 mins) was compressed to ~200MiB, with Cartoon mode, Lumi mask, Qpel. VHQ mode=4, VHQ metric=1, VHQ for B=yes, Use chroma motion=yes.

[blob2500]

PS 1.3.5 vs 1.3.7 Quick Tests:
"MPEG" and "H.263" are tested separately. For each:

The .pass files are identical with 1.3.5 or with 1.3.7, except for the comment-header lines.
The final results of 2-pass encoding are bit-identical, except for the bit-stream version strings.
Outputs seem deterministic, i.e. if you encode twice with the exact same settings, then the final results are identical.

I'm not sure 100%, but I think images of video are identical from 1.3.2 version (except perhaps solved bugs) ;)
Last important differences are with 1.3.1 and previous; DCT/iDCT improvement in 1.3.2. "look" image is changed from this version; IMHO is better this new algorithm (better images quality); for someone is better quality of previous algorithm (1.2.x - 1.3.1).
http://websvn.xvid.org/cvs/viewvc.cgi/branches/release-1_3-branch/xvidcore/src/dct/

[Liisachan]

I'm not sure 100%, but I think images of video are bit identical from 1.3.2 version (except perhaps solved bugs) ;)

In a way, that's a good thing too, stable & reliable :) and...

Even though the image quality is identical, updating from 1.3.5 is basically a good move for end-users, as potentially critical security issues have been fixed.
However, since there was an accidental regression in 1.3.6, I was a bit paranoid, wanting to verify that 1.3.7 is okay again.
Also, in that context, the following report by manolito was worrying; but so far I could not reproduce it:

Now this latest version 1.3.7 got me curious, I made a few tests using identical settings to my old setup. But I could not see any advantage. The resulting files were a little bigger

Since 1.3.5 and 1.3.7 write the essentially same file with identical file size in my quick tests, and 1.3.7 is supposed to be more robust, potential vulns fixed, one has a good reason to update to 1.3.7 sooner or later, even if it's just a maintenance release without no encoding-quality changes [and as such there is no need to switch to 1.3.7 urgently].

[blob2500]

In a way, that's a good thing too, stable & reliable :) and...

Even though the image quality is identical, updating from 1.3.5 is basically a good move for end-users, as potentially critical security issues have been fixed.
However, since there was an accidental regression in 1.3.6, I was a bit paranoid, wanting to verify that 1.3.7 is okay again.
Also, in that context, the following report by manolito was worrying; but so far I could not reproduce it:

Since 1.3.5 and 1.3.7 write the essentially same file with identical file size in my quick tests, and 1.3.7 is supposed to be more robust, potential vulns fixed, one has a good reason to update to 1.3.7 sooner or later, even if it's just a maintenance release without no encoding-quality changes [and as such there is no need to switch to 1.3.7 urgently].

I agree with you :)

About that report and question of @manolito:

"So why in the world should I switch to this latest version? Because newer is always better? Just give me one good reason.."


...in summary, I think: Yes produced file is little bigger than Celtic_Druid's Xvid build 1.2. -127 (or more stable final Jawor's Xvid 1.2.2), but 1.3.7 (or 1.3.2/1.3.5) make (slightly) better images; and it's not always true: depends on other variables too: type of video's content, and if encoding is 1 pass (fix quantizer or fix average bitrate) or 2 pass. IMHO 1.3.7 is better in 2 pass mode; 1.2.x is better in 1 pass mode (or first pass of 2-pass encoding) and sometimes vice-versa :) ... but, anyhow, let's talk about minimal differences... for this imho is better to use last, and more bug-free, version. ;)

[manolito]

Thanks everybody for the explanations... :p

Since I only use Xvid for conversions to SD and only in single-pass mode with a constant quantizer, I think that I will stick with the old Celtic Druid version. I have been using it since it came out, and it never failed for myself, plus I never got any complaints by friends who played it on their HW DVD players.

Another thing I like about the Celtic Druid version is that his installer does not install any bloatware. It does not even create a new folder under Program Files, this is my preferred behavior.

[Liisachan]

As of writing this (2020-01-05 UTC), my antivirus ClamWin sees malware in MiniConvert.exe coming with Xvid installers (I'm on Win7). This is likely to be a false positive, as only 2 out of 70 engines "detect" it (Virustotal (https://www.virustotal.com/gui/file/3d6accb2320833f2115ae12e11ac6fce75967e166b38f36f4f2fbfef6a4cf613/detection), Jotti (https://virusscan.jotti.org/en-US/filescanjob/rae69uhyqz) — I don't really trust those sites, just for reference).

Another thing I like about the Celtic Druid version is that his installer does not install any bloatware. It does not even create a new folder under Program Files, this is my preferred behavior.
To be fair, the current installer lets you install files in the folder you select (C:\Program Files\Xvid is the default, but not forced).
Possibly bad things about this installer include:

You can't open it as an archive and extract the actually installed files (as pointed out by filler56789)
When you update or re-install a different version of Xvid, the installer creates subfolder rollbackBackupDirectory, rollbackBackupDirectory1, rollbackBackupDirectory2, etc. and copy the old files there. The uninstaller doesn't clean up these old files.
It doesn't keep the old Xvid encoding settings. The settings will be initialized when you update (this may be necessary and safer in general, though).
It doesn't remember that the user doesn't want auto-update checking, even though it does save old files. You have to manually select "No" every time you install Xvid.

A good thing about this installer is:

It explicitly asks if the user wants auto-update checking. Nowadays, so many applications try to phone home without asking the user. Xvid at least doesn't do such a rude thing.

I couldn't reproduce your results because my tests are only against 1.3.5 (relatively new) and using different settings (2-pass, not 1-pass).

[Motenai Yoda]

The test conditions are old-fashioned: a 640x480 anime episode (~25 mins) was compressed to ~200MiB, with Cartoon mode, Lumi mask, Qpel. VHQ mode=4, VHQ metric=1, VHQ for B=yes, Use chroma motion=yes.
Actually Cartoon mode don't work well on anime content, the same for lumi mask, vaq is better, that or no-aq.

[blob2500]

Cartoon mode works fine only in Anime with "flat" style images, without dept...
Examples: Futurama, Simpsons ;)

In all other cases, it should not be a good choice. ;)

[Motenai Yoda]

Examples: Futurama, Simpsons ;)

and that's why it wasn't named Anime mode but Cartoon mode

[Liisachan]

Actually Cartoon mode don't work well on anime content, the same for lumi mask, vaq is better, that or no-aq. Thanks for your opinions, that's informative. What I did was a regression test, though, not a quality test. Besides, when I say old-fashioned, I mean cell anime from like 30 years ago (1980s, 1990s), probably not what you're thinking when you hear the word "anime".
People often say some settings are better (e.g. 10-bit is better than 8-bit), but if tested in a double-blind way, sometimes (often?) they can't tell which is which :) Anyway the most powerful technique to make old shows look nicer, is not encoder settings, nor filter settings, but may be manual, frame-by-frame restoring/retouching to remove random dirt.

[Asmodian]

It has been a while since I used Xvid but even that old anime is better with film mode, cartoon is really for Simpson's etc.

[Liisachan]

@Asmodian
If you guys (encoding gurus) say so, I assume that is probably true. I still sometimes use old-fashioned xvid.avi as an internal working file for e.g. typesetting, typically a quick 1-pass, q=3. Since it's a temporary file just to check frame timing, and not related to the final format e.g. x264.mkv, I'm not trying to use the best possible settings for xvid. However, if I ever create xvid.avi, xvid.mkv, etc. as the final format, I take your advice seriously and do some blind tests. Thanks!