Isn't it time for a new compression mode in XviD?

[Eruendil]

Hi to all!

Inspired by DDogg I decided to work over a batchfile creator I wrote for personal use (which happens to be a batchfile itself):

It is called "VCBatchGen" (Video Conversion Batchfile Generator) and is intended to make video creation easier (as GordianKnot or even VirtualDubMod) without sacrifising control over the process (AutoGK etc.) And it certainly makes use of Kopernikus' xvid_encraw.exe!

Absolute newbies might get confused, it's something for experienced users, I think.

So basically what it does: VCBatchGen creates
1. a batchfile and
2. an AVS-script.

Just copy the folder in the archive to any directory, modify two batchfiles ("VideoConvert\VCBatchGen Link.bat" and "VideoConvert\VCBatchGen\vcbatchgen.bat" - don't worry, it's all about program and file paths!) and Drag and Drop the folder containing your "VIDEO_TS"-dir on the (modified) "VCBatchGen Link.bat" file.

VCBatchGen will then ask some questions concerning VOB number (for example VTS_01_*.vob, if you have several movies/episodes in one VIDEO_TS folder) , interlacing, picture format and so on).

Considering your answers, a batchfile will be created in the folder you specified in vcbatchgen.bat and an AVS-script in the folder you dropped on "VCBatchGen Link.bat".

Just execute the batchfile and (if you have set the paths in vcbatchgen.bat correctly), your rip will be demuxed and video and audio converted automatically.

There is a little helpfile provided as well as a help function in VCBatchGen (vcbatchgen.bat -? or /?).

Sounds complicated, but if you know what a batchfile is, you'll have this thing running in notime. And it really helps to make film converting much easier without worrying about pixels and filters or loosing control over the steps!

Ah yes: You need some programs installed: DGIndex, AVISynth 2.5, BeSweet and certainly xvid_encraw from Kopernikus.

