XviD-01082002-1

[Koepi]

I don't remember who added the new lumi code, but it has to be tweaked, the hardcoded values don't do much. I think it's mentioned in the thread linked above.

Regards,
Koepi

[Nic]

(yay...chemn did the green bug fix) :D

-Nic

[Koepi]

const float DarkThres = 0.25;
const float DarkAmpl = 7.0;

const float BrightThres = 4.0;
const float BrightAmpl = 5.0;

const char LowestVal = 10;

const float GlobalBrightThres = 220.0;
const float GlobalDarkThres = 20.0;
float global_quant = 1.0;


If someone has some better values which I should hardcode (and please, not too strong, it should not produce artefats), I would gladly set them for the next build.

Any ideas?

Regards,
Koepi

[Koepi]

Hehe, yeah, that's nice :)

Btw., welcome back Nic!

Regards,
Koepi

[MaTTeR]

@Koepi

Might it be possible to have a few fields to allow the user to tweak the values? It sounds cool but I'm not a coder so I don't know what would be involved for such a beast. Just a thought.

[Koepi]

Matter,

this would make a change of the XviD API necessary which the core developers really, really badly dislike.

So either you come up with better values or you have to use acaila's xvid builds. ;)

Regards,
Koepi

[Acaila]

Well, unless someone knows what all those variables do, all we users can give you is a guess. And that wouldn't be very helpful. Is there no way we can tweak those values (temporary vfw interface?) without each new value requiring a new build?
My solution was only meant to be temporary anyway.

[Koepi]

I sent out an email if some developers already have found better values or if they agree on an API change.

Regards,
Koepi

[MoonWalker]

I saw that the values have changed now...


const float DarkAmpl = 14 / 2;
const float BrightAmpl = 10 / 2;
const float DarkThres = 70;
const float BrightThres = 200;

const float GlobalDarkThres = 60;
const float GlobalBrightThres = 170;

const float MidRangeThres = 20;
const float UpperLimit = 200;
const float LowerLimit = 25;


But I can't compile it to know if they are better :(, so I am waiting for a build :)...

MoonWalker

[Koepi]

Well, that's the old luma masking code.

The new one seems to really f*** up in some situations (maybe those in SPR?), so I'd say just wait a little... There is some action amongst the xvids devels going on, let's see what happens.

Regards,
Koepi

[Koepi]

XviD-04082002-1:
- EPZS motion search reactivated.
- Old luma masking code is back, new one was buggy.

Let's see if this helps it.

[soulfx]

There shoudn't be any problems arising becuase of enabling luma masking in both passes, right? I remember this got fixed, as that is why in first pass mode luma isn't greyed out anymore.

BTW, to test my encodes I use my laptop since it's screen (as is the nature of LCD) provides a better way to see any blocking or artifacts.

And as a side note: I've got SPR sitting right here next to me, if anyone want's me to run some tests or something.

[MoonWalker]

:rolleyes: I haven't seen how the old lumi was, so I supposed it was the new one :)...

@Koepi
And a request for a simple hint :)

How to you activate the EPZS and/or EPZS^2 code??The current configuration is


/nologo /ML /W3 /GX /O2 /Ob2 /D "NDEBUG" /D "ARCH_X86" /D "WIN32" /D "_MBCS" /D "_LIB" /Fp"Release/core.pch" /YX /Fo"Release/" /Fd"Release/" /FD /c

I suppose you add a /D switch...

Thanks in advance,
MoonWalker

[Koepi]

Yes please, try "load defaults" with this new build, enable luma, search precision 6, the stats file, and maybe even MVH. Use h263 for first pass please.

For second pass choose doom9's size, using modulated quantizer, maybe raise alt curve high/low to 500(!). Limit iframe-quantizers between 2 and 6 and pframe quantizers between 2 and 31 (or 16, it's up to you here ;) ).

The credits should be 15% (dunno the credits range though).

Thanks for offering! I'd be glad to hear if in the first scenes in the second pass the quantizer still gets aroun 8-12 or even higher...

Best regards,
Koepi
Regards,
Koepi

[Psyche]

