xvid_encraw - Patched with AviSynth input support

[bond]

I doubt there's mp4 output. But if anybody were going to add that, it's better to wait until the CSV code (I don't know why you can't see it.. is there a shadow CSV? In the past year I've not seen much of activity anywhere so I'm wondering if development has moved to channels I'm not aware). Anyway, the submission deadline for codecs is the 16th so by that time I should have that encraw and if it's ready for release it will show up here as well.so .avs input is supported?

[Doom9]

yes, as I said, there is no point continuing the source from this thread. Now, patience is a virtue..

[Sagittaire]

$Id : xvid_encraw.c, v1.11.2.282003/06/2523:23:21 edgomez Exp $

xvid_encraw is edgomez's code ... ???

[JoeBG]

Hi, what's the current status of xvid_encraw? I volunteer to add anything I can add - this weekend if needed. What's left/broken/wrong?

I have posted the following problem very often but never got a feedback:
For me it seems to be that the first pass in xvid_encraw is useless because I have the suspicion, that xvid_encraw does not use the informations of the statsfile. The second pass is totally independent from the first pass. I have just the request, that someone with more skills than me can check this before the next release - thank you very much :)

[sysKin]

For me it seems to be that the first pass in xvid_encraw is useless because I have the suspicion, that xvid_encraw does not use the informations of the statsfile. The second pass is totally independent from the first pass. I have just the request, that someone with more skills than me can check this before the next release - thank you very much :)

I just looked around, apparently you need to specify stats filename with
-pass1 xvid.stats

and then

-pass2 xvid.stats

If you don't, everything goes weird. I fully admit encoder should be more rebust than this (and should not allow -pass1 and -pass2 in the same command, just in case).

[JoeBG]

I just looked around, apparently you need to specify stats filename with
-pass1 xvid.stats

and then

-pass2 xvid.stats

If you don't, everything goes weird. I fully admit encoder should be more rebust than this (and should not allow -pass1 and -pass2 in the same command, just in case).

I don´t think so. Please look at the problem if the commandlinde works:

@echo off
title Jempeg4-1400
echo.
echo Pass 1 Xvid
echo ************
echo.
%Xvid% -i %Videofolder%\Film.avs -type 2 -pass1 %Videofolder%\xvid.stats -asm -quality 6 +chroma_opt -max_bframes 2 -bquant_ratio 150 -bquant_offset 100 -bf_thres 0 -bitrate %bitrate% -max_key_interval 250 -pquants 1 31 -bquants 1 31 -iquants 1 31 +trellis -mpeg_quant -lumimasking +hpel -qpel -vhq 4 +rd_bf -turbo -o %Videofolder%\Film.m4v
cls
echo.
echo Pass 2 Xvid
echo ************
echo.
%Xvid% -i %Videofolder%\Film.avs -type 2 -pass2 %Videofolder%\xvid.stats -asm -quality 6 +chroma_opt -max_bframes 2 -bquant_ratio 150 -bquant_offset 100 -bf_thres 0 -bitrate %bitrate% -max_key_interval 250 -pquants 1 31 -bquants 1 31 -iquants 1 31 +trellis -mpeg_quant -lumimasking +hpel -qpel -vhq 4 +rd_bf -keyframe_boost 100 -close_i_red 1 20 -ccp_high 0 -ccp_low 5 -max_oi 5 -max_od 6 -overf_cs 10 -o %Videofolder%\Film.m4v
cls



To say it directly: This does not work: statsfile will not get read in the second pass and it would be very nice, if someone could check this or if someone could tell me my the mistake.

I can only point out, that xvid_encraw does not work and I hope that I´m making a mistake. Please confirm :)

[Sagittaire]

little test with xvid_encraw.exe

1) 2 pass encoding work fine
2) it's possible to make NPass encoding ... lol

here CLI for Multipasse with XviD

