Xvid 1.3.2 is out [Archive] - Page 2

hello_hello

7th December 2011, 08:05

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.

I still have the version of Xvid which comes bundled with AutoGK installed. If you'd like to ensure it's using the correct settings with the new version, post the details (including your AutoGK standalone compatibility option) and I'll compare them to the Xvid settings it's using on my PC.

I haven't been keeping up with this thread and being lazy thought I'd ask now.....
What would be the advantage of upgrading the version of Xvid which comes with AutoGK? I'm just curious to know what it does better. Quality, file size, CPU usage etc. (the version I have uses VAQ).

When converting a DVD using AutoGK it currently keeps my dual core CPU pretty busy. I also have a quad core CPU in another PC (same clock speed) which doesn't complete an encode much faster than the dual core because the CPU only runs at around 50% to 60%.
Not that it's the end of the world. Most of the time if I'm converting a DVD I'm doing more than one, so I just convert two at a time.

kalehrl

7th December 2011, 15:00

I know it is not using the correct profile because I remember that with ess compatibility option checked, the autogk xvid version would use 'home theatre pal'.
With xvid 1.3.2, it is using 'xvid mobile' profile.
Having finished a couple of encodes, I can see that the 'xvid mobile' profile isn't respected because the resolution is well above the suggested one of 352x240.
I also compared the max bitrate of an encoded avi and the limitations of the 'xvid mobile' profile and it goes above the limitations.

As for my settings, I checked 'properly place avi subtitles' and 'ESS compatibility option'.
Everything else is default.
I also tried checking the MTK compatibility option but the files size with xvid 1.3.2 isn't correct.

What would be the advantage of upgrading the version of Xvid which comes with AutoGK? I'm just curious to know what it does better. Quality, file size, CPU usage etc. (the version I have uses VAQ).

It is just out of boredom. :D

hello_hello

7th December 2011, 18:08

As far as I know resolutions such as 352x240 for the mobile profile aren't enforced by Xvid, you can use a profile with any resolution.
On the other hand I would have thought the max bitrates of a profile would be enforced. Maybe not, but it seems odd. I assume you're referring to a 2 pass encode because the VBR settings are ignored in single pass mode, as far as I know.

I wonder why the ESS compatibility option was giving you correct file sizes but not MTK? As far as I know the only difference between the two is AutoGK uses the standard h263 or mpeg matrices with the ESS option and custom matrices with MTK. I thought the incorrect file size had to do with the VBR settings not working correctly, but maybe it's okay when using the default matrix? Mind you I've tried other versions of Xvid in the past where the VBR setting were broken even using the ESS option.

Well, if there's nothing overly exciting to be achieved by messing with the version of Xvid AutoGK installs, I might play it safe and leave it alone.

GMJCZP

29th February 2012, 04:56

At this point, what version of Jawor is preferable, 1.2.2 or 1.3.2?
With version Koepi 1.2.2 I took less time to process a video.

kalehrl

29th February 2012, 14:43

The new jawor's 1.3.2 is some 30% slower than squid's 1.2.1 xvid_encraw.
I tried generic, jawor's 1.3.2 versions but there are no differences.

GMJCZP

4th March 2012, 01:12

For now I use the Jawor version 1.3.2.
But somebody tell me that the version 1.2.2 is equal in quality I will use the 1.2.2 again because the speed.

kalehrl

4th March 2012, 11:44

Although I don't have a trained eye, I compared the 1.3.2 and 1.2.1 xvid_encraw outputs and the differences are negligible.
At least for me but, as I said, I don't have a trained aye when it comes to slight video differences.
For me 30% decrease in speed isn't worth negligible increase in quality.

Sonic9

18th March 2012, 14:54

I have noticed Xvid 1.3.2 doesn't support YV12 decompressing , in AviSynth with a DirectShowSource ... with the 1.2.2 it works ... anyone too ? (sorry for my bad english ...)

Jawor

18th March 2012, 15:08

anyone too ?
Yes, it looks like Output Colorspace == No Force defaults to YUY2 (quite frankly I have no idea why the developers would make this decision). Changing this option to YV12 in the Xvid decoder configuration window (or adding pixel_type="YV12" to DirectShowSource) forces YV12 output from the decoder.

Pulp Catalyst

