xvid_encraw - Patched with AviSynth input support

[MacAddict]

I'm impressed using this on my DualCore system for the past few months. I'm confused why the 2nd pass only appears to use one core and averages about 51% utilization though. My content isn't filtered with anything but ColorMatrix and isn't resized. First pass usually averages 99-103fps while the 2nd pass is around 12-15fps. Anyone else seeing this behavior?

[TheRyuu]

I'm impressed using this on my DualCore system for the past few months. I'm confused why the 2nd pass only appears to use one core and averages about 51% utilization though. My content isn't filtered with anything but ColorMatrix and isn't resized. First pass usually averages 99-103fps while the 2nd pass is around 12-15fps. Anyone else seeing this behavior?

I am as well. I'm wondering if this is slowing down the encoding at all or if that's just as fast as it's gonna get.

I'm pretty sure it's because xvid_encraw is only using 1 thread for xvid and the other for the frame serving or whatever it's called (which is what it's suppose to do). I'm wondering if this is slowing down the second pass?

[squid_80]

If you want to force it to behave differently, use -threads 3 (2 for encoding, 1 for reading input) or -threads 2 and -nothreadedinput. I think you'll find it slower though.

[TheRyuu]

If you want to force it to behave differently, use -threads 3 (2 for encoding, 1 for reading input) or -threads 2 and -nothreadedinput. I think you'll find it slower though.

The best balance seems to be 2 threads for the first pass, and 3 for the second. That way, both passes seem the fastest to me. (~100fps on first, ~30fps on second).

Dunno if it works the same way on quad core though.

[20-40]

It's excellent! Many thanks to Kopernikus and squid_80… Thank you.

Last week I have recompressed many music video clips from my collection, and because of their number and lack of free time, I've dropped-out any thoughts about two-pass re-encoding, but all of them must fit one DVD - and CQ was out of the picture… Reading this thread, I've played a little, and as I have been very satisfied by results, decided to go on…
This is the simple avisynth script I've used:

AVISource("G:\input.avi")
Crop(0,86,512,212)
MDeblock()
Undot()
LanczosResize(640,268)
ResampleAudio(48000)
SoundOut(output="MP3",mode=2,cbrrate=128,filename="D:\HVS.mp3",autoclose=true,showprogress=true)