In which way was the new lumi-masking buggy? I have not seen a word about it in xvid.org forums (at least I don't remember) and Isibaar only states in CVS "back to the old lumi-masking". In fact, I thought the new algos for adaptive quant were better than the old ones.
Do you know the reason for that change, Koepi?

EDIT: disabled signature, showed up wrong here and made the post unreadable.

[Koepi]

Originally posted by MoonWalker
How to you activate the EPZS and/or EPZS^2 code??The current


It's not that easy.

Since it is experimental code, you have to define it in the core (motion.h, comment out PMVfast and remove comments from EPSZ), in VFW you have to add some line to codc.c (you need in frame.general an additional XVID_ME_EPZS and for the search you must add PMV_USESQUARES16 to the search precision flags for 6-ultra high.

[Marc FD]

@Koepi

I think making 2 builds :
- XviD Basic with some default settings choice, no SMP, no Bframes, no Qpel, no Alt-CC = nothing experimental, BUT a little bit pre-processing (it's easy to trick newbies, see the interest for RV9, the more filtering-user encoder in the world, or DivX 5, who blurs data to avoid blocking ...)
-XviD Pro (without any ad-ware !!) with all settings, lumi-masking setings, optionnal Bframes/SMP/Qpel support and tweakable pre-processing

Is getting somehow the best solution, no ?

BTW for me you can't get the best of XviD without filtering because it's an "honest" codec who will not blurs-them-all, and try to keep the a result close to the original (original noise i mean -sic-).
It's why i'm trying to improve filtering (as an avisynth filter coder)
I think XviD is far better than some codecs (---- 5 --9) when used with the right filter-chain (i mean HQ filter-chain, not something who wash out the video)

PS : What's making me the more laughing are the comments of doom9 on RV9 :
"the picture just seemed the most visually appealing to the eye"
yep, you got it, that's what filtering is designed for :)

EDIT : Okay now i've censored myself :) . I'm back to normal ;)

[Koepi]

Marc,

hm, maybe you want to edit that post.

Doom9 tried to help where he could without biasing the results. If there is broken luma code in CVS, he can't do anything against it (and I was in the believe that this code really works "better" whilst it works _different_. I.e. look at SPR, it totally fucked up there. I.e. matrix - it did quantise some things away without really gaining bitrate, I'm redoing matrix now and it seems to be better the old way.)
Btw., SPR in that resolution really needs luma masking to somehow still look ok, it's a classical 3 or even 4 CD movie...

Psyche,

the "new" code was working wrong in that way that it simply quantised away when e.g. a bright area had small dark spots or a dark area has "light spots". Isibaar has a nice example, a car where you can see the lights in the night. The only detail attracting your eyes are these lights, and those now get heavily quantised, resulting in a bad quality. The "old" code is a little more sophisticated and takes care of such situations (to speak a little untechnically), it just quantises higher in a overall "medium brightness" range.
Still, the old code gives a real impact in bitrate usage without sacrifycing too much quality, whilst the "new" code was quantising heavily obviously without giving a noticable bitrate gain.
EDIT: so much for the theory, I'm finishing my matrix-test tonight qt ~4a.m. and then we'll see...

Regards,
Koepi

[Psyche]

OK, thanks for the explanation, I guess it's been talked about in IRC, isn't it?

BTW, I've removed my signature now, I've had enough of "it shows bad". But I'm not blaming you. It's mozilla's fault, not mine.
BTW2, my signature was a DeCSS written in perl.

[MaTTeR]

I thought it was agreed upon by a few regular posters here awhile back that lumi wasn't the best option for a 2CD(1400MB) rip. Am I wrong?

Marc,

Calm down man. You made some valid points though about how honest the codec really is :-) Clearly the people in this forum knows what sort of results Xvid can provide compared to the "others". I had no idea the lumi code was broken in that build from the 27th, I used that build several times without issue until switching to Acaila's. Disappointing but who really cares in the end...always other comparisons down the road.

[Koepi]

Matter,

for SPR it is necessary to enable luma masking to put it on a 2CD, I often read that in the past. It's simply too demanding.

Regards,
koepi

[Bartjess]

it rox

[ookzDVD]

@Koepi,

I think your latest build (04-08-2002) have GUI bug,
the Alt.CC tab and Credits tab.

Thank you.

[BiaTch 5.0]

Originally posted by soulfx
There shoudn't be any problems arising becuase of enabling luma masking in both passes, right? I remember this got fixed, as that is why in first pass mode luma isn't greyed out anymore.

BTW, to test my encodes I use my laptop since it's screen (as is the nature of LCD) provides a better way to see any blocking or artifacts.

