Xvid 1.3 RC1?

[hajj_3]

It seems as though xvid 1.3 might be at RC1 stage according to: http://www.free-codecs.com/download/xvid_codec.htm

hope someone can benchmark it to v1.22 with a dual core and quad core cpu.

[Przemek_Sperling]

In terms of speed? I think it can be a bit hard because there are different selectable optimisations that can be chosen in setup and nobody can guarantee that the "optimal" settings are really the best. BTW, I have doubts if I should choose SSE+SSE2+SSE3 or SSE+SSE2+SSE3+SSSE3 because my AMD Athlon II does not utilize SSSE3 and uses SSE5 instead http://en.wikipedia.org/wiki/SSE5
Anyway, this release is a bit faster that Xvid 1.22 but I do not know if it is because of the instructions set or because of better multithreading (it utilizes my triple core CPU in 65-70%).

[ilkertezcan]

This is Jawor's xvid build. Major bug: Not fluid when playing compressed video that endoded with this build.

Sample video: http://www.megaupload.com/?d=953BWWFU

Contain of package;

jawor_build_xvid13rc1.avi = Compressed with Jawor build (http://jawormat.republika.pl/xvid.html). Look carefully to the underwater effect. Not fluid.

xvidvideoru_build_xvid13cvs.avi = Compressed with Xvidvideo.ru build (http://www.xvidvideo.ru/xvid-video-codec/xvid-1-3-0-cvs-101030-05-48-vaq-mtk-x86-x64-update.html). Look carefully to the underwater effect. Fluid, no freeze.

P.S.: This sample vide compress settings is same(2-pass, etc)...

[Jawor]

BTW, I have doubts if I should choose SSE+SSE2+SSE3 or SSE+SSE2+SSE3+SSSE3 because my AMD Athlon II does not utilize SSSE3
Then choose "SSE+SSE2+SSE3". Those options only mean that I used -msse (-msse2, -msse3, -mssse3) switches in the building process. The speed difference isn't big. It's the hand-written assembler optimizations that really matter, and those are always built-in and automatically used when Xvid detects a CPU that supports them.
P.S.: This sample vide compress settings is same(2-pass, etc)...
But what were those settings? ;) And did you use xvid_encraw (whose build) or VfW?

The fluidity seems to return after unpacking Packed Bitstream. I've seen this problem with the latest xvid_encraw and PB, but I'm not sure what really causes it.

[mihanja80]

When comparing the data sources in the program AvsP (open with DirectShowSource ("F: \ Dimon \ jawor_build_xvid13rc1.avi"))
Visually the differences are not observed
:)
Maybe the problem with the decoding?

I use translate.google.com

[Jawor]

Visually the differences are not observed


The frames are OK. Something's wrong with writing Packed Bitstream, 'cause after unpacking it with MPEG-4 Modifier the stuttering is gone. It doesn't return after “packing” the bitstream again with MPEG-4 Modifier, so it definitely looks like xvid_encraw has a problem with writing PB.

[mihanja80]

http://i.piccy.info/i5/67/13/931367/01_500.jpg (http://piccy.info/view3/931367/047aa54838915d4ee50c44ef0d218e36/)

ilkertezcan, GSpot270a shows inclusion Packed Bitstream and the presence of N-Vpos in both cases.

Disabling Packed Bitstream (by using the -nopacked switch) is very important. http://www.videoaudio.pl/forum/index.php?s=&showtopic=4720&view=findpost&p=54065


ilkertezcan,
Show script (log) coding.
How do you get the presence of N-Vpos?


Try now these settings apply:
-qtype 0 -vhqmode 4 -nopacked -bvhq -bquant_ratio 162 -bquant_offset 0 -masking 2 -imin 2 -pmin 2 -bmin 2

-bitrate 800 -qtype 0 -vhqmode 4 -nopacked -bvhq -bquant_ratio 162 -bquant_offset 0 -masking 2 -vbvmax 4854000 -vbvsize 3145728 -imin 2 -pmin 2 -bmin 2

I use translate.google.com

[thewebchat]

Jawor, can you build Xvid 1.3RC1 for AMD64 as well?

[Jawor]

Jawor, can you build Xvid 1.3RC1 for AMD64 as well?
Yes, but I don't have 64-bit Windows installed, so someone else has to do some basic testing (like checking if it even works). And I won't able to build a 64-bit DirectShow decoder right now (Microsoft's SDKs are buggy, building a working strmbase.lib is a nightmare, especially for a platform that I don't have access to).