Some necessary AVISynth-plugins are provided in the archive (they can be difficult to find and don't take much space). Just copy them in your AVISynth plugin directory. NOTE: I am using VCBatchGen in a PAL country, so some modificatons might be necessary. ANOTHER NOTE: VCBatchGen is tested with good and noisy DVD-material, but not with (good or bad) VHS-material, so the "bad" source mode remains experimental.

Feel free to ask any questions!

Greetings,
Eruendil

PS: Programs can be downloaded here:
http://www.doom9.org/index.html?/software2.htm

xvid_encraw from Kopernikus is found here:
http://xvid.ist-dein-freund.de/

------------------------------------ UPDATE --------------------------------
/Update: Newer, NTSC-compatible version of VCBatchGen is found in this posting: http://forum.doom9.org/showthread.php?p=906702#post906702
----------------------------

[DDogg]

Attachment still not approved. Eruendil, could you make available temporarily? check has temp (http://files.project357.com/) storage for this community.

I am wondering why there seems to be no interest. The folks here nearly always experiment with any new idea, so I am thinking I must be missing something?

[Eruendil]

Ok, I uploaded the file to:

http://files.project357.com/uploads/index.php?dir=&file=VCBatchGen_plus_files.zip/

With best regards,
Eruendil

------------------------------------ UPDATE --------------------------------
/Update: Newer, NTSC-compatible version of VCBatchGen is found in this posting: http://forum.doom9.org/showthread.php?p=906702#post906702
----------------------------

[Kopernikus]

I compiled a new version, with the typo fixed and the code cleaned up a bit. It is based on a 1.2 cvs from today.

http://xvid.ist-dein-freund.de/stuff/xvid_encraw_hvs_061105.exe

[DDogg]

I compiled a new version, with the typo fixed and the code cleaned up a bit. It is based on a 1.2 cvs from today.

http://xvid.ist-dein-freund.de/stuff/xvid_encraw_hvs_061105.exeKopernikus, thanks for the new build. I used it and Eruendil's cmdline on several encodes and the results are excellent.

I wish more people would try this method and report their results. Seems like it is just a better way to go if one wishes to put encodes on a server. I did a 2 hour source with no filters and no matrix. It came in at 700 megs. Bright and sharp, no blocks, real nice.

[Romario]

Guys, please, give me link for 1.2 CVS (builds and changelog for 1.2, each revision)

Thanks.

[foxyshadis]

xvid.org?

This isn't even a thread about cvs, it's about a non-cvs patch.

[henryho_hk]

Dear all, I ran the following for a test. I thought the I frames would be at quant. 3 and the B frames would be at quant. 5 (3*1.00+2). But then "t.stats" tell me that the B frames are also at quant. 3. Have I done anything wrong?

xvid_encraw_hvs_20061105.exe -zones 0,q,3,KO -nopacked -progress 100 -max_key_interval 300 -vbvsize 3145728 -vbvmax 4854000 -vbvpeak 8000000 -quality 4 -vhqmode 0 -max_bframes 1 -bquant_ratio 100 -bquant_offset 2 -qtype 1 -qmatrix "Didees-SixOfNine.cqm" -nochromame -turbo -framerate 29.970030 -hvs_aq "3 0 1 lc_lum 40 - theta x - 1 lc_lum 50 - theta x - 1 lc_lum 130 - theta x + 1 lc_lum 140 - theta x + 80 gl_lum - theta x +" -cq 3 -pass1 "t.stats" -type 2 -i "t.avs" -avi "t.avi"

-------------------

I know what's wrong now. It should be "-bquant_offset 200"

-------------------

It seems this xvid_encraw is much slower than squid's compile. Is it due to compilation settings or the new encoding mode?

[tyee]

I just tried the VCBatchGen method and I got this at the end of the command window. I did disable the audio part of the batching too.


Trying to retrieve width and height from input header
Non YV12 input colorspace DIB ! Attempting conversion...
AVIStreamReadFormat read 40 bytes.
width = 772, height = 56, planes = 1
Compression = , 0
Bits Per Pixel = 32
AVIStreamGetFrameOpen successful.
40 0 0 0 4 3 0 0 56 0 0 0 1 0 12 0 89 86 49 50 80 253 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0
xvidcore build version: xvid-1.2.0-dev
Bitstream version: 1.2.-127
Detected CPU flags: ASM MMX MMXEXT SSE SSE2 TSC
Detected 2 cpus, using 2 threads.
Using quantizer = (4.00 + (((((0.00 - (1.00 * theta((lc_lum - 40.00)))) - (1.00
* theta((lc_lum - 50.00)))) + (1.00 * theta((lc_lum - 130.00)))) + (1.00 * theta
((lc_lum - 140.00)))) * theta((80.00 - gl_lum))))

241 frames(100%) encoded, 358.63 fps, Average Bitrate = 23kbps
Tot: enctime(ms) = 672.00, length(bytes) = 28708
Avg: enctime(ms) = 2.78, fps = 360.12, length(bytes) = 118
I frames: 1 frames, size = 14431/ 14431, quants = 4 / 4.00 / 4
P frames: 80 frames, size = 127/ 10163, quants = 4 / 4.00 / 4
B frames: 159 frames, size = 25/ 4114, quants = 6 / 6.00 / 6
Press any key to continue . . .


Can you see what's wrong. It only ran for about a second before terminating.


PS. I think I have the wrong version of DGDecode.dll.

PS. That was it, DGIndex/DGDecode were mismatched! Working good now except that I think there is a bug when I input that the source is progressive, the -FO switch in DGIndex is not changed to progressive!!

[Kopernikus]

Has anyone a freely available, short (1000-2000 frames) sample, that pushes Xvid to its limits? I would like to run some further tests, but lack proper samples.

[ripernh]

Why this problem of dark scenes is not the priority of sites as divx and xvid.org?
I don’t speak english, sorry
I am using translating

[DDogg]

Has anyone a freely available, short (1000-2000 frames) sample, that pushes Xvid to its limits? I would like to run some further tests, but lack proper samples.Some HD source If you have broadband here (http://orange.blender.org/download).

[henryho_hk]

that pushes Xvid to its limits?

It depends which XviD's limit you want to test. You can try the samples in this thread: http://forum.doom9.org/showthread.php?t=116746

[Eruendil]

@tyee: Happy that it's working :) !
Actually I didn't really understand what this -FO option is good for. I only remember to have read somewhere that "Force Film" is an option that is necessary in some cases in NTSC-countries. As far as I came, I thought that honor/igone pulldown-flags is about dropping specific frames..?

Anyway, I never needed the option for my movies. But I can implement a version that does if you tell me, in which cases which values have to be set for that option...

Greetings,
Eruendil

/add1: Perhaps the modification could also be useful for people not living in an NTSC-country, but just intending to convert NTSC-material ;)

/add2: Why does xvid_encraw tell me that it calculates 30.48 fps, if it actually does only do 13.85 fps (121301 frames, 2h26m / 146 min conversion time) :confused: ..?? The total frames xvid_encraw prints is correct, but the total time and fps values are pure fantasy. Are these some kind of internal values considering some internal duration of conversion of a single frame or so?

[tyee]

Eruendil
In vcbatchgen.bat, if we change this part --

echo @echo on>>"%OUT%"
echo "%DGINDEX%" -AIF=[%WORK_DIR%\VIDEO_TS\VTS_%VOB_NUM%_1.VOB] -IA=3 -FO=0 -TN=%TRACKS% -OM=1 -OF=[%WORK_DIR%\VOB_Number_%VOB_NUM%] -EXIT>>"%OUT%"

by changing the -FO=0 to -FO=1, I think that will do it. This would make it progressive as default, and then when avsgen.bat executes, this part of avsgen.bat --

@echo INTERLACED OR PROGRESSIVE SOURCE
@echo in = interlaced: activate deinterlacing
@echo pr = progressive: no deinterlacing
:GET_DEINT
set /p DEINT="Interlaced / progressive source: "
IF "%DEINT%" NEQ "in" (
IF "%DEINT%" NEQ "pr" @echo Unrecognised input, please repeat.&&GOTO :GET_DEINT )

IF "%DEINT%" == "in" @echo in = in.TDeint( mtnmode = 0 )>>"%DIR%\VOB_Number_%NUM%.avs"


should change it to interlaced if required.
I think this would work for me here as NTSC. What do you think?


BTW - Why did you decide to split the batchfile up into two - vcbatchgen and avs_gen? What would happen if it were all one batch file??

[Eruendil]

Hi!

@tyee:
So, the only thing to be changed is "-FO=0" to "-FO=1", if I got it right. For all types of source material? Then all that has to change is the one number "0"->"1" in vcbatchgen.bat.

Or do you mean that "-FO=1" may only be applied for progressive material and must be "0" for interlaced sources?

Would these settings work for PAL also, or is there a different version (or simply a parameter NTSC=yes/no) needed?

About splitting vcbatchgen.bat and avs_gen.bat: I'm not sure anymore, why I split the two. Could be that I was liking the idea of modularity, or I simply was not familiar with how to use batchfiles and it was supposed to be a workaround of some kind...

As you see, I also use help_bat.txt to insert lines into the generated batchfile that operate with variables, which wouldn't have worked with the "echo"-command, which would have tried to replace all the variables by their values, so there will always be more than one file needed... And passing some variables to avs_gen.bat won't hurt, I think, and that way it remains "modular" ;)

Greetz,
Eruendil

[tyee]

Eruendil


"Or do you mean that "-FO=1" may only be applied for progressive material and must be "0" for interlaced sources?"

Yes, that is what I mean. Most of our NTSC dvd's are progressive on the disk and -FO=1 would inverse telecine (remove the pulldown flags, I believe) the dvd so we get 23.976fps for our encoding to xvid, but this could be changed when the avs_gen.bat asks us if it is interlaced or progressive.

tyee

[Eruendil]

Ok, I've got a working NTSC version on my harddrive now :D .

One question: Do I have to publish a special NTSC-version or do the settings -FO=1/0 work for PAL correctly also :confused:? Then I just could replace the old file. Can anybody tell for sure?

CU,
Eruendil

[henryho_hk]

How does the division operator work? Both cmdlines below give a quantizer of zero:

xvid_encraw_hvs_20061105.exe -progress 100 -hvs_aq " 3 4 \ " -cq 3 -single -i input.avs -avi output.avi

xvid_encraw_hvs_20061105.exe -progress 100 -hvs_aq " 4 3 \ " -cq 3 -single -i input.avs -avi output.avi

[Eruendil]

@henryho_hk:
If I remember right, I once noticed a strange behaviour of the -hvs_aq option: If the first value is a "calculated constant" (like "3 4 /" is a constant value) it produced senseless results... I'm not sure, if it was exactly the problem I describe here, but somehow in that direction...

Also I would be careful with leading spaces and such..!?

/add1: Perhaps you could try something like -hvs_aq "lc_lum 3 * lc_lum 4 * /" and "lc_lum 4 * lc_lum 3 * /" and see if it's working... Except this problem I don't remember to have encountered any other problem with formulas. Sorry :( that I didn't report it sooner!

/add2: The applied quant is the formula value cut off after the point. So 4.99999 would be quant 4.

[Kopernikus]

@henryho_hk: its "/" not "\" :)
But I guess I should add a error message

@eruendil: any example for strange behaviour?

And I will round the value instead of cutting it.

[Kopernikus]

Here is a new version:

-rounding
-warning if there is something wrong with the formula
-more code cleanup
-new parameters to play with:

lc_ssim: approximated (luma) ssim value of this macroblock in the frame before. 1 is lossless, 0 is very bad quality (even 0.8 is very bad).
gl_ssim: frame average of lc_ssim.

The ssim (a psychovisual quality metric, corresponds quite good to some aspects of human perception) values are 1 frame old, but I can not calculate ssim without having compressed the frame. And its still useful as the bad artefakts stay in place for more than one frame.

http://xvid.ist-dein-freund.de/stuff/xvid_encraw_061119.exe

[tyee]

Eruendil

"One question: Do I have to publish a special NTSC-version or do the settings -FO=1/0 work for PAL correctly also ? Then I just could replace the old file. Can anybody tell for sure?"

From what I remember, only NTSC uses the -FO=1 setting. PAL never uses it. I believe it removes the 3:2 pulldown flags, which is only used in NTSC. This will convert a 29.97fps NTSC movie to a 23.976fps progressive movie for us to encode.

[henryho_hk]

And I will round the value instead of cutting it.

It seems the AQ reported is a bit confusing.

xvid_encraw_hvs_20061119.exe -progress 100 -hvs_aq " 1.5 1.5 + " -cq 3 -single -i input.avs -avi output.avi
........... gives AQ = 2 and max I-Q = 3

xvid_encraw_hvs_20061119.exe -progress 100 -hvs_aq " 3 3 + 2 / " -cq 3 -single -i input.avs -avi output.avi
........... gives AQ = 3 and max I-Q = 3

xvid_encraw_hvs_20061119.exe -progress 100 -hvs_aq " 3 2 + 2 / " -cq 3 -single -i input.avs -avi output.avi
........... gives AQ = 2.5 and max I-Q = 3

[Eruendil]

@Kopernikus:
Sorry, but I don't have the formulas anymore, but I remember sweating some time about the problem and all worked fine after rearranging the formula (perhaps an error which wasn't repeated after regrouping the formula - I don't think so, but possible).

Regarding the new version of xvid_encaw: Do you really think it is wise to change the basic behaviour (rounding instead of cutting) of the formula now? I mean: In the end it doesn't matter at which point the quant is changed, the formula has to be adapted for both cases (although the "feeling" might be a bit better if rounding occurs... but that's for the sake of losing continuity, if something like this exists up to now).

@tyee:
The point is: Will -FO=1 do any harm to (progressive) PAL-material (always using "0" worked fine for PAL)? If I get you right, it doesn't matter if it's "1" or "0" for PAL-material.

PS: What strange fps-values NTSC uses! I guess this had some technical reason in the past?

/add1 @henryho_hk wrote
-hvs_aq " 1.5 1.5 + "
As far as I know, you can't use floating point values "1.5". You have to use "15 10 /" instead.

-hvs_aq " 3 + 3 2 / "
Here you use an operator needing two arguments after only giving one "3 +"... Do you perhaps mean "3 3 + 2 /"?

-hvs_aq " 3 + 2 2 / "
Idem.

Greetings,
Eruendil

[Kopernikus]

It The 1.5 is parsed as an int -> 1+1 = 2
3 + 3 2 / seems not a valid formula to me, and it is parsed as 3 2 / and gives AQ = 1.5 here

3 + 2 2 / -> AQ = 1.0

Seems all correct.

The Quantizer that is displayed per frame is not affected by the plugin. It is even different from the one written to bitstream, but there is a comment in the sources, so I assume it has a reason that I don't see.

@eruendil: I think rounding is better, and it is better to change it now.

[henryho_hk]

BTW, Kopernikus will you merge to a new code base by squid_80? It has an improved AVI writer.

http://members.optusnet.com.au/squid_80/sources/

[Kopernikus]

It is better to bug squid_80 to send a patch to the xvid-devel mailinglist.

[henryho_hk]

I want to modify Eruendil's formula as below hoping to limit the I/P quantizer range to 2~5 because I think 6 seems too aggressive.

"lc_lum 130 - theta lc_lum 140 - theta + lc_lum 40 - theta - lc_lum 50 - theta - 80 gl_lum - theta 3 * * 15 + 4 /"
or
"lc_lum 130 - theta lc_lum 140 - theta + lc_lum 45 - theta - 80 gl_lum - theta * 3 +"
or
"lc_lum 135 - theta lc_lum 40 - theta - lc_lum 50 - theta - 80 gl_lum - theta * 4 +"

In above these cases, how should I put the -cq parameter? And does it affect the B-frames only?

--------------------------------------------------------------------------------------------------

Answering myself, it's mostly in the document. "-hvs_aq" works on I and P frames only. B-frames seems to depends on the original rate control algorithm and, in the case of single CQ encode it depends solely on -cq, -bquant_ratio and -bquant_offset.

And ffdshow's visualization really helps a lot. It's fun to see different quantizers within a frame.

[Kopernikus]

The Quantizer that is displayed per frame is not affected by the plugin. It is even different from the one written to bitstream, but there is a comment in the sources, so I assume it has a reason that I don't see.


Yes, its a little bit confusing, the displayed Quantizer is not correct, for now just ignor it. I will try to find out why not the real quantizer is displayed, but the one frome ratecontrol.

[tyee]

Eruendil

@tyee:
The point is: Will -FO=1 do any harm to (progressive) PAL-material (always using "0" worked fine for PAL)? If I get you right, it doesn't matter if it's "1" or "0" for PAL-material.

I think the -FO=1 will do harm to PAL, so best to use -FO=0 for PAL at all times. I may be wrong so if anyone else knows please correct. So, to summarize, use -FO=0 for all PAL and -FO=1 for NTSC progressive and -FO=0 for NTSC interlaced.

[Eruendil]

Hi there!

Ok, here it goes (sorry for letting you wait, but I had some quite busy days): A fully PAL and NTSC-compatible version of VCBatchGen (V 1.6) ...

Either as attechment to this posting or at project357:

http://files.project357.com/uploads/index.php?dir=&file=VCBatchGen_plus_files_2006-11-25b.zip/

You simply will be asked if it's PAL or NTSC material and -FO will be 0 in all cases except for a progressive NTSC source. I thought that a seperate version would be nonsense anyway as someone might want to encode NTSC and PAL with one installation. Enjoy!

Greetings,
Eruendil

[tyee]

Thanks a lot Eruendil!! Much appreciated!

[henryho_hk]

Stealing the idea from Eruendil's formula:


-nochromame -cq 4 -bquant_offset 200 -bquant_ratio 100 -hvs_aq " quant lc_lum gl_lum 2 / - theta 255 gl_lum - 3 * 4 / lc_lum - theta + 2 / - "


If gl_lum > 153, all blocks are at Q=4. Otherwise, those with lc_lum between 0.5*gl_lum and 0.25*(255-gl_lum) will have Q=3.

BTW, does this HVS plugin work between with non-HVS matrices such as 6of9, MPEG or even H.263?

[DDogg]

henryho_hk, glad to see you are investigating this method. What are your thoughts so far in comparison to non patched xvid encodes? Btw, here is some data from a recent job using the formula above. I don't do many xvid encodes so I've not drilled down on what exactly the lines mean - would appreciate your comments on:

Detected 2 cpus, using 2 threads.
Using quantizer = (quant - ((theta((lc_lum - (gl_lum * 0.50))) + theta(((((255.0
0 - gl_lum) * 3.00) * 0.25) - lc_lum))) * 0.50))

141241 frames(100%) encoded, 92.13 fps, Average Bitrate = 959kbps
Tot: enctime(ms) =1533143.00, length(bytes) = 676975854
Avg: enctime(ms) = 10.85, fps = 92.13, length(bytes) = 4792
I frames: 2409 frames, size = 12169/29315491, quants = 4 / 4.00 / 4
P frames: 63254 frames, size = 8196/518470581, quants = 4 / 4.00 / 4
B frames: 75440 frames, size = 1712/129188678, quants = 6 / 6.00 / 6
N frames: 138 frames, size = 8/ 1104 Used this full line: -i %fname% -avi %out1% -nochromame -cq 4 -bquant_offset 200 -bquant_ratio 100 -hvs_aq " quant
lc_lum gl_lum 2 / - theta 255 gl_lum - 3 * 4 / lc_lum - theta + 2 / - " -bquant_offset 200
-bquant_ratio 100 -progress 10 Encode was @ 640x272 - finished video size was 648 MB - source was 94 minutes long

[Kopernikus]

HVS matrices are AFAIK matrices that try to exploit some properties of the human vision (as quantizing different frequencies differently is such a property, you could call every matrix HVS).

The Plugin changes the quantizer of blocks as a function of several parameters, that is something a QM cannot do. And I cannot imageine a reason why a different CQM should interfere with the plugin.

@DDogg: The data you posted is not very usefull, the displayed quants are totally wrong, I guess I should fix this.

How does the result look, and are there problematic parts?

[DDogg]

@DDogg: The data you posted is not very usefull, the displayed quants are totally wrong, I guess I should fix this.

How does the result look, and are there problematic parts? Looks very well. Zooming to 200% finds a few problems with a few frames in the middle of an explosion (in water) - I think I can live with that :)