And as a side note: I've got SPR sitting right here next to me, if anyone want's me to run some tests or something.

I'm a newbie but IMO use it in the second pass only I encoded From Hell XviD-27072002-1 & I got some pinky background frames with lumi both passes.

[rui]

WHO!

A guy spends a few days away from the forum, and when he returns, all the "encoding world" is turned upside down. :D

We have new builds, with new (old) lumi, new speed improvements, new codec comparison tests, etc., etc. :p

It's good to have you back Nic. I hope that my fellow countrie men, and women, have treated you well. :)

[rui]

Originally posted by BiaTch 5.0


I'm a newbie but IMO use it in the second pass only I encoded From Hell XviD-27072002-1 & I got some pinky background frames with lumi both passes.

Well, i made 3 small tests using the latest koepi's build, all with default parameters except for motion search precision 6 and HME.
The 1st using no lumi at all, the 2nd using lumi in 2nd pass only, and the 3rd using lumi in both 1st and 2nd pass.

I must say that the one using lumi on both passes was better than the one using lumi in the 2nd pass only.
Of course that BiaTch 5.0 opinion is a valid one, i just wanted to express the results i got.

I have made some movie encodings using lumi in both passes and didn't got any problems till today. But i also have to admit that test with no lumi was the best looking.

After having read the codecs test made by doom9, i was a bit surprised, because i didn't experienced any problems with the new lumi code. I didn't test for compression gains, but i didn't got the problems he mentions in the comparison, either.

But i didn't encode SPR, maybe that movie in particulary is problematic :confused:

[soulfx]

I've got this thing running through a SPR encode right now. I'll test it on my laptop and look for anything unusual.

SPR is a really hard movie to compress. I've ran Jonny's compression check... first with your run of the mill 640'ish resolution; result 36.47%. Then set the resolution a bit lower and had it at 45.63%. Those are some low hitting results for something going for a 2 cd backup (it seems SPR may be more suitable for a 3 CD backup), but with 2 CD's one can sure see how a Codec does under some heavy situations.

I've setup two encodes, one with luma mask only in the second pass and the other with luma mask in both passes. Um, yeah, it's going to be a while.

[Koepi]

Please use luma masking (if you use it) in boith passes. The curve compression works better and this helps getting better results (in terms of "constant quality", if you just use it on 2nd pass, you'll have somwhere unpredictable bits over, which get used _later_ instead in the scene where you could use them).

Regards,
Koepi

[Koepi]

Changelog:

XviD-05082002-1:
- Separated greyscale for main movie and credits.

Well, and some other changes... gruel was so nice to include them into CVS very fast.

Another point, I switched back to PMVfast for testing as I think I saw something whcih _could_ be produced by an incorrect implementation of EPZS, it is somewhat "shifting the wrong details through the picture", resulting in a "line" where it doesn't belong.
But since I can't know for sure I'm redoing the encoding now with the PMVfast code and hope to see a difference.

So far a small status report from my side ;)

Best regards,
Koepi

[int 21h]

Currently I achieve better quality with the 6-28 build available on Nic's page than any of the recent builds.. but I'm sure it will be sorted out soon.

[soulfx]

Allright, well the SPR encode has finished.

XviD-04082002-1 was used to encode and luma masking was set in both passes. Motion Search was 6, Modulated Quants were used, I-frame Min/Max 2/6, P-frame Min/Max 2/16, Alt CC used at Default Medium settings. Credits were trimed. Target size used was: 1519618 (2x800MB XCD). Resolution output was 512x288. Cropped 3 off left and right. SimpleResize2 Algo.

I know these settings differ from Doom9's, but I wanted to get one done using the settings I would use.

I made a bunch of framegrabs at the same spots Doom9 did his (or as close as I could get it) that you can check out below:
http://members.cox.net/soul.fxpro/sprtest/clip1.jpg
http://members.cox.net/soul.fxpro/sprtest/clip2.jpg
http://members.cox.net/soul.fxpro/sprtest/clip3.jpg
http://members.cox.net/soul.fxpro/sprtest/clip4.jpg
http://members.cox.net/soul.fxpro/sprtest/clip5.jpg
http://members.cox.net/soul.fxpro/sprtest/clip6.jpg
http://members.cox.net/soul.fxpro/sprtest/clip7.jpg
http://members.cox.net/soul.fxpro/sprtest/clip8.jpg

