Xvid 1.3.2 is out

[Przemek_Sperling]

Just downloaded from Jawor's site. No problems so far.

The changelog of the new version:

Xvid 1.3.2 32-bit (built on 01.06.2011)

Patches:
- New profile: Generic Standalone
- MTK profiles for better compatibility
with MediaTek-based standalone players (celtic_druid)
- Updated DivX profiles for better compatibility
with DivX-Certified standalone players
- A separate "Use 4MV" checkbox
for the "INTER4V" macroblock mode
- Adjustable VBV parameters in the "unrestricted" profile
- "Closed GOV" checkbox available
in the "unrestricted" profile
- Checkbox for writing DivX 5 user data to the bitstream
- "DX50" FourCC is forced in DivX profiles
- Encoder can use "MP4V" FourCC
- Maximum number of zones increased to 255
- YV12 decoding fix
- Some cosmetic GUI changes

Changes since 1.3.1:
* xvidcore
- Updated implementation of IDCT/FDCT to match error spec of
MMX/SSE code
- Added "make info" to unix Makefile
- Removed debian directory from release tarballs
- Made multi-threading (pthread support) switchable at compile time
* VFW frontend
- Minor GUI changes
* DShow/MFT frontend
- GUI cosmetics
- Updated MSVC project files with seperate build configs for MFT-enabled
binary

[meshaun]

how to update megui/avidemux/xvid4psp tools to the latest xvid 1.3.2?

especially to megui

[olnima]

@Jawor:
There might be a bug in your xvid 1.3.2 - version:

If I compress with xvid in single-pass-mode (q=3) using VirtualDub and set "VHQ metric" to "PSNR-HVS-M" I get an error
no matter if I'm capturing with this settings directly into xvid or compress an existing video. As I said, Koepis version of xvid 1.3.2 does not show this behavior and runs fine with these settings, also your last 1.3.1-version.

Thanks in advance,
Olnima

Maybe someone else can verify this.

[Jawor]

Maybe someone else can verify this.

I can ;) I just reproduced this.

Thank you, I'll look into it.

<EDIT>
OK, it should be fixed now. 02.06.2011 builds are up.
</EDIT>

[olnima]

yep, confirmed,
thanks Jawor !!! :thanks: :thanks: :thanks:

[henryho_hk]

Modded xvid_encraw (http://www.easy-share.com/1915908197/xvidencraw_xvid132_jawor_hh_20110606.7z) for testing purposes. There are 76 variations (x86/64 at different optimization levels for different CPUs). It seems the static linking really works this time and so you may discard the bundled xvidcore.dll.

Modification list (as far as I remember):
1) Binary mode set on stdin and stdout.
2) Changed the cumulative SSIM variable to a "double".
3) Added true throughput FPS display (#frames divided by seconds).
4) Fixed a bug when both "-start" and "-frames" are specified.
5) Fixed some number formatting at various places.
6) Added output buffering in various places.
7) Added file output for statistics, SSIM and PSNR-HVMS figures.
8) "-ffast-math" (XviD's default) and "-fexcess-precision=fast" (added for GCC 4.6.0) specified.
9) Sorry, no OpenDML AVI output.

The next mod may be "fixing" the chroma optimizer (http://forum.doom9.org/showthread.php?t=136324).

[Boulder]

Does anyone happen to know whether the crappy ESS Vibratto II chipset supports 4MV? I'm unable to test myself as the player is not with me but I need to encode some stuff to watch on it later.

[Jawor]

Does anyone happen to know whether the crappy ESS Vibratto II chipset supports 4MV?
In vanilla builds, the four-vector macroblock mode (4MV) was always enabled at Motion Search Precision 5 and above. Almost everyone leaves Motion Search Precision at 6, so (probably) 99.99% of all existing Xvid encodes use 4MV ;) I didn't test any players based on Vibratto II, but if it didn't support this extremely popular feature, we all would've heard about it a long time ago...

[Boulder]

Thanks, I trust it will work then as I usually had MSP at 5 or 6.

[v0lt]