xvid_encraw.exe -i Encodage.avs -type 2 -o first.m4v -pass1 statsfile1 -asm +hqacp +inter4v +hpel +chromap +chromab +me_advd16 +me_advd8 +me_sqr16 +me_sqr8 +me_hpelr16 +me_hpelr8 +me_gmer +me_exts16 +me_exts8 +rated +rd_bf +rd_hpelr16 +rd_hpelr8 +rd_chk_pred +rd_exts +trellis -lumimasking -max_bframes 2 -bquant_ratio 150 -bquant_offset 0 -stats
xvid_encraw.exe -i Encodage.avs -type 2 -o second.m4v -pass1 statsfile2 -pass2 statsfile1 -size 13500 -asm +hqacp +inter4v +hpel +chromap +chromab +me_advd16 +me_advd8 +me_sqr16 +me_sqr8 +me_hpelr16 +me_hpelr8 +me_gmer +me_exts16 +me_exts8 +rated +rd_bf +rd_hpelr16 +rd_hpelr8 +rd_chk_pred +rd_exts +trellis -lumimasking -max_bframes 2 -bquant_ratio 150 -bquant_offset 0 -stats
xvid_encraw.exe -i Encodage.avs -type 2 -o third.m4v -pass2 statsfile2 -size 13500 -asm +hqacp +inter4v +hpel +chromap +chromab +me_advd16 +me_advd8 +me_sqr16 +me_sqr8 +me_hpelr16 +me_hpelr8 +me_gmer +me_exts16 +me_exts8 +rated +rd_bf +rd_hpelr16 +rd_hpelr8 +rd_chk_pred +rd_exts +trellis -lumimasking -max_bframes 2 -bquant_ratio 150 -bquant_offset 0 -stats

MP4Box.exe -nodrop -add third.m4v third.mp4


Multipass example:

I want 13500 Ko final size for my encoding

first pass q2 done 34741 Ko
second pass with first stat file done 13312 Ko
third pass with second stat file done 13500 Ko

and quality for 3 pass is better than 2 pass quality with better target bitrate and certainely better vbv reliability (if vbv are used) ... lol

[IgorC]

Sagi
thank you for information.

[JoeBG]

little test with xvid_encraw.exe

1) 2 pass encoding work fine
2) it's possible to make NPass encoding ... lol

here CLI for Multipasse with XviD

xvid_encraw.exe -i Encodage.avs -type 2 -o first.m4v -pass1 statsfile1 -asm +hqacp +inter4v +hpel +chromap +chromab +me_advd16 +me_advd8 +me_sqr16 +me_sqr8 +me_hpelr16 +me_hpelr8 +me_gmer +me_exts16 +me_exts8 +rated +rd_bf +rd_hpelr16 +rd_hpelr8 +rd_chk_pred +rd_exts +trellis -lumimasking -max_bframes 2 -bquant_ratio 150 -bquant_offset 0 -stats
xvid_encraw.exe -i Encodage.avs -type 2 -o second.m4v -pass1 statsfile2 -pass2 statsfile1 -size 13500 -asm +hqacp +inter4v +hpel +chromap +chromab +me_advd16 +me_advd8 +me_sqr16 +me_sqr8 +me_hpelr16 +me_hpelr8 +me_gmer +me_exts16 +me_exts8 +rated +rd_bf +rd_hpelr16 +rd_hpelr8 +rd_chk_pred +rd_exts +trellis -lumimasking -max_bframes 2 -bquant_ratio 150 -bquant_offset 0 -stats
xvid_encraw.exe -i Encodage.avs -type 2 -o third.m4v -pass2 statsfile2 -size 13500 -asm +hqacp +inter4v +hpel +chromap +chromab +me_advd16 +me_advd8 +me_sqr16 +me_sqr8 +me_hpelr16 +me_hpelr8 +me_gmer +me_exts16 +me_exts8 +rated +rd_bf +rd_hpelr16 +rd_hpelr8 +rd_chk_pred +rd_exts +trellis -lumimasking -max_bframes 2 -bquant_ratio 150 -bquant_offset 0 -stats

MP4Box.exe -nodrop -add third.m4v third.mp4


Multipass example:

I want 13500 Ko final size for my encoding

first pass q2 done 34741 Ko
second pass with first stat file done 13312 Ko
third pass with second stat file done 13500 Ko

and quality for 3 pass is better than 2 pass quality with better target bitrate and certainely better vbv reliability (if vbv are used) ... lol

You are not right with this. 2 pass Encoding is broken. If you try the following you will see, that you only get ggod quality if you rename statsfile of second pass to statsfile 2 and that you get the same quality without any first pass.