Best way to achive desired final file-size was frame size.
Hvs doesn't like any blackness around, so I've cropped any borders if necessary (I have almost all clips in 512 or 576 width in 4/3 AR with borders :-( )
For batch re-encoding, I wrote this drag&drop HVS_AQxvid_enc.bat:

@rem ###################################################################################
@rem # DRAG&DROP working Avisynth script on this .bat (but...ADJUST ALL PATHS HERE!!!) #
@rem ###################################################################################
@echo off
@set fname=%1%
@set out1=%fname%_.avi
echo %fname%
echo %out1%
@rem
@rem
@rem
"C:\xvid_encraw\xvid_encraw_hvs_061119.exe" -i %fname% -avi %out1% -framerate 25 -nochromame -cq 4 -max_bframes 2 -bvhq -bquant_offset 200 -bquant_ratio 100 -hvs_aq " quant lc_lum gl_lum 2 / - theta 255 gl_lum - 3 * 4 / lc_lum - theta + 2 / - " -threads 2 -max_key_interval 250 -progress 10
@rem
@rem
@rem #####################################################################
@rem ## IF YOU DON'T HAVE or use soundout.dll plugin in Avisynth script ##
@rem #####################################################################
@rem wavi.exe %fname% - | lame.exe -m s -b 128 - D:\HVS.mp3
@rem #####################################################################
@rem ## IF YOU PREFER rather old avimux.exe instead of Avimux_GUI ##
@rem ## (un-rem following & delete lines afterwards) ##
@rem #####################################################################
@rem "C:\xvid_encraw\avimux.exe" -apre=60 -inter=100 %out1% %fname%_muxed.avi "D:\HVS.mp3"
@rem #####################################################################
@rem ## Avimux_GUI section ##
@rem #####################################################################
set PATH=E:\Progra~1\AviMux;%PATH%
setlocal ENABLEDELAYEDEXPANSION ENABLEEXTENSIONS
@rem #####################################################################
@rem ################# set IN/OUT, besides... it #############
@rem ###### must be ABSOLUTE path for mp3 from/for soundout.dll !!! ######
@rem #####################################################################
set TMPAMG=%fname%.amg
set SRCVFN=%out1%
set SRCAFN=D:\HVS.mp3
set MUXFLN=%fname%_muxed.avi
@rem ######################################################################
@rem ####### following lines create Avimux_GUI script #########
@rem ######################################################################
echo CLEAR > "!TMPAMG!"
echo LOAD !SRCVFN!>> "!TMPAMG!"
echo LOAD !SRCAFN!>> "!TMPAMG!"
echo SELECT FILE 1 >> "!TMPAMG!"
echo ADD VIDEOSOURCE >> "!TMPAMG!"
echo SET INPUT OPTIONS >> "!TMPAMG!"
echo WITH SET OPTION >> "!TMPAMG!"
echo AVI FORCE MP3VBR 0 >> "!TMPAMG!"
echo MP3 VERIFY CBR NEVER >> "!TMPAMG!"
echo MP3 VERIFY RESDLG 0 >> "!TMPAMG!"
echo END WITH >> "!TMPAMG!"
echo SET OUTPUT OPTIONS >> "!TMPAMG!"
echo WITH SET OPTION >> "!TMPAMG!"
echo OVERWRITEDLG 0 >> "!TMPAMG!"
echo CLOSEAPP 1 >> "!TMPAMG!"
echo DONEDLG 0 >> "!TMPAMG!"
echo MAXFILES OFF >> "!TMPAMG!"
echo STDOUTPUTFMT AVI >> "!TMPAMG!"
echo AVI ADDJUNKBEFOREHEADERS 0 >> "!TMPAMG!"
echo AUDIO INTERLEAVE 1 FR >> "!TMPAMG!"
echo PRELOAD 60 >> "!TMPAMG!"
echo AVI HAALIMODE 0 >> "!TMPAMG!"
echo OPENDML 0 >> "!TMPAMG!"
echo LEGACY 0 >> "!TMPAMG!"
echo RECLISTS 0 >> "!TMPAMG!"
echo END WITH>> "!TMPAMG!"
echo START !MUXFLN!>> "!TMPAMG!"
@rem #####################
@rem ## Finaly ... mux ##
@rem #####################
AVIMux_GUI.exe %fname%.amg

After that, all was piece of cake, well… it took two day for all clips, but quality is great and one pass (my time) per clip was saved.

One thing has left - 1-hour Sade concert captured from TV a long time ago. For fun, I've decided to do two pass encoding and final size should be defined… so:


@echo off
@set fname=%1%
@set out1=%fname%_.avi
Echo %fname%
Echo %out1%
@rem
@rem
@rem
"C:\xvid_encraw\xvid_encraw.exe" -i %fname% -avi %out1% -framerate 23.976 -nochromame -pass1 "xvid.stats" -size 614512 -max_bframes 2 -bvhq -bquant_offset 200 -bquant_ratio 100 -hvs_aq " quant lc_lum gl_lum 2 / - theta 255 gl_lum - 3 * 4 / lc_lum - theta + 2 / - " -threads 2 -max_key_interval 250 -progress 10
"C:\xvid_encraw\xvid_encraw.exe" -i %fname% -avi %out1% -framerate 23.976 -nochromame -pass2 "xvid.stats" -size 614512 -max_bframes 2 -bvhq -bquant_offset 200 -bquant_ratio 100 -hvs_aq " quant lc_lum gl_lum 2 / - theta 255 gl_lum - 3 * 4 / lc_lum - theta + 2 / - " -threads 2 -max_key_interval 250 -progress 10
@rem
@rem
@rem
"C:\MingW\bin\mencoder.exe" %out1% -audiofile %fname% -oac mp3lame -lameopts cbr=128 -ovc copy -o %fname%_muxed.avi

This 2-pass_1cd_HVS.bat has done all job by drag&drop simple avisynth script ( similar to aforementioned, but without SoundOut in it).
Kopernik's encraw has been overwhelmed by input and new squid's encraw has jumped in.

Thank you guys, once again.

[20-40]

Better late then never. OK, I use XviD 1.2-127 (CVS) and Avisynth 2.6 (also CVS). Somehow, I've noticed "longer-then-usual" encoding times with xvid_encraw (then it should be with reported FPS). I have, back then; hundreds of encodings on queue, all clips were short… and… I didn't care too much about time, I guess.
Then, longer encodings came… well, if someone has 90000 frames to encode, he can expect 900 seconds if reported fps by xvid_encraw was - 100 fps, right?

HOWEVER - encoding took 9000 seconds, which is almost close to three hours compared to "expect" fifteen minutes.
Then, pretty freaked out, I have compiled xvid again - with gcc, with vc71 and vc80. Then with icl 9.0 and then 9.1. Then encraw exe, turning optimizations on and off. With all these compilers. Different sources of encraw - original and squid80's. Mine. Everything stays - bogus fps on screen…

Well, next time I will fire-up stopwatch.exe, rather then seeing-believing. I humbly suggest that to all concerned.
http://free-kr.t-com.hr/zeman/xvid_encraw-fps-sw.jpg

[jethro]

Did you feed an avisyth script to Xvid_encraw? If yes, it could be that 'enctime' is the CPU time which xvid_encraw itself spent on compressing frames and the missing time comes from avisynth processing.

[squid_80]

Run xvid_encraw -h and tell me the date and time it was built. I think you're using an older version which only counts the time taken for encoding, not including time taken to fetch the input frame i.e. avisynth processing. But it was over a year ago that I changed that behaviour.

[20-40]

As I've mentioned, it's about three versions of source code of encraw. As I've said, it doesn't matter which specific version. As I've mentioned, all encraws exhibit the same error - bogus fps during and after encoding (when it reports some data). Also, it doesn't matter by which compiler is compiled - same as by who - same is valid for exes compiled by you or anyone else.
"FPS" spitted by any encoder is very valid information for anyone, in determining script/filtering options, and in the eyes of the most people, something that is looked at first.
What I'm saying is that "FPS" IS bogus, it MAY be a bogus in god knows how many cases, as it can be subject of easy manipulations.
To clarify myself - I suggest to people to check ACTUAL (as REAL) encoding times, and not to focus on ETAs or FPses alone.
But you've made only ONE zip of source available and one zip with compiled encraw and aviwriter.dll (and I love YOUR version - adding VD routines was very nice idea). There is no other "versions" of your encraw. Kopernikus made available two (but rather obsolete by now). Xvid.org cvs is one only. My own is my gcc and intel modified. Sucus is, it realy doesn't matter.
However:
1.C:\xvid_encraw>xvid_encraw_squid.exe -h >xvid_encraw_squid.txt
xvid_encraw built at 10:22:53 on Aug 31 2007

2.C:\xvid_encraw>xvid_encraw_vc71.exe -h
xvid_encraw - raw mpeg4 bitstream encoder written by Christoph Lampe
rt 2002-2003
xvid_encraw built at 10:08:29 on Feb 14 2008

3.C:\xvid_encraw>xvid_encraw_hvs_061119.exe -h
xvid_encraw - raw mpeg4 bitstream encoder written by Christoph Lampe
rt 2002-2003

xvid_encraw built at 16:38:19 on Nov 19 2006

4.C:\xvid_encraw>xvid_encraw_orig.exe -h
xvid_encraw - raw mpeg4 bitstream encoder written by Christoph Lampe
rt 2002-2003

xvid_encraw built at 15:38:53 on Feb 13 2008
(2. and 4. are CVS XviD.org, 2. is with added your aviwriter code and 4. is CVS but hvs modified version for my gcc-4.3 CYBORG)

P.S. It reminds me on old, built-in prank in all Windows: "Estimated time: 2 minutes left".
Two minutes later is" Estimated time: 6 minutes left". Time CAN flow in - negative. :-)