Here (http://jawormat.republika.pl/Xvid_130_RC1_08012011_x64.exe) is an experimental build.

[thewebchat]

Yes, but I don't have 64-bit Windows installed, so someone else has to do some basic testing (like checking if it even works). And I won't able to build a 64-bit DirectShow decoder right now (Microsoft's SDKs are buggy, building a working strmbase.lib is a nightmare, especially for a platform that I don't have access to).

Here (http://jawormat.republika.pl/Xvid_130_RC1_08012011_x64.exe) is an experimental build.

I can't test it because it doesn't come with xvid_encraw :(

Also, it would be easier if you just provided a zip'd bundle since 7-zip can't extract your installer for some reason.

[Jawor]

I can't test it because it doesn't come with xvid_encraw :(

Also, it would be easier if you just provided a zip'd bundle since 7-zip can't extract your installer for some reason.

OK, here (http://jawormat.republika.pl/130_RC1_x64.7z) it is.

[thewebchat]

Tested it, and it works.

[Jawor]

Tested it, and it works.

Thank you.

It would be great if anyone tested the 64-bit VfW version that comes in this installer (http://jawormat.republika.pl/Xvid_130_RC1_08012011_x64.exe).

[mihanja80]

Jawor,
I do not know what needed to be tested but Xvid_130_RC1_08012011_x64.exe Works

capture-11.avi (http://narod.ru/disk/3007415001/capture-11.avi.html)

[Przemek_Sperling]

Then choose "SSE+SSE2+SSE3". Those options only mean that I used -msse (-msse2, -msse3, -mssse3) switches in the building process. The speed difference isn't big. It's the hand-written assembler optimizations that really matter, and those are always built-in and automatically used when Xvid detects a CPU that supports them.


Thank you for your explanation. Everything is clear now.

I confirm that the 64-bit version of Xvid works with my Windows 7 64-bit.

[ilkertezcan]

@Jawor: Thank you for your interest. Firstly I'm sorry my bad english. I hope, I can write correctly.

I don't use xvid_encraw.exe. My encoder: Virtualdub 1.10.0

Yeah, I always use Packed Bitstream. Why? The Shift+Left+Right Arrows buttons directly go to keyframes when frames between navigation on Virtualdub. Exactly the way I want... And you are right: I disabled Packed Bitream and no fluid problem! Thank you!

The real strange situation: Even if packed bitstream is enabled in xvidVideoRU builds, there is not fluid problem. I don't know why. I'm not expert like you. :)

My sample video: MPEG2 from DVB. I extracted (stream copy) a small piece through Avidemux from my capture video. So you can want test, here(screenshots of my settings is included in the package):

http://www.megaupload.com/?d=PDHQ3KYE

[Jawor]

I do not know what needed to be tested but Xvid_130_RC1_08012011_x64.exe Works
I confirm that the 64-bit version of Xvid works with my Windows 7 64-bit.
That's great. Thank you both.
I don't use xvid_encraw.exe. My encoder: Virtualdub 1.10.0
That's really strange, because I noticed the PB problem only with xvid_encraw, not the VfW codec (I've always been using the stable VirtualDub version).

Maybe it's because the experimental VD version... or it is another problem caused by the GCC compiler (it's been giving me lots of headaches lately). Here (http://jawormat.republika.pl/Xvid_130_RC1_09012011.exe) is an MSVC 2008 build.

[ilkertezcan]

@Jawor: Thank you for your answer and new build.

http://jawormat.republika.pl/Xvid_130_RC1_09012011.exe = I tried this MSVC 2008 build with both versions of VirtualDub (Stable & Expermential).
Packed Bitstream issues is still same. I'm sorry for the trouble I gave you. :(

I tested all builds of xvid on Virtualdub 1.9.11 (with Xvid VFW GUI). Koepi, Jawor, XvidVideoRU... (GCC & MSVC builds too).
All video: http://www.megaupload.com/?d=CQH1GWCW

package contents:
* jawor_122.avi
* jawor_122_NOpackedbitstream.avi
* jawor_13rc1_gcc.avi
* jawor_13rc1_gcc_NOpackedbitstream.avi
* jawor_13rc1_msvc2008.avi
* jawor_13rc1_msvc2008_NOpackedbitstream.avi
* koepi_122.avi
* xvidvideoru_13cvs_gcc.avi
* xvidvideoru_13cvs_msvc2008.avi
* xvidvideoru_13cvs_msvc2010.avi

More strange state: Even if Packed Bitstream is disabled, the video (more) non-fluid play with compressed Jawor 1.2.2.
This problem does not exist in the 1.3 RC1 (of course, only if packed bitstream is disabled). I still didn't understand why the issues. :confused:
I'm sorry to waste your time...

[Przemek_Sperling]

I would like to ask about the versioning of writing libraries. Usually when I coded films with Xvid the writing library was described (checked with The KMPlayer, PotPlayer, etc.) as Xvid 1.2.2, Xvid 1.30 build 55, etc. In case of Xvid 1.30 RC1 the new library is described as Xvid 61 (sic!). Is it OK?

[Jawor]

I still didn't understand why the issues.
Neither do I, but... I think we can continue this wild goose chase for a little while longer ;) Here (http://jawormat.republika.pl/Xvid_130_RC1_10012011_Vanilla.exe) is an installer containing an unpatched build compiled with MSVC 2008 using project defaults. If this build doesn't help, the problem must lie somewhere else.

I haven't been able to reproduce the problem with PB through VfW (I tried both with Cartoon Mode and without it). All files I encoded through VfW play fine both with ffdshow and with the Xvid decoder.

Usually when I coded films with Xvid the writing library was described (checked with The KMPlayer, PotPlayer, etc.) as Xvid 1.2.2, Xvid 1.30 build 55, etc. In case of Xvid 1.30 RC1 the new library is described as Xvid 61 (sic!). Is it OK?

Yes, it's OK. It's the so-called “bitstream version” number and it is increased every time an encoder bug is fixed, so that decoders could recognize earlier (buggy) encoder versions and use workarounds for those bugs. Of course creating such workarounds requires additional work from authors of software decoders (I think ffdshow uses workarounds for some very old Xvid bugs).

[ilkertezcan]

Again, thanks. I tried lastest build (Vanilla/unpatched build) and finally fixed!
No fluid problem! Furthermore, even if packed bitstream is enabled, no fluid problem. :)
Compressed videos with this build(Besides, included "no cartoon mode"): http://www.megaupload.com/?d=BVIWEE4L

[Jawor]

Again, thanks. I tried lastest build (Vanilla/unpatched build) and finally fixed!
No fluid problem! Furthermore, even if packed bitstream is enabled, no fluid problem. :)


That's good news. The only significant patch that I've been using in xvidcore.dll was taken from celtic_druid's MTK profiles, maybe that was the cause. I don't think I screwed up something in xvidvfw.dll, but I'll take a closer look at it as well.

<EDIT>
I think it's time for seppuku :stupid:

I created the “Write DivX 5 user data to the bitstream” checkbox in the hope that only advanced users would uncheck it (it's checked by default). It is “hidden” under the Other options button. Unfortunately I didn't predict that some people would created PB files with this option unchecked. Software (and possibly hardware) decoders don't like such files.

A fixed build (that forces DivX 5 user data when PB is enabled) will be up in a few hours.
</EDIT>

[henryho_hk]

Jawor, I tested both the 09 Jan and 11 Jan versions of xvid_encraw and xvidcore.dll. There seems to be artifacts with QPel + slices:


xvid_encraw.exe -progress 100 -max_key_interval 240 -bquant_ratio 162 -bquant_offset 0 -max_bframes 2 -vhqmode 1 -qtype 0 -metric 0 -nopacked -i m0.avs -pass1 m0.pass -zones 0,q,3,K -quality 5 -nochromame -turbo -slices 4
xvid_encraw.exe -progress 100 -max_key_interval 240 -bquant_ratio 162 -bquant_offset 0 -max_bframes 2 -vhqmode 1 -qtype 0 -metric 0 -nopacked -i m0.avs -pass2 m0.pass -bitrate 2200 -quality 6 -bvhq -avi m0-s4.avi -slices 4
xvid_encraw.exe -progress 100 -max_key_interval 240 -bquant_ratio 162 -bquant_offset 0 -max_bframes 2 -vhqmode 1 -qtype 0 -metric 0 -nopacked -i m0.avs -pass2 m0.pass -bitrate 2200 -quality 6 -bvhq -avi m0.avi
xvid_encraw.exe -progress 100 -max_key_interval 240 -bquant_ratio 162 -bquant_offset 0 -max_bframes 2 -vhqmode 1 -qtype 0 -metric 0 -nopacked -i m0.avs -pass2 m0.pass -bitrate 2200 -quality 6 -bvhq -qpel -avi m0-qp.avi
xvid_encraw.exe -progress 100 -max_key_interval 240 -bquant_ratio 162 -bquant_offset 0 -max_bframes 2 -vhqmode 1 -qtype 0 -metric 0 -nopacked -i m0.avs -pass2 m0.pass -bitrate 2200 -quality 6 -bvhq -qpel -avi m0-qp-s4.avi -slices 4


"m0.avs" is wrapping a small 656x272 AVI. "m0-qp-s4.avi" is having artifacts of thin horizontel strips. Can anyone else reproduce it?

Sample (http://img522.imageshack.us/i/66351789.png/)

[Jawor]

Builds with that stupid Packed Bitstream bug fixed are up.
Can anyone else reproduce it?


I tried (with my latest 32-bit MSVC 2008 build), but I couldn't reproduce such artifacts (Intel E2160, 32-bit Vista). If anyone else tests Qpel + Slices, please let us know whether it works fine or not.

Slices are a brand new feature in Xvid, so some bugs can happen... and most people probably won't use them anyway because of incompatibility with many (if not all) standalone players. That makes hunting down and squashing the bug much more difficult.

[ilkertezcan]

Thanks for patched 11.01.2011 build. I tested. Packed Bitstream (and fluid) issue completely are fixed. Thank you very much.

Also, I tried "Write DivX 5 user data to the bitstream" option. The video save is same whether or not this setting check or uncheck.
(Compared with a Hex Editor (http://mh-nexus.de/en/hxd/) software. Analyz menu -> File Compare).

P.S.: Also, thanks for 'thanks to' part in readme.txt. ;)

[Jawor]

Also, I tried "Write DivX 5 user data to the bitstream" option. The video save is same whether or not this setting check or uncheck.
(Compared with a Hex Editor (http://mh-nexus.de/en/hxd/) software. Analyz menu -> File Compare).


That's because writing DivX 5 user data is now forced when we use Packed Bitstream. That's what this fix is about ;)

My mistake was allowing people to uncheck the Write DivX 5 user data... checkbox with Packed Bitstream checked. Decoders couldn't properly recognize files with PB without a DivX 5 user data string ending with p (like DivX503b1393p).

[ilkertezcan]

I understand better now. Thanks too for this detailed info.

[HarryM]

Why is XviD 1.3 underwrited as "release candidate 1", when I see (posts here), that 1.3 is still too buggy? Maybe better "beta 1".:confused:

[Jawor]

Why is XviD 1.3 underwrited as "release candidate 1", when I see (posts here), that 1.3 is still too buggy? Maybe better "beta 1".:confused:
One “bug” was caused only by GCC's -O3. Another “bug” was caused by unchecking Write DivX 5 user data with Packed bitstream enabled, which shouldn't be done. Both had nothing to do with the vanilla 1.3.0 RC1 source code (and both are fixed in my latest build).

There may be a bug with slices (that AFAIK no one has been able to reproduce), but most users probably won't use this feature (it's incompatible with standalone players).

[mihanja80]

I have artifacts when encoding XviD1.3 any assembly !!!
Example: Source - sample (http://ge.tt/#29Cch95)

http://rghost.ru/4114029/thumb.png (http://rghost.ru/4114029.view)


screenshot comparison in AvsP (http://screenshotcomparison.com/comparison/23396)
screenshot comparison in Media Player Classic - Home Cinema (http://screenshotcomparison.com/comparison/23400)


XviD 1.3
PLATFORM
------------------------------
OS: Microsoft Windows NT 6.1.7600.0
OEMCodePage: 866
Language: RUS
DecimalSeparator: ,
Framework: 2.0.50727.4952
Processors: 2
SystemDrive: C:

XVID4PSP
------------------------------
Version: 5.10.211.2
Created: 26.01.2011 18:07:34
TempPath: F:\Temp
AppPath: C:\Program Files (x86)\XviD4PSP 5

FILES
------------------------------
Fawni - Serious.mkv >
Fawni - Serious3.avi

TASK
------------------------------
Format: AVI Hardware
Duration: 00:03:16:600 (4915)
VideoDecoder: FFmpegSource2
Resolution: 1280x720 > 720x408
Aspect: 1.7778 > 1.7647
VCodecPreset: Custom XviD CLI
VEncodingMode: TwoPass
VideoCodec: h264 > XviD
VideoBitrate: 3170 > 1900
Quality: 0.138 > 0.259
Framerate: 25.000
SourceType: PROGRESSIVE
FieldOrder: UNKNOWN
AudioDecoder: bassAudioSource
AEncodingPreset: MP3 CBR 128k
AudioCodec: FLAC > MP3
AudioBitrate: 0 > 128
Samplerate: 48000
Channels: 2

SCRIPT
------------------------------
import("C:\Program Files (x86)\XviD4PSP 5\dlls\AviSynth\functions\AudioFunctions.avs")
import("C:\Program Files (x86)\XviD4PSP 5\dlls\AviSynth\functions\VideoFunctions.avs")
loadplugin("C:\Program Files (x86)\XviD4PSP 5\dlls\AviSynth\plugins\bass\bassAudio.dll")
loadplugin("C:\Program Files (x86)\XviD4PSP 5\dlls\AviSynth\plugins\FFMS2.dll")
import("C:\Program Files (x86)\XviD4PSP 5\dlls\AviSynth\plugins\FFMS2.avsi")

video = FFmpegSource2("C:\Users\Mihanja80\Downloads\Fawni - Serious.mkv", rffmode=0, cachefile="F:\Temp\fawni - serious.mkv.ffindex").AssumeFPS(25.000)
audio = bassAudioSource("F:\Temp\0069_0.flac")
AudioDub(video, audio)

ConvertToYV12()

###[FILTERING]###
###[FILTERING]###

Spline64Resize(720, 408)

AUDIO ENCODING
------------------------------
Encoding audio to: F:\Temp\0071.mp3
MP3 128kbps 2ch 16bit 48000khz

lame.exe: -m s -b 128 -q 2 - "F:\Temp\0071.mp3"

VIDEO ENCODING
------------------------------
Encoding video to: F:\Temp\0071.avi
XviD 1900kbps 720x408 25.000fps (4915 frames)

...first pass...

xvid_encraw.exe: -pass1 "F:\Temp\0071_1.log" -nopacked -bquant_ratio 162 -bquant_offset 0 -qtype 1 -quality 5 -vhqmode 1 -masking 2 -metric 1 -max_key_interval 250 -threads 4 -i "F:\Temp\0071.avs" -o NUL

Tot: enctime(ms) =31251.00, length(bytes) = 75684418
Avg: enctime(ms) = 6.36, fps = 157.27, length(bytes) = 15398
I frames: 163 frames, size = 41405/6749103, quants = 2 / 2.00 / 2
P frames: 1885 frames, size = 22260/41961788, quants = 2 / 2.00 / 2
B frames: 2850 frames, size = 9464/26973391, quants = 3 / 3.00 / 3
N frames: 17 frames, size = 8/ 136

...last pass...

xvid_encraw.exe: -pass2 "F:\Temp\0071_1.log" -nopacked -bquant_ratio 162 -bquant_offset 0 -qtype 1 -quality 6 -vhqmode 4 -masking 2 -metric 1 -max_key_interval 250 -bvhq -bitrate 1900 -vbvmax 4854000 -vbvsize 3145728 -vbvpeak 2359296 -chigh 20 -clow 7 -imin 2 -pmin 2 -bmin 2 -threads 4 -i "F:\Temp\0071.avs" -avi "F:\Temp\0071.avi"

Tot: enctime(ms) =111508.00, length(bytes) = 46670604
Avg: enctime(ms) = 22.69, fps = 44.08, length(bytes) = 9495
I frames: 163 frames, size = 34233/5580126, quants = 2 / 2.72 / 3
P frames: 1885 frames, size = 13378/25218003, quants = 2 / 3.14 / 5
B frames: 2850 frames, size = 5569/15872339, quants = 3 / 4.37 / 8
N frames: 17 frames, size = 8/ 136

MUXING
------------------------------
Video file: F:\Temp\0071.avi
Audio file: F:\Temp\0071.mp3
Muxing to: F:\Dimon\Fawni - Serious3.avi
Please wait...

TIME
------------------------------
Общее время кодирования: 4 min 1 sec
Файл получился на: 47.75 mb



XviD 1.2
PLATFORM
------------------------------
OS: Microsoft Windows NT 6.1.7600.0
OEMCodePage: 866
Language: RUS
DecimalSeparator: ,
Framework: 2.0.50727.4952
Processors: 2
SystemDrive: C:

XVID4PSP
------------------------------
Version: 5.10.211.2
Created: 26.01.2011 18:07:34
TempPath: F:\Temp
AppPath: C:\Program Files (x86)\XviD4PSP 5

FILES
------------------------------
Fawni - Serious.mkv >
Fawni - Serious4.avi

TASK
------------------------------
Format: AVI Hardware
Duration: 00:03:16:600 (4915)
VideoDecoder: FFmpegSource2
Resolution: 1280x720 > 720x408
Aspect: 1.7778 > 1.7647
VCodecPreset: Custom
VEncodingMode: TwoPass
VideoCodec: h264 > XviD
VideoBitrate: 3170 > 1900
Quality: 0.138 > 0.259
Framerate: 25.000
SourceType: PROGRESSIVE
FieldOrder: UNKNOWN
AudioDecoder: bassAudioSource
AEncodingPreset: MP3 CBR 128k
AudioCodec: FLAC > MP3
AudioBitrate: 0 > 128
Samplerate: 48000
Channels: 2

SCRIPT
------------------------------
import("C:\Program Files (x86)\XviD4PSP 5\dlls\AviSynth\functions\AudioFunctions.avs")
import("C:\Program Files (x86)\XviD4PSP 5\dlls\AviSynth\functions\VideoFunctions.avs")
loadplugin("C:\Program Files (x86)\XviD4PSP 5\dlls\AviSynth\plugins\bass\bassAudio.dll")
loadplugin("C:\Program Files (x86)\XviD4PSP 5\dlls\AviSynth\plugins\FFMS2.dll")
import("C:\Program Files (x86)\XviD4PSP 5\dlls\AviSynth\plugins\FFMS2.avsi")

video = FFmpegSource2("C:\Users\Mihanja80\Downloads\Fawni - Serious.mkv", rffmode=0, cachefile="F:\Temp\fawni - serious.mkv.ffindex").AssumeFPS(25.000)
audio = bassAudioSource("F:\Temp\0069_0.flac")
AudioDub(video, audio)

ConvertToYV12()

###[FILTERING]###
###[FILTERING]###

Spline64Resize(720, 408)

AUDIO ENCODING
------------------------------
Encoding audio to: F:\Temp\0072.mp3
MP3 128kbps 2ch 16bit 48000khz

lame.exe: -m s -b 128 -q 2 - "F:\Temp\0072.mp3"

VIDEO ENCODING
------------------------------
Encoding video to: F:\Temp\0072.avi
XviD 1900kbps 720x408 25.000fps (4915 frames)

...first pass...

xvid_encraw.exe: -pass1 "F:\Temp\0072_1.log" -qtype 1 -vhqmode 4 -nopacked -bvhq -bquant_ratio 162 -bquant_offset 0 -lumimasking -max_key_interval 250 -threads 4 -i "F:\Temp\0072.avs" -o NUL

Tot: enctime(ms) =71579.00, length(bytes) = 81844826
Avg: enctime(ms) = 14.56, fps = 68.69, length(bytes) = 16645
I frames: 162 frames, size = 45347/ 7346316, quants = 2 / 2.00 / 2
P frames: 1885 frames, size = 25838/ 48705927, quants = 2 / 2.00 / 2
B frames: 2851 frames, size = 9046/ 25792447, quants = 3 / 3.00 / 3
N frames: 17 frames, size = 8/ 136

...last pass...

xvid_encraw.exe: -pass2 "F:\Temp\0072_1.log" -bitrate 1900 -qtype 1 -vhqmode 4 -nopacked -bvhq -bquant_ratio 162 -bquant_offset 0 -lumimasking -max_key_interval 250 -chigh 20 -clow 7 -vbvmax 4854000 -vbvsize 3145728 -vbvpeak 2359296 -imin 2 -pmin 2 -bmin 2 -threads 4 -i "F:\Temp\0072.avs" -avi "F:\Temp\0072.avi"

Tot: enctime(ms) =130133.00, length(bytes) = 46038265
Avg: enctime(ms) = 26.47, fps = 37.78, length(bytes) = 9363
I frames: 162 frames, size = 36020/ 5835340, quants = 2 / 2.81 / 4
P frames: 1885 frames, size = 14103/ 26584364, quants = 2 / 3.23 / 5
B frames: 2851 frames, size = 4776/ 13618425, quants = 3 / 4.49 / 8
N frames: 17 frames, size = 8/ 136

MUXING
------------------------------
Video file: F:\Temp\0072.avi
Audio file: F:\Temp\0072.mp3
Muxing to: F:\Dimon\Fawni - Serious4.avi
Please wait...

TIME
------------------------------
Общее время кодирования: 3 min 41 sec
Файл получился на: 47.14 mb



Developers, please note ...

[Jawor]

Maybe PSNR-HVS-M has some problems with flat surfaces... So far only a handful of people tested this feature in Xvid.

I also noticed you're using -vbvpeak. The concept of “VBV peak rate” was redefined in November 2010. Previously it was multiplied by 3, now it isn't (and that means you have unintentionally limited the maximum bitrate to 2359 kbps). Now it just means “maximum bits over any one second”.

Besides, the whole concept of “VBV peak rate” is considered deprecated in Xvid. Actually, it was just an invention of DivX, Inc.. The “peak rate” of DivX profiles is already satisfied in your command line thanks to -vbvmax 4854000 -vbvsize 3145728. There's no need to use -vbvpeak at all (it will only mess things up).

All presets using -vbvpeak should be updated. The old value must be multiplied by 3 (or the -vbvpeak parameter should be removed from them completely).

[mihanja80]

low bitrate gives Ring on the contours of ...
with default settings - there are blends of (phantom) ...
function of the new metric is not doing anything.

http://rghost.ru/4130310/image.png
Mirror Image (http://piccy.info/view3/1026863/bea0dde51da6bc75bffd0a7125b04d03/)

PLATFORM
------------------------------
OS: Microsoft Windows NT 6.1.7600.0
OEMCodePage: 866
Language: RUS
DecimalSeparator: ,
Framework: 2.0.50727.4952
Processors: 2
SystemDrive: C:

XVID4PSP
------------------------------
Version: 5.10.211.2
Created: 26.01.2011 18:07:34
TempPath: F:\Temp
AppPath: C:\Program Files (x86)\XviD4PSP 5

FILES
------------------------------
Fawni - Serious.mkv >
Fawni - Serious6.avi

TASK
------------------------------
Format: AVI Hardware
Duration: 00:03:16:600 (4915)
VideoDecoder: FFmpegSource2
Resolution: 1280x720 > 720x408
Aspect: 1.7778 > 1.7647
VCodecPreset: Custom
VEncodingMode: TwoPass
VideoCodec: h264 > XviD
VideoBitrate: 3170 > 1900
Quality: 0.138 > 0.259
Framerate: 25.000
SourceType: PROGRESSIVE
FieldOrder: UNKNOWN
AudioDecoder: bassAudioSource
AEncodingPreset: MP3 CBR 128k
AudioCodec: FLAC > MP3
AudioBitrate: 0 > 128
Samplerate: 48000
Channels: 2

SCRIPT
------------------------------
import("C:\Program Files (x86)\XviD4PSP 5\dlls\AviSynth\functions\AudioFunctions.avs")
import("C:\Program Files (x86)\XviD4PSP 5\dlls\AviSynth\functions\VideoFunctions.avs")
loadplugin("C:\Program Files (x86)\XviD4PSP 5\dlls\AviSynth\plugins\bass\bassAudio.dll")
loadplugin("C:\Program Files (x86)\XviD4PSP 5\dlls\AviSynth\plugins\FFMS2.dll")
import("C:\Program Files (x86)\XviD4PSP 5\dlls\AviSynth\plugins\FFMS2.avsi")

video = FFmpegSource2("C:\Users\Mihanja80\Downloads\Fawni - Serious.mkv", rffmode=0, cachefile="F:\Temp\fawni - serious.mkv.ffindex").AssumeFPS(25.000)
audio = bassAudioSource("F:\Temp\0069_0.flac")
AudioDub(video, audio)

ConvertToYV12()

###[FILTERING]###
###[FILTERING]###

Spline64Resize(720, 408)



AUDIO ENCODING
------------------------------
Encoding audio to: F:\Temp\0074.mp3
MP3 128kbps 2ch 16bit 48000khz

lame.exe: -m s -b 128 -q 2 - "F:\Temp\0074.mp3"


VIDEO ENCODING
------------------------------
Encoding video to: F:\Temp\0074.avi
XviD 1900kbps 720x408 25.000fps (4915 frames)

...first pass...

xvid_encraw.exe: -pass1 "F:\Temp\0074_1.log" -qtype 1 -notrellis -vhqmode 1 -nopacked -max_bframes 1 -bquant_ratio 162 -bquant_offset 0 -masking 2 -max_key_interval 210 -zones 0,q,3.0 -quality 5 -nochromame -turbo -threads 4 -i "F:\Temp\0074.avs" -o NUL

Tot: enctime(ms) =39053.00, length(bytes) = 51129044
Avg: enctime(ms) = 7.95, fps = 125.85, length(bytes) = 10402
I frames: 167 frames, size = 31833/5316140, quants = 3 / 3.00 / 3
P frames: 2455 frames, size = 13211/32435329, quants = 3 / 3.00 / 3
B frames: 2280 frames, size = 5867/13377471, quants = 4 / 4.00 / 4
N frames: 13 frames, size = 8/ 104

...last pass...

xvid_encraw.exe: -pass2 "F:\Temp\0074_1.log" -bitrate 1900 -qtype 1 -notrellis -vhqmode 4 -nopacked -bvhq -max_bframes 1 -bquant_ratio 162 -bquant_offset 0 -masking 2 -max_key_interval 210 -vbvmax 4854000 -vbvsize 3145728 -imin 1 -pmin 2 -bmin 3 -threads 4 -i "F:\Temp\0074.avs" -avi "F:\Temp\0074.avi"

Tot: enctime(ms) =91274.00, length(bytes) = 46682299
Avg: enctime(ms) = 18.57, fps = 53.85, length(bytes) = 9497
I frames: 167 frames, size = 32478/5423922, quants = 2 / 2.90 / 4
P frames: 2455 frames, size = 11991/29439581, quants = 2 / 3.04 / 5
B frames: 2280 frames, size = 5183/11818692, quants = 4 / 4.08 / 6
N frames: 13 frames, size = 8/ 104


MUXING
------------------------------
Video file: F:\Temp\0074.avi
Audio file: F:\Temp\0074.mp3
Muxing to: F:\Dimon\Fawni - Serious6.avi
Please wait...

TIME
------------------------------
Общее время кодирования: 3 min 49 sec
Файл получился на: 47.76 mb


Source above ...
Try it yourself ...

[DELiAN]

I'm really surprised that no one here has noticed that the Xvid_130_RC1_11012011_x64.exe installer is pretty messy. Half the files are copied to "Program Files (x86)", half to "Program Files"; "Configure Decoder" shortcut in "Start Menu" is broken; you cannot use DirectShow filter with x86 players even if it has been registered, because programs cannot find x86 version of xvidcore.dll (and they are not able to see/use x64 one). The 64-bit version of players is useless for playback too, because there is only 32-bit-compiled version of xvid.ax.

Is there a way to install both x86 and x64 versions of xvidcore and xvidvfw dlls, so I can use the x64 one whenever that version of application is available, and the x86 one in case only that one exists (older apps)?

[Jawor]

Half the files are copied to "Program Files (x86)", half to "Program Files"
StatsReader and FourCC Changer are old applications that are available only as 32-bit binaries (they wouldn't benefit from using 64 bits anyway).
"Configure Decoder" shortcut in "Start Menu" is broken; you cannot use DirectShow filter with x86 players even if it has been registered, because programs cannot find x86 version of xvidcore.dll (and they are not able to see/use x64 one).
I uploaded a new installer that should fix this. Thanks for the report.

Is there a way to install both x86 and x64 versions of xvidcore and xvidvfw dlls, so I can use the x64 one whenever that version of application is available, and the x86 one in case only that one exists (older apps)?
I just made an installer that is able to install both 64-bit and 32-bit xvidcore.dll and xvidvfw.dll on the same system.

http://jawormat.republika.pl/Xvid_130_RC1_11012011_x86_and_x64.exe

[DELiAN]

I just made an installer that is able to install both 64-bit and 32-bit xvidcore.dll and xvidvfw.dll on the same system.

Great, thanks! I actually succeeded by manually moving all files from "Program Files (x86)\XviD" to "Program Files\XviD" after x64 installation, then installing x86 version, but with your new installer it will be much easier for sure.

Keep up the good work. Now when Koepi has stopped making his builds, we certainly need someone to count on in the future. :)

[mariush]

I've downloaded the 7z file from jawormat.republika.pl/Xvid_130_RC1.7z and did some test encodes...

I'm experiencing blockiness/artifacts when using -slices 2 -threads 4 instead of just -threads 4. I do get a speed improvement on my overclocked to 3.02Ghz Q6600 32 bit from 93-95 fps to about 105-110 fps but you can see the result is bad.

WARNING: The sample is 16 seconds of erotic content, not safe for work, with some deinterlacing ugliness but I don't care, it's just for tests. And it's legally purchased/ I'm allowed to work on it.

Original sample: http://savedonthe.net/download/253/test.html (3 MB)

with slices : xvid_encraw.exe -i test.avs -progress 100 -vhqmode 4 -masking 2 -slices 2 -threads 4 -avi final_slices.avi : http://savedonthe.net/download/254/final_slices.html (1.85 MB)

no slices : xvid_encraw.exe -i test.avs -progress 100 -vhqmode 4 -masking 2 -threads 4 -avi final_threads.avi : http://savedonthe.net/download/255/final_threads.html (same size as above)

-slices 2 -threads 4 with -masking 1 makes artifacts slightly worse at a first look but I may be wrong.

Without slices, it looks OK (well considering the source, and no artifacts visible)

Am I doing something wrong or I am forgetting some parameter?

as I said, q6600 overclocked to 3.02 Ghz (but no problems with previous xvid_encraw and xvid 1.2), 32bit Windows 2003, 4 GB ram.

later edit: -slices 4 -threads 4 is even worse, adding -bvhq, -qpel, -gmc makes it slightly better right at the beginning but it's still obvious after the first few frames

even later edit: checked the version on xvidvideo.ru (xvid.1.3.0-(cvs).101030.05.48-vaq-mtk-icl11_x86) but it looks like that one doesn't have the -slices feature implemented. I copied xvid_encraw from jawor's build over and tried -slices but the avi files were identical so I guess it's not implemented in the xvidcore.dll

[Tuik]

i'm having that problem too...