28th July 2012, 23:11

xvid 1.3.x series was suppose to improve upon 1.2x series, yet all things being equal xvid 1.3.x seems to be a disaster!!

1.3.x is suppose to have superior multi-threading abilities over it's predecessor, yet everyone is showing upto a 30% decrease over 1.2.2.....
" " also has alienated MeGUI users and other GUI's as well by dropping openDML support
" " has broken backwards compatibility with it's predecessor causing most gui developers to make changes if they wish to support it (why couldn't backwards compatibility be maintained)

i'm forced to ask the following, i'm surprised no one else have (that i can find anyway)

why was Xvid 1.3.x even developed
why has it broken a lot of compatibility with it's predecessors
why (and this is a big one) for something that claims to have better multi-threading scaling showing time and time again to be inferior to it's predecessor!
what went wrong?
why after 2 more updates 1.2.2 is still superior in nearly all regards? (well those that matter anyway)
and finally why was openDML dropped knowing for well that MeGUI (which so many use) users would effectively be unable to use this new xvid series?

davexnet

4th August 2012, 17:23

Regarding the "max bitrate" associated with the various profile/level,
for example "xvid home" has a max of 4854.000.

However, this is only honored in 2-pass mode, not CQ.

My question is, why?

Is this intentional, or an oversight ? It really means, anybody encoding to work
on a hardware device, really must use 2-pass, otherwise run the risk of peaks at too-high
a bitrate causing playback problems.

Thanks for any info.

Jawor

5th August 2012, 21:17

Xvid's “constant quality” encoding mode is simplistic and has no bitrate control mechanism. It encodes every frame with the specified quantizer (except for B-frames - their quantizer is calculated from the I/P-frame quantizer using the specified ratio and offset).

DivX's “constant quality” mode has VBV, so it should be possible to create such a mode for Xvid as well. But that would require some serious coding work from someone familiar with Xvid's VBV algorithm. For the last few years, Xvid's development has been very slow since almost everybody migrated to x264 (and Xvid is now used almost exclusively for compatibility with old DVD players), so that probably won't happen.

davexnet

5th August 2012, 21:41

Appreciate the info. I'd heard it mentioned before about Divx having the control Vs. Xvid which didn't.
I never really understood WHY Xvid didn't - was there a legitimate reason, or was it over looked?
(seems as if nobody got around to it!)

I really like the quality with the Xvid version that comes with AutoGK, and that's the one I use.
For my DVD/Divx standalone player, I've found that encoding with CQ4 and limiting the resolution to
something like 624 x ??? usually works. Using bitrate viewer I can see on very high demand scenes the BR
goes up to approx. 10000 kbps, and it works OK as long as it's for just a few seconds.

Thanks again.

Jawor

5th August 2012, 21:49

I never really understood WHY Xvid didn't - was there a legitimate reason, or was it over looked?
The VBV algorithm was added to Xvid pretty late in the development process (somewhere around version 1.1.x IIRC). I guess it was much easier to implement VBV only for 2-pass, where we have information about bitrate requirements of every frame from the stats file (that was created in the first pass).
seems as if nobody got around to it!
Well, yeah, you could say that ;)

datauser

16th August 2012, 14:23

Using encraw in Xvid 1.3.2

Am I correct in saying that its main use(encraw) is for using with external programs like MeGUI/Staxrip, because you would have to place this encraw either to an existing or newly made encraw folder within the framework of that individual program alongside the copied xvidcore.dll to get the encoding benefits and that is its real purpose: to be used with a converting tool of your choice?

Or as a standalone for use in Avisynth/VirtualDub etc

To get encraw to work do I now have to copy this xvidcore.dll and make a new xvid_encraw folder within the Xvid installed directory in my program folders or just place/copy the xvidcore.dll alongside the encraw in the main Xvid folder for using the Xvid codec as is?

The instructions for installing and using encraw from zip were straightforward enough from Jawormat site,

How to install "xvidcore.dll" for EncRaw:
After unzipping, put xvidcore.dll in your EncRaw folder

However!

Can I use your xvidcore.dll with xvid_encraw?

Yes. It is recommended to use the bundled version of xvid_encraw.exe.
How do I use your xvidcore.dll with xvid_encraw?
Go to your xvid_encraw folder, backup the old xvidcore.dll and put my xvidcore.dll in the folder.