[henryho_hk]

But it was over a year ago that I changed that behaviour.

Is it now a simple (end time - start time) over the whole clip (or finished portion)? Otherwise, many factors may come in.

[Too busy on my work for the last year.... no time for on my own batch script]

[20-40]

ANY encoder is the last in the encoding chain, it means that it doesn't matter what is input. Encoding application must-should-only could report actual (REAL) number of encoded frames by second. Fluctuations during encoding are expected, as they depend on complexity of input, by filling/emptyng caches/buffers, by writing the output… just to mention a few…
Nevertheless, at least FINAL encoding time should be right, right?
BUT - it's not.
It looks simple, simple end_of_encoding minus start_of_encoding equal total_encoding_time, but it is not - as you can see from the screenshot I've provided dozen inches beforehand.
It seems that people have mixed-up few things.

In the case of XviD codec and encraw, fps is stored and represented in/as "%6.2f". It has nothing to do with avisynth. This value is reported by codec ALSO for VirtualDub, Avidemux and any other application we use. If there were an error in ANY other part of the chain (avisynth with filters, codec itself) - such error would be manifested by/in them too, right? However, it is not the case.
And - in my case "%6.2f" is %6.2f/(ARG_THREADS + 1), but it doesn't fix the error.

[squid_80]

J:\ts-temp2>copy con enc_test.bat
xvid_encraw -h 2> help.txt > nul
find "built" < help.txt
time < nul
xvid_encraw -i lost.avs -frames 50000 2>nul | find "Tot:"
time < nul
^Z
1 file(s) copied.