I also put together a sampleclip from all the locations used in the framegrabs.
http://members.cox.net/soul.fxpro/sprtest/sampleclips.avi

I am sorry to report, but in my hurry out the door after setting the encode to start I must have closed out Dbgview. :( So I don't have a report to generate.

It would have been nice to see what kind of output Doom9 was getting (even though it was crappy) from his SPR encode. That way we could all know how bad it actually was.

Peace,
SoulFX

[Koepi]

Thank you very much for you efforts, SoulFX :) I really appreciate it!

Well, with these settings it seems to be watchable if the screenshots are representative IMHO.

Best regards,
Koepi

[yokem55]

The difference though is that Doom9 encoded SPR at 640x352....a much higher resolution. Your test may not be representative of what Doom9 got from his encode...also watching the video, I wasn't that impressed that with 200mb extra space and 20% less resolution it would look better than it did....very fuzzy and blurry, but this is likely due to the reduced resolution and the simple resize filter (which isn't known for quality).

[cult]

doom9 says he used BicubicResize(640,352,0,0.5) for spr and targeted for 1400mb.
Your settings were simple resize 512x288 and aimed for 2x800cds
A little bit unfair for the other codecs.Dont know how much it affects the results but I am sure that it does.
Anyway,imho r9 is even more blurry than divx5.I wouldnt use it for any serious ripping(i dont rip anime).I mean,come on guys,look at the screenshots,there is no detail at all.If u like to watch such a movie well be mu guest.My choise-xvid.I use it for the 1st time to encode a "from here to eternity".A nasty 4:3 b&w movie full of noise.Divx4 couldnt make with it but xvid(a late february build),made a perfect encoding.I use it since then.
Xvid is the king of the hills.It rox
A big thank to all the guys out there for your great work.

[BiaTch 5.0]

Using; 04082002-1 I got some grey blocks in credits the movies where; The Hole, & Cobra(both Pal/interlaced/field resize), using; quant 31.

[rui]

Well, at least from my point of view, the night scenes aren't that bad. Yes, you used a low resolution, but maybe the new (old) lumi code is making the diference. Like i said earlier, i never had problems with the old (new) code,(man, this is getting confusing :D), but i never encoded SPR.

I think that soulfx deserves the a big thanks from all of us for his hard work :)

At least he made the test, not like me who only do "small" tests (working in a p2-350 can be a trouble). ;)

[Koepi]

Originally posted by BiaTch 5.0
Using; 04082002-1 I got some grey blocks in credits the movies where; The Hole, & Cobra(both Pal/interlaced/field resize), using; quant 31.

You sure just forgot that quantizers >20 are a little buggy, right?

Regards,
Koepi

[rui]

Originally posted by Koepi
Changelog:

XviD-05082002-1:
- Separated greyscale for main movie and credits.


Great!

Originally posted by Koepi

Another point, I switched back to PMVfast for testing as I think I saw something whcih _could_ be produced by an incorrect implementation of EPZS, it is somewhat "shifting the wrong details through the picture", resulting in a "line" where it doesn't belong.
But since I can't know for sure I'm redoing the encoding now with the PMVfast code and hope to see a difference.

Well, i hope that you find out that EPZS didn't have anything to do with it, because it would be a shame. :(
I really noticed a diference in details when making a encode using uManiac's builds (PMVfast) and your/Nic's builds (EPZS).

[Koepi]

Well, I fell over a bug which can't be cleared up easily (EPZS isn't approved to work with adaptive quant.[luma masking] etc), so for now I'll stay with PMVfast, the impact isn't _that_ huge. I redid my encodings and they look fine (and bugfree ;) ).

Regards,
Koepi

[iago]

@Koepi

I'm about to start a test encode with the 05082002-1 build. Should I use the default values for Max I-frame/Min I-frame intervals (300/1) in the first and the second pass?
(Otherwise, I'm considering to change them to 240/4)

Other values will be (as you suggested):
UltraHigh/H.263/LumiMasking enabled for the first pass.
UltraHigh/Modulated/LumiMasking enabled/Min-Max I-frame:2-6/Min-Max P-frame:2-16/AltCC:default and all the rest with default values for the second pass.

Movie: Fight Club (2:19 hr)
Resolution/Resize: 576*240/Bilinear
VideoSize: 614000 kb

Thanks in advance and best regards,
iago

[ookzDVD]

@rui


I really noticed a diference in details when making a encode using uManiac's builds (PMVfast) and your/Nic's builds (EPZS).

so... which one is more details ?


@Koepi
Thank you for the test ;)
so... starting the latest build (05-08-2002),
you will use the PMVFast until EPZS bug fixed ?