This info seems a tad confusing since encraw from your bundled installer version is installed within the Xvid directory and the xvidcore.dll in the system32 folder in XP.
Thanks.:)

Pulp Catalyst

20th August 2012, 22:30

I have confirmed with what has been said in the MeGUI forum, 1.3.2 is a lot slower, and produces the same quality as 1.2.x (some reports suggest a very slight increase in quality.... but this has not been proven, and i have yet to see it myself)

also 1.3.2 breaks compatibility in a few areas compared to the 1.2.x series.

I spent nearly a day with 1.3.2....... in MeGUI & Xvid4psp

1. why is xvid 1.3.x so much slower to 1.2.x ?
2. why has the developers behind xvid not taken steps to maintain backwards compatibility with it's predecessor?

as for MeGUI, quite frankly it does not play nice at all with the new xvid 1.3.2.... only one core gets used, lumiasking must be turned off..... and xvid runs terribly slow

truth is, xvid 1.2.2 vaq is as good as it gets, and with each passing month the need for xvid will continue to decrease, we all want xvid to get better, but the truth is..... 1.2.2 vaq already does a bang up job, and the multithreading was improved as much as it could be done without breaking xvid entirely (only a complete rewrite of xvid's code would solve the multithreading issue, and that was never going to happen with such an old ASP encoder)

given how efficient CPU's are becoming though, a good intel i5 using xvid will rip through most things in a heartbeat.

kalehrl

21st August 2012, 08:52

2. why has the developers behind xvid not taken steps to maintain backwards compatibility with it's predecessor?
My dvd/xvid player copes with Xvid 1.3.2 just fine so it doesn't break compatibility with standalone players. The only thing it breaks are GUIs because of a different CLI command.

Pulp Catalyst

21st August 2012, 20:27

that's what i meant, sorry if i did not make myself clear on that!

datauser

22nd August 2012, 10:56

...truth is, xvid 1.2.2 vaq is as good as it gets, and with each passing month the need for xvid will continue to decrease, we all want xvid to get better, but the truth is..... 1.2.2 vaq already does a bang up job, and the multithreading was improved as much as it could be done without breaking xvid entirely (only a complete rewrite of xvid's code would solve the multithreading issue, and that was never going to happen with such an old ASP encoder...

Yes, totally and much faster. Also gives better quality than 1.3.2 in my humble opinion. However sometimes using the Xvid 1.2.2 version in HDConvertToX 3.x with its version of encraw encoder(no VAQ, but luminance masking is used instead), it has given me a fuzzy/blurry color scene after a 2 pass which is annoying, because the rest of my avi comes out perfect.

If AutoGK profiles worked with Xvid 1.2.2(no undersizing etc) then that program would reach near perfection too in what it does!

RedDwarf1

30th June 2013, 21:48

None of the Xvids after 1.2.2 work fully on my Win 7 x64 system for some reason and I have seen a few other people have similar problems.

In VirtualDub(Mod) the preview does not work in 1.3.0 onwards but it does on 1.2.2. It shows that a decompressor for the video is not available and no video is displayed. I would like the extra options that were added to 1.3.x but need the video working in VirtualDub.

Is there a solution to this?

LigH

29th October 2014, 08:59

Believe it or not:

Xvid-1.3.3-20140406 _Final Release_

This is Xvid 1.3.3 bugfix release. It replaces the previous 1.3.2 stable release.

Changes since 1.3.2:

* xvidcore
- Improved MinGW and Cygwin compilation support
- Fixed possible encoder crash when Turbo+BVHQ+Qpel options are combined
- Added support for GNU Hurd as target OS
- Patch for QNX support
- Fix for possible overflow in Trellis quantization

* VFW frontend
- Minor GUI changes

* DShow/MFT frontend
- GUI cosmetics
- Switchable tray icon

* Example programs
- Fixed bug in xvid_encraw PGM header parser
- Fix out of bound access to framestats struct in xvid_encraw

http://www.xvid.org/

You did not yet notice ... so you probably don't have that problem either yet: If you have the auto update notifier enabled during installation, a window may pop up during your Windows booting:

http://www.ligh.de/pics/autoupdate-windows.png

And nothing else happens...