J:\ts-temp2>enc_test.bat

J:\ts-temp2>xvid_encraw -h 2>help.txt 1>nul

J:\ts-temp2>find "built" 0<help.txt
xvid_encraw built at 10:22:53 on Aug 31 2007

J:\ts-temp2>time 0<nul
The current time is: 21:56:51.29
Enter the new time:
J:\ts-temp2>xvid_encraw -i lost.avs -frames 50000 2>nul | find "Tot:"
Tot: enctime(ms) =5591690.00, length(bytes) = 1729539969

J:\ts-temp2>time 0<nul
The current time is: 23:30:04.39
Enter the new time:
Clock end time - clock start time = ~5593 seconds.
xvid_encraw reports 5591.690 seconds.
Using my build, as stated by the -h option.
I don't see any problems here.

[20-40]

Combination of xvidcore-vfw-ax compiled with gcc-4.3CYBORG and your source (squid80's) encraw compiled with 2003 with your's source of aviwriter dll compiled with 2005 on two cores/threads works error free!
I'm still puzzled with all this, but - everything is fine now.

However, squid80, thank you for reactions.

[Lenchik]

Hope thgis is right thread to ask.

I am trying to create a series of .bat files for batch processing of videos from my photo.
Previous .bat files create series of .avs files. For now problem is to create .bat for video encoding using xvid_encraw.
Here goes code:
setlocal ENABLEDELAYEDEXPANSION ENABLEEXTENSIONS

for %%i in (*.avs) do (
start "%%~ni - Pass 1/2" /b /wait /belownormal xvid_encraw.exe -type 2 -i "%%~dpi%%i" -pass1 "%%~dpi%%~ni.stats" -bitrate 2000 -kboost 100 -chigh 30 -clow 15 -overhead 0 -max_key_interval 100 -nopacked -vhqmode 4 -closed_gop -lumimasking -notrellis -imin 1 -pmin 1 -max_bframes 1 -bvhq -bquant_ratio 162 -bquant_offset 0 -bmin 1 -par 1:1 -threads 3 -vbvsize 3145728 -vbvmax 4854000 -vbvpeak 8000000

start "%%~ni - Pass 2/2" /b /wait /belownormal xvid_encraw.exe -type 2 -i "%%~dpi%%i" -pass2 "%%~dpi%%~ni.stats" -bitrate 2000 -kboost 100 -chigh 30 -clow 15 -overhead 0 -max_key_interval 100 -nopacked -vhqmode 4 -closed_gop -lumimasking -notrellis -imin 1 -pmin 1 -max_bframes 1 -bvhq -bquant_ratio 162 -bquant_offset 0 -bmin 1 -par 1:1 -threads 3 -avi "%%~dpi%%~ni-video.avi" -vbvsize 3145728 -vbvmax 4854000 -vbvpeak 8000000
)

The problem is that sometimes .avs files are not opened correctly (may be because of directshowsource aplied to .mov files). Anyways, i want to create script that will start first pass encoding of current .avs again and again if first attempt fails (if i am doing this manually for jobs in megui or virtualdub - it works fine), and then in same way for second pass of each .avs. How can i do it? may be some errorcheck or error output of xvid_encraw? I am not so good at .bat or at other programming to find out this by myself alone (that's why i have taken some parts of code from avs2qxvid).
By the way, any other suggestions about script are welcome.
Hope you understood my idea and my english.

[buzzqw]

use ffmpegsource and not directshowsource :)

BHH

[henryho_hk]

squid_80, would you mind making a win64 compile of the latest version? ^_^

I have just installed Vista64 SP1 and I was trying the 64bit compiles of Avisynth, xvid_enraw with 64bit XviD. With a simple script (DVD mpeg2source+tdeint+mipsmooth), they are using 1.7GB ram per xvid_encraw process. In the same machine (Q6600 + 8GB RAM) under the same OS, the 32-bit counterparts are using 512MB only. Another interesting point is the speed. At thread=1 or 5, the 64-bit combo is running at similar speed of 25~30 mins for a 18-min clip (cq3, vaq, max-b=1, vhq1, quality6, bvhq, trellis, etc.) For the 32bit combo, it's 14 mins for thread=1 and 24 mins for thread=5. Seems we still have a long way to go for 64bit platform.

[squid_80]

- The pc I use to compile xvid_encraw has been in pieces since xmas, so it's a bit hard to make new builds at the moment. But I think the 64-bit build should be up-to-date, it doesn't need to be recompiled to use new xvidcore builds.
- Always use setmemorymax when checking memory usage for programs that use avisynth scripts. Different avisynth versions may have different default memory usage limits.
- If threading in the 64-bit xvid isn't working properly, talk to the people who compiled xvidcore.dll. For me it works fine.
- 32-bit version takes 14mins with 1 thread but 24 mins with 5 threads? Again, talk to whoever made your xvidcore because that's not right at all.

[henryho_hk]

I recall the 64bit Avisynth from you was 2.55. I will try tweaking setmemorymax to see if it makes any difference. For threading, I was hoping for a 64bit xvid_encraw build of your greatly improved version with threaded input (http://forum.doom9.org/showpost.php?p=1039344&postcount=696). I would not it on the net. Perhaps I should try compiling it myself.

I am sorry that I seem to have made some typos in the speed figures in my last post (it should be something like "32-bit version takes 24mins with 1 thread but 14 mins with 5 threads"). I will test it again tonight.

[hellrasinbrasom]

Have you tried using Xvid4PSP to deal with encoding problems

:helpful:

[Kurtnoise]

I've a question about -zq vs -zw vs -zones switches : the first two are redundant, aren't they ? We can safety use the last one for the same thing, correct ?

[juGGaKNot]

Does it like 4 threads ?

I use

echo %NUMBER_OF_PROCESSORS% > "%mypath%\proc.txt"
set /p trd=<"%mypath%\proc.txt"
set /A trd2=%trd%+1
del "%mypath%\proc.txt"

And it works fine for single and dual core but on a quad xeon it does not work ( 3 threads not 5 )

[Kurtnoise]

you should read previous comments instead of asking this...

[juGGaKNot]

you should read previous comments instead of asking this...

Aham so 3 threads for all cores ?

[halsboss]

I'm confused as to which versions are available ... I read here and there about squid_80's version (whatever that is) but don't know where to download squid_80's own build ...

Also is it possible, similar to HCenc, for pass1 to produce a temporary decoded file to be used as input to pass2 so that pass2 doesn't have to process a glacially slow avisynth script a second time ?



ps go the crows, squid_80 :)

[halsboss]

Jeepers. About 30% of the time xvid_encraw crashes for me with a dialog box
"xvid_encraw has encountered a problem and needs to close."
When I click on more info it says "ModName avisynth.dll Modver 2.5.7.0 Offset 0000adbb".
Any ideas ?

Seems to happen randomly on either pass1 or pass2. Settings and commandline are

"C:\software\XVID_ENCRAW\xvid_encraw.exe" -type 2 -i "G:\HDTV\2\test.avs" -max_bframes 2 -bitrate 1500 -pass2 "G:\HDTV\2\test.stats" -stats -framerate 25 -max_key_interval 125 -asm -quality 6 -vhqmode 4 -bvhq -packed -closed_gop -lumimasking -imin 1 -bmin 1 -pmin 1 -clow 10 -overhead 0 -vbvsize 1835008 -vbvmax 8000000 -threads 3 -progress 25
"C:\software\XVID_ENCRAW\xvid_encraw.exe" -type 2 -i "G:\HDTV\2\test.avs" -max_bframes 2 -bitrate 1500 -pass2 "G:\HDTV\2\test.stats" -stats -framerate 25 -max_key_interval 125 -asm -quality 6 -vhqmode 4 -bvhq -packed -closed_gop -lumimasking -imin 1 -bmin 1 -pmin 1 -clow 10 -overhead 0 -vbvsize 1835008 -vbvmax 8000000 -threads 3 -progress 25 -o "G:\HDTV\2\test.m4v" -kboost 50

using .avs
SetMTmode(mode=5,threads=4) # start with mode=5 for source http://forum.doom9.org/showthread.php?p=1067216#post1067216
SetMemoryMax(512)
LoadPlugin("C:\SOFTWARE\DGindex\DGDecode.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins-zzz\tdeint.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins-zzz\yadifmod.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins-zzz\NNEDI.dll")
mpeg2source("G:\HDTV\2\test.d2v",cpu=4,ipp=true)
AssumeFPS(25)
AssumeTFF()
SetMTmode(mode=2,threads=4)
yadifmod(mode=0,order=1,edeint=nnedi(field=1,threads=4)) # mode=0=normal deinterlace
spline36resize(640,360)
SetPlanarLegacyAlignment(True)
Distributor()

[Sharc]

@halsboss
I also experienced a number of crashes with xvid_encraw (OS is Vista). The crashes seem to be caused by the -qpel function for certain sources.
Workaround was to disable -qpel. :(

[henryho_hk]

Same experience here... 720p + QPel ... during early 2nd pass

[henryho_hk]

squid_80, may we have a x64 compile of your 20070831 version of xvid_encraw?

[MOS-Marauder]

Hi xD
Question.. i saw that XVid ENcraw writes a custom pixel shape (1:1) instead of SQUARE in the bitstream. Any chance of fixing ?

Chris

[Sharktooth]

it's not a bug.
SQUARE is NOT written... is ASSUMED.
while "Custom Shape" is a wrong term used by avinaptic that means an AR is specified in the bitstream...

in practice avinaptic ALWAYS report Square Pixels for streams that have NO AR SIGNALED while it ALWAYS report Custom Shape for ALL the streams with any signaled AR (even 1:1).
that's an avinaptic limitation.

[Gew]

Hi!

I'm just curious. As I've understood it, xvid_encraw uses the same default settings as xvidvfw.dll, hence they should output the same?

However, when I load an .avs in VirtualDubMod, and encode it with XviD/VfW, and then encode the very same .avs with xvid_enraw.exe, the output is not entirely the same. In fact, even the bitrate differs a few kbps. Am I missing out on something? I have a theory that the codec settings are in fact similar, but there's a difference in how the source (.avs) is being projected/fed into the codec, hence the non-identical results.

Is this correct?

Ty in adv~
Regards~

[Sharktooth]

VFW bitstream writing depends on the host application while encraw has bitstream writing.
also there are other differencies... so the output will always be different.

[Gew]

Ty for your clarification Sharktooth. I think I got it.
It's like comparing drinking something straight out of the bottle with from a glass.
It'll be roughly the same result, but still not bit-identical.

:thanks:

[Gew]

What's the difference between the three reported quants?
I.e. when pulling a quick 250 frames encode using -bitrate 50 I get:

I quants = 4 / 9.00 / 14
P quants = 4 / 18.03 / 25
B quants = 7 / 25.18 / 31

What are the three different values reporting? Which one is the actual "overall quantizer" being used..?
Or are the different figures three different ways of telling the exact same thing?
Or any other relationship in between them, something I'm not aware of?

Ty in adv~

:stupid:

[Brother John]

Those are minimum/average/maximum quants used for the respective frame types. Average is a calculated value from all frames; you might call this the »overall quantizer«.

Btw: Xvid quants can only be integer number (from 1–31). Whenever you encounter a fractional number it can only be some average value, but never an actual »real« quant.

[Gew]

Ty a lot Brother John.
Your explanation was well-defined and makes perfectly good sense.
Sorry for "bothering" thread with silly newbish question.
I tried Google for answers before posting but no strings gave any result.

Anyways..

:goodpost::thanks:

Cheers~

[Gew]

Hmm. Compatibility issue with recent xvidcore.dll or something?

I'm using:
xvid_encraw built at 10:22:53 on Aug 31 2007
xvid [info]: xvidcore build version: xvid-1.3.2

Just tried an encode with an .AVS for source. Final bitrate is ~half what I set.
Also, now when I watch my result, the ~2/3 bottom of the video is all just a smear.

Any ideas?


EDIT:
Confirmed! Just tried same encode using an older xvidcore.dll
xvid [info]: xvidcore build version: xvid-1.2.2
No picture/framerate issues there. Any chance for a quick fix? ;)

[Jawor]

Yes, squid_80's version doesn't work correctly with xvidcore.dll 1.3.x (it has been mentioned somewhere in other topics). The reasons lie somewhere in changes made to the Xvid source code, but AFAIK they haven't been identified (otherwise a fix would appear). squid_80's last build comes from August 2007 (that's almost 4 years), so some incompatibilities are to be expected....

[Gew]

Hi (again)...

Now it's been more than seven months. Perhaps foolish of me, but I'm still curious. Are there any versions (builds by others perhaps?) of xvid_encraw available that will handle recent xvidcore.dll without any hassle? I'd be grateful. Let's say I have my reasons why I prefer the xvid_encraw (over eg. ffmpeg/mencoder) for batch encodes.

Thank you in advance~
Regards~
Cheers~

[madhatter300871]

Hi

If you just download the latest xvid from the xvid website, it comes with xvidencraw, it works for me with no problems. All I did was copy the xvidencraw.exe and xvidcore.dll (from system32) into my own folder, it works no problems.

[kalehrl]

Does it use only one core in the second pass?

[madhatter300871]

Does it use only one core in the second pass?

I think so, but I'll double check on my next encode.

[Gew]

Hi

If you just download the latest xvid from the xvid website, it comes with xvidencraw, it works for me with no problems. All I did was copy the xvidencraw.exe and xvidcore.dll (from system32) into my own folder, it works no problems.

Gosh, I never noticed that Xvid had/has started inbedding xvid_encraw.exe in their Win32 bundles. I just downloaded latest stable (Xvid-1.3.2-20110601.exe). Haven't tried it just yet, but I doubt I will run into any problems.

The issue I had with my xvid_encraw.exe (dated 2007 or something) was that if I used an xvidcore.dll from the 1.3.x series I had severely messed up output. Half the screen was "floating" somehow. Therefor I have kept an old Xvid 1.2.x xvidcore.dll just for use with xvid_encraw. This issue is mentioned a couple of pages up in this very thread.

Anyways, big thanks.
Now I will probably be able to kick it with latest Xvid! :D

Cheers!

:thanks:

Update!

Not only did it work with excellent result; average encoding speed raised from ~77 FPS to ~107 FPS (just ran side-by-side test using same input). This (I guess) a result of my old xvid_encraw.exe / xvidcore.dll combination only used 3 out of 4 cores on my CPU (xvid [info]: Detected cpus = 4, threads requested = 3, threads in use = 3), whereas this new set simply yields "Detected 4 cpus, using 4 threads". Awesome. One thing that made me worry was that at first my AVI would not play; MPC gave me "Cannot render the file". After some further digging, I noticed that the stream was actually not wrapped into a AVI container, but more or less raw. I then noticed that the "-avi" switch puts output in AVI, whereas "-o" (which I have always used before) does this raw-isch result. Anyways, like I said, works like a charm now!

[madhatter300871]

That's great.

I checked my last encode and it does indeed use all 4 cores on the second pass, it outputs the message "detected cpus=4, threads in use=4", (or something like that).

I'm getting about 200fps on the first pass, and about 30fps on the second pass, this is with a 1920x1080 input and a 720 x whatever output. Good enough for me :)

[kalehrl]

I don't get one thing.
When I use 1.3.2 xvid_encraw.exe in MeGUI, I get around 60 fps whereas with the default 1.2.2+VAQ xvid_encraw.exe I get around 85 fps.
I tried using Jawor's, generic and encraw from xvid.ru but it is the same - always much slower that the 1.2.2.
When I encode using vdubmod and the 1.3.2 system xvid, I get normal fps (around 85).