But try yourself:
xvid_encraw.exe -i Encodage.avs -type 2 -o first.m4v -pass1 statsfile1 -asm +hqacp +inter4v +hpel +chromap +chromab +me_advd16 +me_advd8 +me_sqr16 +me_sqr8 +me_hpelr16 +me_hpelr8 +me_gmer +me_exts16 +me_exts8 +rated +rd_bf +rd_hpelr16 +rd_hpelr8 +rd_chk_pred +rd_exts +trellis -lumimasking -max_bframes 2 -bquant_ratio 150 -bquant_offset 0 -stats
xvid_encraw.exe -i Encodage.avs -type 2 -o second.m4v -pass2 statsfile1 -size 13500 -asm +hqacp +inter4v +hpel +chromap +chromab +me_advd16 +me_advd8 +me_sqr16 +me_sqr8 +me_hpelr16 +me_hpelr8 +me_gmer +me_exts16 +me_exts8 +rated +rd_bf +rd_hpelr16 +rd_hpelr8 +rd_chk_pred +rd_exts +trellis -lumimasking -max_bframes 2 -bquant_ratio 150 -bquant_offset 0 -stats

[JoeBG]

No Reaction?

Sorry, but this problem is bagging me since months and Sagittaire did not use a 2 pass commandline for his test. I´m really wondering, why noone is interested in this? Did noone test this? Xvid_Encraw is such an interesting project. Noone interested in this? Noone is testing a 2 pass commandline since months and noone is corresponding to this problem.

@ All

If noone will answer on this problem again, the xvid commandline for xvid_encraw will be dead - and I really wonder why noone is interested.

@ doom9

Don´t use xvid_encraw before this important problem is fixed. The first pass is useless.

But more important is, why noone is intersted in this problem? MeGUI with mencoder-Xvid is very bad because it never matches the size. Xvid Encraw is a solution but noone is really interested. But why? I dont understand all this. Has someone answers?

[dimzon]

Xvid Encraw is a solution but noone is really interested. But why? I dont understand all this. Has someone answers?
I can tell you only about myself. I'm switched from XviD to x264 encoding 6 month back...

[708145]

broken 2pass explains a lot. I use xvid_encraw in ELDER's xvid mode and had strange size matching problems.

A bugfix would help me, too.

bis besser,
T0B1A5

[JoeBG]

broken 2pass explains a lot. I use xvid_encraw in ELDER's xvid mode and had strange size matching problems.

A bugfix would help me, too.

bis besser,
T0B1A5

But noone is interested in this - there will be no help for you :(

I can tell you only about myself. I'm switched from XviD to x264 encoding 6 month back...

Do you think we shoul close this request? I´m really looking every day at this threat but noone is answering and noone is interested.

@ doom9

I´m so disappointed with this project. Mencoder is really a bad solution for meGUI, xvid_encraw is really a much worser solution than mencoder for meGui. So we should forget our targets for a Xvid commandline solution? Have you ever seen a video with a 2 pass xvid_encraw commandline?

[bond]

didnt doom9 say that there is already someone working on the cli? simply be patient ;)

[JoeBG]

didnt doom9 say that there is already someone working on the cli? simply be patient ;)

OK. But after such a long time with this problem and no solution for it I really don´t think that doom9 has the time to test it - especially the quality of the resulting videos. Do you really have hope for this project?

[Kurtnoise]

@echo off
title Jempeg4-1400
echo.
echo Pass 1 Xvid
echo ************
echo.
%Xvid% -i %Videofolder%\Film.avs -type 2 -pass1 %Videofolder%\xvid.stats -asm -quality 6 +chroma_opt -max_bframes 2 -bquant_ratio 150 -bquant_offset 100 -bf_thres 0 -bitrate %bitrate% -max_key_interval 250 -pquants 1 31 -bquants 1 31 -iquants 1 31 +trellis -mpeg_quant -lumimasking +hpel -qpel -vhq 4 +rd_bf -turbo -o %Videofolder%\Film.m4v
cls
echo.
echo Pass 2 Xvid
echo ************
echo.
%Xvid% -i %Videofolder%\Film.avs -type 2 -pass2 %Videofolder%\xvid.stats -asm -quality 6 +chroma_opt -max_bframes 2 -bquant_ratio 150 -bquant_offset 100 -bf_thres 0 -bitrate %bitrate% -max_key_interval 250 -pquants 1 31 -bquants 1 31 -iquants 1 31 +trellis -mpeg_quant -lumimasking +hpel -qpel -vhq 4 +rd_bf -keyframe_boost 100 -close_i_red 1 20 -ccp_high 0 -ccp_low 5 -max_oi 5 -max_od 6 -overf_cs 10 -o %Videofolder%\Film.m4v
cls



To say it directly: This does not work: statsfile will not get read in the second pass and it would be very nice, if someone could check this or if someone could tell me my the mistake.

I can only point out, that xvid_encraw does not work and I hope that I´m making a mistake. Please confirm :)

I just tested with xvid_encraw from the 1.1.0 sources and it seems to work fine without specifying an output file for the 1st pass...