@Jawor
Version 1.3.2 is much slower than version 1.3.1. :(

Maybe you forgot to compile something?
Made multi-threading (pthread support) switchable at compile time

[Jawor]

Version 1.3.2 is much slower than version 1.3.1. :(
No one else noticed... What are your settings?

Maybe you forgot to compile something?
Made multi-threading (pthread support) switchable at compile time

MSVC builds use native Windows threads instead of the PThread library.

<EDIT>
Actually, you may be right about this PThread thing... Something may be missing in the MSVC project files. Stay tuned.
</EDIT>

<EDIT_2>
Yup, looks like the Visual C++ projects were not adjusted to the latest changes in multithreading code (the HAVE_PTHREAD preprocessor directive was missing). Unless we were supposed to build a single-threaded xvidcore.dll in MSVC by default ;)

Try those builds:
32-bit (http://jawormat.republika.pl/Xvid_132_17062011.exe)
64-bit (http://jawormat.republika.pl/Xvid_132_17062011_x64.exe)
32-bit & 64-bit (http://jawormat.republika.pl/Xvid_132_17062011_x86_and_x64.exe)
</EDIT_2>

[v0lt]

Try those builds:
32-bit (http://jawormat.republika.pl/Xvid_132_17062011.exe)
64-bit (http://jawormat.republika.pl/Xvid_132_17062011_x64.exe)
32-bit & 64-bit (http://jawormat.republika.pl/Xvid_132_17062011_x86_and_x64.exe)
much better now.:thanks:

[Jawor]

much better now.:thanks:

OK, I'll release those builds “officially” ;) Thank you for reporting this. Apparently the MSVC project files were simply forgotten when those changes were made.

Why did nobody else notice this for two weeks? Huh! I know why I didn't... In all my 1.3.2 encodes I used heavy AviSynth filtering that severely bottlenecked my (dual core) CPU.

[PiPPoNe92]

Jawor thanks a lot for your mods, can you optimize xvid version with implemented fillters like "Extra Detail Profile Public"? Thanks in advance

[Jawor]

Unfortunately I have neither the time nor the skills to code any real quality enhancements for Xvid. But the codec is so flexible that encoding quality can be vastly improved by simply tweaking some of the already available options for each source.

Xvid's biggest problem is the obsolete MPEG-4 Part 2 standard with all its constraints and imperfections. To solve this, we'd have to simply abandon it and that would mean breaking compatibility with old standalone players. We already have x264 for that ;)

Cruncher's “Extra Detail Profile” has been dead for years and AFAIK the source code has never been released (although some people were interested in continuing the project).

[PiPPoNe92]

thank you for answer, but I still would like to use Xvid for dvdrip releases because in Italy there are still old standalone players :D

P.S. ..and I'd hate to leave xvid codec! :(

[SilaSurfer]

Now I'm going to sound silly.:rolleyes: Lately I've been experimenting with a specific source which has some short dark static scenes in it. Now those are going to get a low bitrate and look terrible. Lots of blocks and other high compression artefacts from my general Xvid workflow. I understand Xvid settings except using large numer of zones and how to hit a specific file size using them.

Example:

first pass Q3 (I normally use this)

In this case:

zone1 q3
zone2 q2 -difficult area which needs more bitrate to look better
zone3 q3

Can a comp check be performed to hit the right filesize? I normally do a comp check with one zone Q3 for the whole movie then use that with the encode itself. But in this case I can't do anything but apply short zones with Q2 in those short scenes to make those actually look good. I would appreciate any info on this. Thanks.

[Jawor]

I still would like to use Xvid because in Italy there are still old standalone players

I use a 50€ Philips player myself, so I'm also stuck with Xvid (or DVD-Video) for encoding my TV captures :p

Believe me, if I could make Xvid's quality even better, I would...

[PiPPoNe92]

I have done a lot of tests, and I noticed that the strength lies primarily in the codec x264 deblocking (--deblock), in fact if I disable that option, the quality is about similar to xvid at the same bitrate. Everything is to improve the xvid deblocking filter.

[Jawor]

the strength lies primarily in the codec x264 deblocking (--deblock), in fact if I disable that option, the quality is about similar to xvid at the same bitrate. Everything is to improve the xvid deblocking filter.
There's no in-loop deblocking in Xvid and there never will be (the MPEG-4 Part 2 standard doesn't allow it in Simple and Advanced Simple profiles). That means we can only use the deblocking function offered by the decoder we're using (and since a deblocking filter is not enforced by the standard, its presence and features vary from one decoder to another).

Most MPEG-4-capable standalone DVD players use no deblocking whatsoever... and there's nothing we can do about it (and the introduction of an in-loop filter in Xvid would break compatibility with standalones). It's just one of the MPEG-4 Part 2 standard's deficiencies.

When it comes to software decoders, basically we have 3 to choose from:
— ffdshow (tons of deblocking, deringing and postprocessing options)
— Xvid (simple checkboxes for deblocking and deringing luma and chroma planes plus a “Film Effect” checkbox)
— DivX (a checkbox for “adaptive postptrocessing” and a slider for manual postprocessing strength)

[jmac698]

I'm confused, what is the difference between Jawor and Knoepi builds? What's the best version of rawenc to get?
Also, autogk had a feature for adaptive quantization. Is this now included in xvid 1.3.2? Does it also require a modded rawenc to turn the flag on for the feature?
I had a Philips player too. I assume this is MTK chipset. What is the difference between MTK profile and Divx compatible? Is MTK not Divx certified? Is MTK a superset and giving (potentially) a little better quality?
Does anyone else find h.263 matrix looks horrible? I always use mpeg2 matrix and high bitrate (just yesterday I noticed the difference between ~700kbps and 1700kbps easily). I've never experimented with other matrices (since I used a lot autogk and megui can't do what I want).
Thanks.

[Jawor]

I'm confused, what is the difference between Jawor and Knoepi builds?
My builds use an installer created with Inno Setup. Koepi's builds use Isibaar's installer (based on QT libraries that make it 10 times larger ;) ) that includes a “check for updates” feature and Xvid MiniConvert (a wonderful parody of DivX Converter).

My builds include some small additions to the VfW GUI (like e.g. DivX & MTK profiles) and a workaround for decoding YV12 through VfW.

Is MTK not Divx certified?
MediaTek chipsets can cope with encodes created using the “DivX Home Theater” profile and most MTK-based players (except “no-names”) are DivX-Certified.
Is MTK a superset and giving (potentially) a little better quality?
All “MTK” profiles allow Qpel and MPEG/MPEG-Custom quantization. “MTK 6000” profiles also allow the usage of more than 1 B-frame in a row and a much higher bitrate. Yeah, we could say that they're supersets of “DivX Home Theater”.
Does anyone else find h.263 matrix looks horrible?
The “H.263” quantization type always gave a smooth picture. To preserve more detail, we simpy have to use “MPEG” or “MPEG-Custom” (with a high-bitrate matrix like EQM v3 HR).

[jmac698]

Jawor,
Thanks for the reply! I've been wondering those questions for a long time.
I'm wondering a few more things too. How does xvid compare to divx or libavcodec? In programs I'm always asked that question, and I don't know why I should pick either one, for example enabling it in ffdshow or the encoding in AviDemux.

[Jawor]

When it comes to decoding through DirectShow (without any postprocessing), Xvid is the slowest decoder of the three. libavcodec can be 30-55% faster than Xvid. DivX is even faster (about 15% faster than libavcodec). These figures come from tests done with TimeCodec.

Postprocessing capabilities of the three decoders differ considerably (see here (http://forum.doom9.org/showthread.php?p=1508749#post1508749)).

Encoding is another matter... Xvid has been outperforming DivX 4/5/6 through all those years in terms of quality, speed and flexibility. AFAIR libavcodec's own MPEG-4 ASP encoder was always pretty unremarkable (it seems it was just abandoned as there was no need to develop two GPL'd ASP encoders in parallel).

[Jawor]

The latest builds (24.06.2011) shouldn't require the Visual C++ 2008 Runtime for the DirectShow/MFT decoder anymore. It was just another peculiarity of Windows SDK (apparently Microsoft decided that if the source code for strmbase.lib is b0rked, its project file should be b0rked as well...).

[CruNcher]

Though DivX Decoder has a big drawback did you ever tried to playback corrupted streams with it ;) ?

[v0lt]

XviD-1.3.2 from XvidVideo.RU
(http://www.xvidvideo.ru/xvid-video-codec/xvid-1-3-2-x86-x64-stable-release.html)

[vlada]

Hi,

after a very long time I finally found some time to test xvid_encraw with piping. Unfortunately it still doesn't work for me. Only first 40 frames are encoded and then xvid_encraw ends without any error. The command line I use is following:

"c:\avs2pipe.exe" video "c:\video.avs" |
"c:\xvid_encraw.exe" -framerate 23.976 -w 712 -h 304 -frames 184120 -max_bframes 2 -qpel -qtype 1 -turbo -nopacked -progress 10 -stats -pass1 "c:\video.stats"

I get the same results with avs2yuv instead of avs2pipe.

Old xvid_encraw from year 2007 works fine. Do you have any idea what might be wrong?

[henryho_hk]

have u tried it without qpel?

[vlada]

have u tried it without qpel?

I just tried that, QPEL doesn't make any change.

[Gser]

how to update megui/avidemux/xvid4psp tools to the latest xvid 1.3.2?

especially to megui

I tried replacing the files but it seems the command liness are different than what MeGUI tries to use. So MeGUI itself needs to be updated.

[Sharktooth]

megui doesnt support xvid 1.3.x and it will not support it until xvid_encraw will be updated with OpenDML support for files beyond 2Gb.

[henryho_hk]

If there are some tools which can remux xvid_encraw's mpeg4 stream to OpenDML AVI, it would solve our problem temporarily.

[henryho_hk]

Old xvid_encraw from year 2007 works fine. Do you have any idea what might be wrong?

Working fine here. Avisynth 2.6 (20110525) + avs2pipemod-20110703-2 + my own patched xvid_encraw build

Edit: P.S. My patched build has the standard input and output set to "binary" mode.

[almosely]

Hi there,

I am a bit desperate here. Xvid's VBV does not seem to work for me at all. I am trying to convert some movies for my SE W890i mobile phone. I wanna use Xvid, because its faster than DivX and there is VAQ built in. After much trying I figured out that my phone works well with DivX Mobile Profile (VBV max Rate 600, VBV Buffer Size 640). With DivX I use target Quantizer 4.8 at single pass mode. This looks okay and don't reserve more bits at scenes I don't want to have a higher bitrate (e.g. tennis matches get high bitrates when the crowd is shown, with 2pass mode). So, I try to get this working with Xvid. I downloaded Xvid from .ru with some more predefined profiles such as "Xvid Handheld" (VBV Buffer Size 256, VBV max Rate 525) that fits better to my demands than "Xvid Mobile" (VBV max Rate 1303). So I tried everything, but Xvid does not hold to VBV specs. I encoded a movie with "Xvid Handheld"-Profile with targeted 537 kbps. The encoded movie has an avg bitrate of 417 (that would be okay of course). But bitrate viewer shows peaks of 3000 kbps! And avinaptic reports "too many violations" regarding "Xvid Handheld" or the less restricted "DivX Mobile". So, VBV does not work at all with Xvid, at least for me. I tried some other tricks: Single pass 550 kbps with min.Quant 4, e.g., but there are high peaks too.

I am encoding Xvid with VAQ=on, motion search precision 6, VHQ-mode 4, VHQ-metric 1, min-max Quant 2-31 - nothing special ... Other things are restricted through the Handheld-Profile.

How can I get the VBV-Routine working for me or do I have to stick with DivX?

-- edit --

I am using Win7 x64 with VDub 1.9.11 (x32), Xvid CoDec 1.3.2 MTK + DivX profiles (24-06-2011) (x32), AviSynth 2.6.0 ST Alpha 3 (25-05-2011) (x32) (for input, crop, resize).

[hello_hello]

How can I get the VBV-Routine working for me or do I have to stick with DivX?

As far as I know if you want VBV control with Xvid you have to run two passes. It doesn't work in single pass mode.

I think DivX and VBV work in both single pass and 2 pass mode. I think....

[almosely]

As far as I know if you want VBV control with Xvid you have to run two passes. It doesn't work in single pass mode.

I think DivX and VBV work in both single pass and 2 pass mode. I think....

Thats right. But I ran Xvid in 2-pass-mode with profile "Xvid Handheld" and there are regardless many buffer under(over?)flows. Within DivX it works just fine, as 1-pass and as 2-pass. But DivX is slower, has no VAQ and I want better quality through Xvid with VAQ at the same bitrate (best option for me would be target quantizer, but xvid doesn't provide that sadly).

Am I doing anything wrong or is VBV in Xvid buggy?

-- edit --

My mobile phone can play x264-movies, but only with half (original) framerate. 25/30fps - and the video is stuttering, regardless if deblocking is on/off and how many ref-frames etc. So I have to stick with MPEG-4 SP (320x240 max).

-- edit --

Perhaps it's a problem of the XviD-1.3.2 from XvidVideo.RU build and I should try Jawor's?

-- edit --

Oh does it make a difference if I run the first pass in VDub via "Queue batch operation/Run video analysis pass" instead of "Queue batch operation/Save as AVI..."? - in both cases I would adjust Xvid to run a first pass of course. Last time I tried, I chose "Run video analysis pass".

-- edit --

Okay, it does not make any difference if run through "Run video analysis pass" or "Save as AVI...".

But I figured out something weird. The same movie (True Grit), once 2-passed only 8 minutes (the bitrate-heaviest scenes, found out by bitrate viewer) and second time the full movie: The 8-minutes-clip is totally VBV-all-right. The whole movie is totally worse-VBV.

-- edit --

So, I uninstalled the .ru-version and installed Jawor's x86-version on my x64-system (I don't need the 64-bit-version, so I chose the single-installer) - Full installation. The Profiles now are different. The "DivX Mobile" is now the same as within the DivX-CoDec (VBV max Rate 600 e.g.). That's fine. So I gave the 8-minutes-clip a try with 2-pass, the "DivX Mobile"-Profile and a target bitrate of 600 kbps. AviNaptic tells me 2 buffer underflows. Bitrate Viewer tells me a peak of about 900 kbps - thats ok. Now I'll try the whole movie with same prefs ...

-- edit --

Okay, it's still the same problem with Jawor's version. A peak over 3000 kbps and many VBV buffer underflows in avinaptic. It seems I have to stick with DivX :-(

[henryho_hk]

It seems I have to stick with DivX :-(

What resolution is the footage? And what exact encoding parameters are you using?

[almosely]

Okidoke *g

Original footage:

- 1h 45mn, 1298 Kbps, 672 x 288 at 23.976 fps, MPEG-4 Visual (XviD) (AS@L5) BVOP2

To decode I am using:

- AviSynth 2.6.0 ST Alpha 3 (x86)
- ffdshow tryouts (by clsid) r3984 (x86) (libavcodec; no postprocessing)

- A .grf-File made with GraphEdit9 (x86), with Haali Media Splitter (03-03-2011) (x86) (AVI-File) -> ffdshow video decoder
- A .avs-File, opened with VirtualDub 1.9.11 (x86), using this cl: DirectShowSource("Movie.grf", audio=False)

VirtualDub prefs:

- Filter "resize (internal)":

Step 1: New size, absolute (pixels), xxx * 192 (xxx is auto-changed)
Step 2: Filter mode Lanczos3 (sometimes only precise bilinear)
Step 3: Letterbox/crop to size: 320 x 192

- Frame Rate: No change
- Color Depth: Decompression (autoselect), output format (24 bit RGB 888)

- Compression: Xvid CoDec 1.3.2 (Jawor) (24-06-2011) (x86)

Xvid prefs:

- Profile "DivX Mobile"; Adaptive Quant. "Variance-Masking"
- Encoding type "Twopass - 1st pass" ... and of course "Twopass - 2nd pass" with Target bitrate 600 kbps
- No Zone options
- Quality preset (user defined):

Motion search precision "6 - Ultra High"
VHQ mode "4 - Wide Search"
VHQ metric "1 - PSNR-HVS-M"
Use chroma motion "Yes"
Use 4MV "Yes"
Maximum I-Frame interval "240"

Min/Max I-frame/P-frame quantizer: 2-31
Trellis quant. "Yes"

The resulting AVI has the following specs:

- 1h 45mn, 509 Kbps, 320 x 192 at 23.976 fps, MPEG-4 Visual (DivX5) (Simple@L3)

http://img845.imageshack.us/img845/3764/bitrateviewerscreenshot.jpg (http://imageshack.us/photo/my-images/845/bitrateviewerscreenshot.jpg/)

Uploaded with ImageShack.us (http://imageshack.us)

And the complete Avinaptic-Report:


[ About file ]

Name: Xvid Jawor DivX Mobile 2pass minQ2.avi
Date: Sun, 02 Oct 2011 01:32:11 +0200
Size: 405,680,666 bytes (386.887 MiB)

[ Magic ]

Tipo file: RIFF (little-endian) data, AVI, 320 x 192, 23.98 fps, video: DivX 5

[ Generic infos ]

Duration: 01:45:18 (6317.514 s)
Container: AVI OpenDML
AVI has index: Yes
Total tracks: 1
Track nr. 0: video
Junk: VirtualDub build 32842/release

[ Relevant data ]

Resolution: 320 x 192
Width: multiple of 32
Height: multiple of 32
Average DRF: 2.83
Standard deviation: 1.588
Std. dev. weighted mean: 1.586

[ Video track ]

FourCC: xvid/DX50
Resolution: 320 x 192
Frame aspect ratio: 5:3 = 1.667
Pixel aspect ratio: 1:1 = 1
Display aspect ratio: 5:3 = 1.667
Framerate: 23.976 fps
Total frames: 151,469
Stream size: 401,961,147 bytes (383.34 MiB)
Bitrate: 509.011 kbps
Qf: 0.346
Key frames: 1,511 (0; 240; 480; 513; 587; ... 151455)
Null frames: 0
Min key int: 1
Max key int: 240
Avg key int: 100.244
Delay: 0 ms

[ Video bitstream ]

Bitstream type: MPEG-4 Part 2
User data: DivX503b1393
User data: XviD0064
Packed bitstream: No
QPel: No
GMC: No
Interlaced: No
Aspect ratio: Square pixels
Quant type: H.263
Total frames: 151,469
Drop/delay frames: 0
Corrupt frames: 0

I-VOPs: 1511 ( 0.998 %)
P-VOPs: 149958 ( 99.002 %) ####################
B-VOPs: 0 ( 0.000 %)
S-VOPs: 0 ( 0.000 %)
N-VOPs: 0 ( 0.000 %)

[ DRF analysis ]

average DRF: 2.83
standard deviation: 1.588
max DRF: 15

DRF<2: 0 ( 0.000 %)
DRF=2: 87287 ( 57.627 %) ############
DRF=3: 46022 ( 30.384 %) ######
DRF=4: 5317 ( 3.510 %) #
DRF=5: 1232 ( 0.813 %)
DRF=6: 4194 ( 2.769 %) #
DRF=7: 3275 ( 2.162 %)
DRF=8: 512 ( 0.338 %)
DRF=9: 1968 ( 1.299 %)
DRF>9: 1662 ( 1.097 %)

I-VOPs average DRF: 3.426
I-VOPs std. deviation: 2.191
I-VOPs max DRF: 15

P-VOPs average DRF: 2.824
P-VOPs std. deviation: 1.58
P-VOPs max DRF: 15

[ Profile compliancy ]

Selected profile: DivX Mobile
Resolution: Ok
Framerate: 23.976 <> 30
Buffer underflow: 00:00:31 (frame 739)
Buffer underflow: 00:02:06 (frame 3020)
Buffer underflow: 00:02:07 (frame 3056)
Buffer underflow: 00:02:09 (frame 3082)
Buffer underflow: 00:02:10 (frame 3105)
Buffer underflow: 00:02:10 (frame 3127)
Buffer underflow: 00:02:11 (frame 3149)
Buffer underflow: 00:02:12 (frame 3170)
Buffer underflow: 00:02:13 (frame 3194)
Buffer underflow: 00:02:14 (frame 3223)
Buffer underflow: 00:02:16 (frame 3266)
Buffer underflow: 00:02:18 (frame 3306)
Buffer underflow: 00:02:19 (frame 3341)
Buffer underflow: 00:02:21 (frame 3379)
Buffer underflow: 00:02:51 (frame 4101)
Buffer underflow: 00:02:54 (frame 4164)
Buffer underflow: 00:03:01 (frame 4334)
Buffer underflow: 00:03:03 (frame 4389)
Buffer underflow: 00:03:05 (frame 4424)
Buffer underflow: 00:03:10 (frame 4551)
Error: Too many violations

This report was created by AVInaptic (25-07-2011) on 4-10-2011 17:20:13

[henryho_hk]

You specify 600kbps two-pass but end up with 509kbps. Try turning VAQ off.

[almosely]

You specify 600kbps two-pass but end up with 509kbps. Try turning VAQ off.

THAN I can use DivX again ... VAQ is the main reason why I want to use Xvid: Same bitrate, better quality. Or in this case: Same quality, lower bitrate.

But all stated above was not pointing to VAQ ... It's the peaks and buffer underflows not the less bitrate than targeted what I am worried about.

-- edit --

I think I could solve my problem. If I am using a target bitrate, then VBV gets underflows, regardless of 2pass and DivX Mobile profile. If I am using a target (file)size, e.g. 55% of the 1st pass' filesize, then everything is fine with the VBV - at least at this first try a few minutes ago.

[henryho_hk]

Yes, VAQ should be offering better visual quality. On the other hand, you may also want to know that VAQ leads to a lower SSIM score in many cases.

[almosely]

VAQ is generally used with x264. It's a compressed file - why don't use the features the codec is offering to get the smallest file with good quality. It's for my cell phone ... I sit down, take a few minutes, watch the newly encoded material on my phone and if it looks okay to me, than the encoding settings are fine. BUT: VAQ was not my concern *g I don't now why you came to VAQ when its obviously a bug in xvid causing these VBV errors at target bitrate mode in 2-pass. Target size works alright. I did not know that.

[Rumbah]

henryho_hk, you posted your modded xvidencraw before Jawor fixed the multithreading for his build. Does multithreading work correctly with your 6/6/11 build or is there a newer one?

Thanks

[henryho_hk]

Gotta check. I was not too keen on xvid multithreading because

(1) Unlike squid's great mod, this version does not have threaded input. We probably need to use it together with avs(26)pipe(mod).
(2) I am mostly using multiple single-threaded encodes which seems more efficient in my machine.

I will make newer compiles if necessary.

[kalehrl]

No one else noticed... What are your settings?



MSVC builds use native Windows threads instead of the PThread library.

<EDIT>
Actually, you may be right about this PThread thing... Something may be missing in the MSVC project files. Stay tuned.
</EDIT>

<EDIT_2>
Yup, looks like the Visual C++ projects were not adjusted to the latest changes in multithreading code (the HAVE_PTHREAD preprocessor directive was missing). Unless we were supposed to build a single-threaded xvidcore.dll in MSVC by default ;)

Try those builds:
32-bit (http://jawormat.republika.pl/Xvid_132_17062011.exe)
64-bit (http://jawormat.republika.pl/Xvid_132_17062011_x64.exe)
32-bit & 64-bit (http://jawormat.republika.pl/Xvid_132_17062011_x86_and_x64.exe)
</EDIT_2>
I seem to be having the same problem.
Xvid 1.3.2 is some 20-30% slower than the "old one" which is 1.2.2+VAQ. I'm using megui and I downloaded xvid_encraw from you web page. This version is supposed to have the bug fixed but apparently not for me. I replaced xvid_encraw and xvidcore.dll in megui folder and started encoding. To verify the findings, I ran the encode with original megui xvid and I got fps of around 90-95. With 1.3.2, I get 65-70. When I monitor processor usage, it is significantly lower with 1.3.2 than with 1.2.2. I have also xvid 1.2.1 installed on my pc (from autogk pack) so maybe that is causing these problems. When I run the same encode with autogk, I get the same fps as with xvid 1.2.2 in megui. Any ides how I can fix this problem? Thank you

[kalehrl]

Is this a known issue with 1.3.2 xvid_encraw or not?
I can't get it to use full processing power of my 2-core processor like 1.2.2 version uses.
@v0lt seems to be using "full" Jawor's 1.3.2 build, not xvid_encraw.

[henryho_hk]

is your 1.2.2 the stock build or squid's mod?

squid's modded version has separate thread for input.

[kalehrl]

It is the one which comes with MeGUI.
I believe I saw it flagged as 1.2.2 + VAQ.
I've just uninstalled xvid which comes with AutoGK and installed Jawors xvid 1.3.2 64bit.
I'm running an encode with AutoGK which is now using the latest xvid and the processor is fully utilised.
It will be done in a couple of minutes and the size will probably be OK.

EDIT:
OK, encode done and it is the right size. I was afraid it wouldn't be correct because of the different xvid version than the one which comes bundled with autogk. :)
I don't think I will fiddle any longer with the xvid_encraw becuase autogk works without problems with the laetst xvid.
It just goes to show how great a tool autogk is.

Just one thing bothers me.
With the encode finished, I opened 'configure xvid encoder' and saw that autogk was using xvid mobile preset with some changes so I wonder if VBR buffer sizes and other restrictive features were applied.

[henryho_hk]

The "stock" version of xvid_encraw does not write correct index when the file size is over 1GB (not really a problem because AutoGK will mux in the sound track and produce a new AVI file anyway). Also, it wraps around silently and write from the file start again when the file size goes over 2GB (or 4GB, I don't remember...). Take care.