[henryho_hk]

What are your thoughts so far in comparison to non patched xvid encodes?

As always, "I don't know what I am doing." ^_^

Actually, I do not know if it is a good idea to have a higher (4) quantizier for bright & dark areas and a lower (3) quantizier for the medium ones.

[squid_80]

Kopernikus: Could you put up the source for the November 19th build? I tried to use the source from 5th November but it seems to get stuck in an infinite loop somewhere on certain frames.

[Kopernikus]

I will try to put it up asap, but my ISP has disconnected me for a unknown reason, so it may take a while.

[Kopernikus]

So, here is the source for the most recent version (I am not sure if it is identical to the one from Nov 19th):

http://xvid.ist-dein-freund.de/stuff/cg_hvs_061209.diff

It works here, but if you encounter any problems just ask.

[squid_80]

One thing in xvid_encraw.c: if(ARG_HVS_LMB != 0 || ARG_HVS_AQ != 0){
plg_hvs_param_t* hvs_param;
hvs_param = (plg_hvs_param_t*) malloc(sizeof(plg_hvs_param_t));

Is that malloc free'd anywhere? Is it safe to free it after the encoder is created with XVID_ENC_CREATE?

[squid_80]

The infinite loop I'm seeing is something to do with trellis.
line 988 in mbtransquant.c: while(i>=0) {
Out[Zigzag[i]] = Nodes[i].Level;
Sum += abs(Nodes[i].Level);
// if (!(Nodes[i].Run))
// fprintf(stderr, "Warning! Nodes[i].Run == 0 (i = %d)\n", i);
i -= Nodes[i].Run;
}
(The commented lines I added.)
The hvs_aq string I'm using is "quant lc_lum gl_lum - 64 / -". When I uncomment the above lines it gets stuck in that loop on some frame (depends on the input clip) with i = 37. I don't really know how trellis works so I don't know what to look for.

[Kopernikus]

One thing in xvid_encraw.c: if(ARG_HVS_LMB != 0 || ARG_HVS_AQ != 0){
plg_hvs_param_t* hvs_param;
hvs_param = (plg_hvs_param_t*) malloc(sizeof(plg_hvs_param_t));

Is that malloc free'd anywhere? Is it safe to free it after the encoder is created with XVID_ENC_CREATE?

Hmmm, it seems that I forgot to free that memory. I will try to check that and reproduce the trellis bug when I am at home.

Thanks for the report.

[squid_80]

I found the other problem. The Lambda values passed to the plugin were all messed up half the time. I modified encoder.c (starting line 772): if(pEnc->mbParam.plugin_flags & XVID_REQLAMBDA) {
int block = 0;
emms();
data.lambda = pEnc->temp_lambda;
for(i = 0;i < pEnc->mbParam.mb_height; i++)
for(j = 0;j < pEnc->mbParam.mb_width; j++)
for (k = 0; k < 6; k++)
data.lambda[block++] = 1.0f;
}
and all is well. Telling the compiler to target SSE2 also hides the error, maybe that's why no-one noticed it before?

[squid_80]

I tried to send a bug report about the missing emms but can't get through to the mailing list - both xvid-devel@list.xvid.org and xvid-devel@xvid.org bounce back. I thought I might have been kicked off the list but if I try to subscribe I get an email telling me I'm already subscribed. I would really like to get this bug fixed rather than hack xvid_encraw around it or link to xvidcore statically.

[Kopernikus]

The list works again, I have send a mail with a patch, hope it will be fixed soon.

Edit: Michael said it works, but it seems not so, the mail bounced again.

[squid_80]

No email from the list has landed in my inbox :(
I decided to hack around it anyway since I can't be sure the user doesn't have a bad xvidcore.dll. I use a dummy plugin to set the lambda values to 1.0f before the hvs plugin is called.

[squid_80]

Ok now I got your email to the dev list with the patch and Michael's reply about 15 mins later. Thanks.

[plugh]

squid_80 / Kopernicus - a question...

In enc_init, you add the hvs plugin to the array _before_ the pass1/pass2 plugins. Doesn't this plugin want the frame quant assigned by these plugins?

Shouldn't it be added to the array after them, like the lumimasking plugin? Or am I misunderstanding things...

(was thinking about incorporating this into my vfw front end)