Thank you.

[Koepi]

Originally posted by iago
@Koepi

I'm about to start a test encode with the 05082002-1 build. Should I use the default values for Max I-frame/Min I-frame intervals (300/1) in the first and the second pass?
(Otherwise, I'm considering to change them to 240/4)


Please, leave them as-is. The new code is handling consecutive keyframes very gracefully.


Other values will be (as you suggested):
UltraHigh/H.263/LumiMasking enabled for the first pass.
UltraHigh/Modulated/LumiMasking enabled/Min-Max I-frame:2-6/Min-Max P-frame:2-16/AltCC:default and all the rest with default values for the second pass.

Movie: Fight Club (2:19 hr)
Resolution/Resize: 576*240/Bilinear
VideoSize: 614000 kb

Thanks in advance and best regards,
iago

Settings look good, but fightclub is a very compressable movie.
I'd suggest you use simple resize or neutral bicubic, heading for 640x272. Let XviD do it's magic :)

Regards,
Koepi

[Koepi]

Originally posted by ookzDVD
@rui


so... which one is more details ?


EPZS should deliver more details of course. But in the moment the risk for getting some broken images is high. So it should be better and more safe to use PMVfast.
I think about adding another search option for search precision 6, but i need approval first (and I just do it if i get approval that it may help something).


@Koepi
Thank you for the test ;)
so... starting this momemt, you will use the PMVFast for your build
until EPZS bug fixed ?
Thank you.

Well, kind of. There's some new ME in the queue again, so I'd say let's stay with safe code for now and switch over later (even at run time selectable possibly).

Regards,
Koepi

[iago]

@Koepi

Absolutely! Tweaking the settings to 640*272 and neutral bicubic immediately... :) (so that Xvid can do its magic :))

Thanks a lot for the immediate reply regarding Min-Max I-frame intervals,

iago

[Gannjunior]

Originally posted by Koepi


EPZS should deliver more details of course. But in the moment the risk for getting some broken images is high. So it should be better and more safe to use PMVfast.
I think about adding another search option for search precision 6, but i need approval first (and I just do it if i get approval that it may help something...

Could you explain me the mean of EPZS and PMVfast,please?
Checking "enable greyscale" what do I obtain?i have to use it in 1st and 2nd pass?
I'm going to encode Platoon. Which could be the best settings for alt curve? 500-90?if you have some experimental settings that you like to test and that could be ok for Platoon, i'm happy to test them.After I could post results with debugview.

thx

ciao :D

[iago]

@Koepi and everybody,

Koepi's 05082002-1 build - Test Encode:

Fight Club (2:19)
640*272
Simple Resize
Aimed Video Size: 623800 kb

First pass is finished with a Gnot quality/compressibility value of 56.4 and the Bits/(Pixel*Frame) value was 0.147, both of which are very critical imho. So we really need Xvid do its magic :).

When the second pass is finished (and after I watch the most likely-to-be-problematic parts of the movie) I'll post the results in detail.

So long,
iago

[Koepi]

Thx iago,

you will be surprised. GKnot's defaults are clearly "too high" for XviD, that's what I saw sometimes here with some encodes the people made.

But wait until I can verify my actual build to work correctly.
Should be another quality gain...

You'd need another 2pass then ;)

But I'm confident that it works out nicely now already.

Best regards,
Koepi

[Mechannibal]

Originally posted by Koepi
Well, I fell over a bug which can't be cleared up easily (EPZS isn't approved to work with adaptive quant.[luma masking] etc), so for now I'll stay with PMVfast, the impact isn't _that_ huge. I redid my encodings and they look fine (and bugfree ;) ).

Regards,
Koepi

EPZS isnt approved to work with "adaptive quant.[luma masking] etc)", but would previous builds that had EPZS enabled work fine if I did not use lumi masking or other adaptive quant.?


Originally posted by Koepi
EPZS should deliver more details of course. But in the moment the risk for getting some broken images is high. So it should be better and more safe to use PMVfast.

In your tests were the broken images because you used lumi masking with EPZS?


Also, what are the other types of adaptive quant.?

Thanks, I am trying to determine if some of my recent encodes (07272002) are ok.