xvid_encraw.exe -i Birth_test.avs -type 2 -pass1 Birth_test.stats -quality 6 -bitrate 50000 -max_bframes 2 -turbo
xvid_encraw.exe -i Birth_test.avs -type 2 -pass2 Birth_test.stats -o Birth_out.m4v -quality 6 -bitrate 50000 -max_bframes 2 -vhqmode 4 -bvhq

[snherbst]

Hi

Iam not good in this commandline tool either. Thats proberly because its not possible to just chose a profile. But any way which command line would be equal to the "Advanced Simple @ L5" Profile.

[Sagittaire]

I just tested with xvid_encraw from the 1.1.0 sources and it seems to work fine without specifying an output file for the 1st pass...

you can post this version here ... ???

[Kurtnoise]

sure...http://kurtnoise.free.fr/xvid_encraw-1.1.0.zip

[JoeBG]

sure...http://kurtnoise.free.fr/xvid_encraw-1.1.0.zip

You make my day :) By the way: -bitrate 50000 <- seems to be a littly high ;)

Edit:

Same Problem here. You have to give the statsfile of the second pass another name than the statsfile of the first pass if you want quality. => Xvid_Encraw does not read from statsfile of the first pass -> the statsfile of the first pass and the first pass itself is totally useless. If you only make a second pass without the first pass you have the same quality.

=> Sorry Kurt, your commandline does not work.

[Kurtnoise]

By the way: -bitrate 50000 <- seems to be a littly high ;)
It was just a crash test... :)


Same Problem here. You have to give the statsfile of the second pass another name than the statsfile of the first pass if you want quality.
huh ? for what for ?

=> Xvid_Encraw does not read from statsfile of the first pass
mmh...to be sure : make only a 1st pass first. Then, rename the stats file or put it in other folder. Second, make an encode with 2 pass (by using the same filename concerning stats file) and compare the different stats files...(diff is good for that). I'm pretty sure that the files are the same. This means that xvid_encraw read the stats from the 1st pass.

[buzzqw]

very dumb question

how i can mux/play with the resultin .raw file ??? :stupid:

BHH

[Yong]

very dumb question

how i can mux/play with the resultin .raw file ??? :stupid:

BHH
First you have to rename the raw xvid file to *.xvid extension,
then mux the raw xvid file with mp4box or mp4creator.
You can playback the raw xvid file with mplayer. ;)

[buzzqw]

@Yong
Thanks !

i successfully muxed raw xvid with mp4creator but latest versione of mp4bix (on celticdruid site) failed with an "unknow input file type"

thanks !

BHH

[Doom9]

mp4box can mux it just fine.. but it expects the .m4v extension. That also works for mp4creator by the way.

[buzzqw]

Thanks too Doom9 !

renaming movie.raw to movie.m4v resolved the unkown input error with mp4box !

BHH

[JoeBG]

Same Problem here. You have to give the statsfile of the second pass another name than the statsfile of the first pass if you want quality. => Xvid_Encraw does not read from statsfile of the first pass -> the statsfile of the first pass and the first pass itself is totally useless. If you only make a second pass without the first pass you have the same quality.

=> Sorry Kurt, your commandline does not work.

I really think, that noone ever tested xvid_encraw like I did.

Which tool makes snapshots from raw files or mp4 files? I will post my results in pictures to show you the problem.

@ Kurt

I have made a first pass, then copied the statsfile into a new folder. Then I made the second pass. How can I compare the two statsfiles? Diff is not a commandline function isn´t it?

[Kurtnoise]

this is a command line tool...;) Check this site (http://gnuwin32.sourceforge.net/packages.html). (diffutils)

And to be more clear...I said.

1/ Make an encode in one pass and save the statsfile.
2/ Make a full encode with 2 passes like you do by changing the filename.
3/ Then compare the stats files...

[Yong]

I think this cli apps indeed have problem,
like JoeBG said.
I tried encode video with 2nd pass without 1st pass stats file, it doesnt show any error when encoding start :rolleyes:

But xvid_encraw does use 1stpass stats file, without it xvid_encraw will create a big files ;)

[JoeBG]

And to be more clear...I said.

1/ Make an encode in one pass and save the statsfile.
2/ Make a full encode with 2 passes like you do by changing the filename.
3/ Then compare the stats files...

I will never understand this testing procedure or the difference to what I already did.


1/ Make an encode in one pass and save the statsfile.
Do you mean a first pass of an 2 Pass Encode? That´s what I already did. I wrote a skript with a stop after the first pass.



2/ Make a full encode with 2 passes like you do by changing the filename.
Why not starting the second pass? Why new encoding in 2 passes. Why changing the filename. I already stored a copy of the statsfile in a different folder.
=> I think I´m not intelligent enough to understand the procedure :(


3/ Then compare the stats files..

Which ones?

[bond]

guys, please. I have it on good authority that encraw is done (except for the profiles you can select in the GUI), it would make little sense for syskin to re-invent the wheel.ok now 1 month is gone. any news on this "done" tool? isibaar? :D

[Doom9]

well.. what was done was posted here. I compiled a list of missing options from that release and sent it to syskin.

[bond]

well.. what was done was posted here. I compiled a list of missing options from that release and sent it to syskin.hm, you mean the 1.1 compile from kurtnoise includes all the changes from isibaar? or did i oversee some other thingie being posted?

i wonder because when i look at the cvs (http://www.xvid.org/cvs/chora/cvs.php/xvidcore/examples?login=2&sbt=1)i only see changes being 3 months old, made by suxen_drol, but not by isibaar!?

[Doom9]

hm, you mean the 1.1 compile from kurtnoise includes all the changes from isibaar?I don't know who wrote it, but it's the current state of encraw. And considering there's a whole new codec not in the CVS I could start a whole series of rumours about a parallel secret CVS or whatnot. Bottom line.. you can get what's posted in this thread and that's it. MeGUI already supports that featureset (not publicly released yet).. if syskin makes any update to the CSV they will be supported.

[bond]

well time for testing then :D

[bond]

if thats the final version it definitely cant keep up with S_O's version. altough this +/- sheme is messy it still offers as good as all options, whereas this 1.1 build definitely does not

[Doom9]

Well, there are in fact multiple major issues I found when giving it more than a 1000 frames to test. I'm in the process of sending a long bugreport to Michael. Some of the issues JoeBG reported are definitely there, but it does get a lot worse :(

Encoding past frame 9999 is impossible.

CBR bitrate control is broken (encodes everything at Q2).
2 pass encoding with a non existing statsfile is possible, and it results in a Q2 stream
2 pass encoding with an existing statsfile results in the majority of all frames being encoded at Q31.. naturally that means the size is off.
The statsfile generated during the first pass is correct, and it can be used to make a second pass via VfW that comes out just as it should.
This behavior seems to happen irrespective of the settings (I tried a bunch of settings but obviously not every permutation).

@JoeBG: that's the kind of analysis I think is reasonable to make.. it gives you a lot more pointers than your "it doesn't work, try it" ;)

[squid_80]

Encoding past frame 9999 is impossible.That's a simple #define in the source code, there's a comment that it's only for testing short sequences.2 pass encoding with a non existing statsfile is possible, and it results in a Q2 streamSame thing happens with the vfw interface if the statsfile is bad.

If people want the features of S_O's build why not just merge the sources with the current CVS code?

[Doom9]

If people want the features of S_O's build why not just merge the sources with the current CVS code?somebody needs to authorize that.. and S_O's build is quite messy, so I'd probably not looking forward to that if I'd be in a position to chose.

P.S. The bitrate has to be given in bits/s but all the rate control issues are still there.

[Doom9]

I have an update: CBR RC is not broken.. but encraw needs the bitrate in bits/s (I suspected but because the results varied all over the place I got confused), and it does work.. it's not as accurate as 2 pass though (2 pass in the VfW of course). I did another 2 pass test with bits/s bitrate for both passes.. it was only a trailer, and it wasn't spot on either, but 200KB off.. doing a full movie now to check.

[squid_80]

If I'm reading the code right, all the extra parameters for 2nd pass like overflow treatment and curve compression are left as 0. Same goes for the CBR settings (Reaction delay, averaging period and smoother). Fixing them to defaults is pretty easy, if anyone's still interested I can post a modified build.

[dimzon]

because with .mp4 output you can edit the output in various tools and dont need mp4box or mp4creator :p
And Yet Another Reason - you can preview right after encoding (without any additional tools)

Seem's like I can spend a little time to add AVI output to this utility (reuse some part of avs2avi code)...

[squid_80]

Seem's like I can spend a little time to add AVI output to this utility (reuse some part of avs2avi code)...
Done it already (didn't mention that in my previous post :)).

[bond]

if you want .avi output why not simply use vfw in virtualdub?

better add support for some real containers, like mkv or mp4 ;)

[squid_80]

if you want .avi output why not simply use vfw in virtualdub?

better add support for some real containers, like mkv or mp4 ;)
..And here in person is the reason why I didn't say anything. ;)
.avi output is a start. Once I figure out what the calls are for mkv (maybe mp4, but look at the trouble gpac causes with x264) I'll probably add that too.

[bond]

..And here in person is the reason why I didn't say anything. ;) you guessed right ;)

edit:
1) shame on you added avi support!
2) if you add mkv support make sure the cli writes the stream in "native mpeg-4" and not in the vfw mode as virtualdubmod, as i really dont see the sense in recreating with the cli whats already possible easily in other ways...