Mechannibal

[Gannjunior]

@Koepi
have you seen my post?(before Iago)
thx
ciao

[iago]

@Koepi and everybody


Koepi's 05082002-1 build Test Results:

Movie: Fight Club (2:19 hr)
Resolution: 640*272
Resize: Simple Resize
Aimed Video Size: 623800 kb

First Pass setup:

6.UltraHigh
H.263
Max I-frame interval: 300 (default)
Min I-frame interval: 1 (default)
Lumi masking enabled
No Hinted ME


Second Pass setup:

6.UltraHigh
Modulated
Max I-frame interval: 300 (default)
Min I-frame interval: 1 (default)
Lumi masking enabled
No Hinted ME
Min-Max I-frame quant: 2-6
Min-Max P-frame quant: 2-16
AltCC with default parameters
All the rest with default values


-------------------------------------------------------
Results:
-------------------------------------------------------

DebugView analyzer for XviD codec v0.9 by MoonWalker
e-mail : s_ilias@gmx.net


Quantizers Analisis
---------------------

Quantizers Used For Movie :
------------------------------
Quant 2 Used : 2429 Times, Percentage Used : 1.24%
Quant 3 Used : 125567 Times, Percentage Used : 64.06%
Quant 4 Used : 66422 Times, Percentage Used : 33.89%
Quant 5 Used : 1584 Times, Percentage Used : 0.81%
Quant 6 Used : 13 Times, Percentage Used : 0.01%

Average Quantizer Used for Movie : 3.343

Quantizers Used For Credits :
--------------------------------
Quant 31 Used : 4187 Times.

MPEG Quantization Type Used 132183 timed, Percentage Used : 66.02%

H.263 Quantization Type Used 68019 timed, Percentage Used : 33.98%

Quantizers prevented from rising too steeply 0 times


Intra-Frame (Key-Frame) Quantizers
------------------------------------

Movie
-------
Quant 2 Used : 4 Times, Percentage Used : 0.16%
Quant 3 Used : 2229 Times, Percentage Used : 91.43%
Quant 4 Used : 192 Times, Percentage Used : 7.88%

Credits
---------
Quant 31 Used : 13 Times, Percentage Used : 0.53%

Number Of Consecutive I-Frames : 174

Inter-Frame (P-Frame) Quantizers
------------------------------------

Movie
-------
Quant 2 Used : 2425 Times, Percentage Used : 1.23%
Quant 3 Used : 123338 Times, Percentage Used : 62.37%
Quant 4 Used : 66230 Times, Percentage Used : 33.49%
Quant 5 Used : 1584 Times, Percentage Used : 0.80%
Quant 6 Used : 13 Times, Percentage Used : 0.01%

Credits
---------
Quant 31 Used : 4174 Times, Percentage Used : 2.11%



Frame Analisis
----------------

Number Of Intra-Frames (Key-Frames) : 2438
Number Of Inter-Frames (P-Frames) : 197764
Total Number Of Frames : 200202

1.22% of the Movie is Intra-Frames (Key-Frames)
98.78% of the Movie is Inter-Frames (P-Frames)



Size Analysis
----------------

1-Pass Size : 1133919433 Bytes or 1107343 KBytes
Scaled Size : 633962737 Bytes or 619104 KBytes
Actual Size : 634056440 Bytes or 619195 KBytes
Compressibility : 55.92%
Quality of XviD avi : 59.83%

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

And, last but not least, I would like to state my own comments after watching certain parts of the movie.

First of all, there is a green bar at the right side of the screen throughout the movie, independent from ffdshow filter. After uninstalling ffdshow and watching the movie in three different players besides checking in vdub, the green bar is still there :(.

Secondly, ffdshow filter produces lots of strange artifacts (pink blocks floating especially at the right side of the screen) both in simple and xvid IDCT. Guess we urgently need Nic's decoder filter :).

And finally, the visual quality of the encoded movie is unfortunately very poor (or at least worse than any of my previous SBC encodes for testing purposes, whatever the resolution or the resize filter is), with a blurry image with many blocks and floating surfaces all over the movie :(.

(My eyes can't deceive me this much, so I even dismissed the idea of attaching some screenshots :()

That's all for now; but I guess there IS something going wrong, though "I" don't know what :confused:. Perhaps the altCC settings?.

Waiting for your opinions and comments.

Best wishes and my best regards,
iago