(maybe mp4, but look at the trouble gpac causes with x264) I'll probably add that too. gpac doesnt really cause trouble to x264... the only issue caused by gpac itself i know is that sometimes plain cvs checkouts bork, but then again its no wonder that cvs isnt always stable. after all its also not needed to use latest cvs in most cases
the rest was caused by issues in x264's calling of gpac (one time not setting the track enabled flag, the other time having issues with the 64bit times)
thats basically it

than again you can also use the mp4 lib from mpeg4ip if you dont like gpac...

[Doom9]

@squid_80:
Here's the list of missing features I compiled:

Additional zone options: (start with i-frame, grayscale, cartoon, chroma optimizer, bvop sensitivity),
minimum and maximum quantizer, trellis,
top field first mode for interlaced, PAR/DAR settings, VBV options and chroma motion.

Fixing them to defaults is pretty easy, if anyone's still interested I can post a modified build.It would be nice to be able to control those since they're currently missing (goes for both 2 pass and 1 pass RC settings)
all the RC related options aren't there.


And when it comes to XviD 1.2, a new option like -nbthreads would be nice to control how many threads are being used.

Done it alreadyIs it already in the CVS?

[Zero1]

I guess if you are going to add MKV and MP4 support that's great, so long as we can still output raw (outputting raw and muxing later has saved me a few times when people have been complaining about x264's borked mp4 out).

[squid_80]

@squid_80:
Here's the list of missing features I compiled:

Additional zone options: (start with i-frame, grayscale, cartoon, chroma optimizer, bvop sensitivity),
minimum and maximum quantizer, trellis,
top field first mode for interlaced, PAR/DAR settings, VBV options and chroma motion.
It would be nice to be able to control those since they're currently missing (goes for both 2 pass and 1 pass RC settings)
all the RC related options aren't there. Here's what I've changed the default settings to (most of this is just to match vfw):
- bframes to 2, adjustable using -max_bframes
- Key frame interval to 300, adjustable using -max_key_interval
- Default quality = 6, should match vfw's motion search precision settings
- Unrestricted profile (currently not adjustable)
- Chroma motion on, can be disabled with -nochromamotion
- Trellis on, can be disabled with -notrellis
- Default VHQ mode = 1, should match vfw's settings
- Packed mode and closed gop are on, can be disabled with -nopacked and -noclosed_gop
- PAR can be set using -par <integer> where 1 = square, 2 = 4:3 PAL, 3 = 4:3 NTSC etc... currently working on custom support.
- AVI output possible using -avi <filename.avi> (for verification purpose only, the avi files are produced using the AVIFile API so they're a bit rough, most people would probably remux them with audio anyway.) Note that it's possible to output a raw file and avi at the same time.
- Fixed single, 1pass and 2pass parameters to default vfw values. I'll make cli parameters for these as soon as I get a chance. Also look for the stats file in 2pass and don't proceed if it's not there.
- Force min/max quants to 2/31. Again cli parameters are coming (I'm thinking probably -imin, -imax, -pmin etc.)
And when it comes to XviD 1.2, a new option like -nbthreads would be nice to control how many threads are being used. There's actually a way for xvidcore.dll to provide the number of cpu cores to the calling program, but at the moment it doesn't work (returns 0). So I'll make it use this value by default then when the functionality is added to xvidcore it should select the correct number of threads automatically. I'll add an override switch anyway, since encraw is all about diagnostics.
Is it already in the CVS?
Nope, I don't have access to xvid's CVS. I'm just working on my own here (but I see Isibaar did recently check in a fix for that 9999 frame limit).

[Doom9]

@squid: sounds like it's finally moving forward :) Doesn't VDub use AVIFile as well to write AVIs? Naturally in the end it would be great if you could submit a patch to xvid-devel so that the whole thing can be merged.
Isibaars patch finally fixed encoding for me.. I'm currently encoding the second movie and then check for size discrepancies if there's any.