WindowsMedia 9 Postprocessing

[peteag]

I know many guys of you don't like windowsmedia 9 very well but I saw something that is very different to the doom9-codec-comparison. I encoded chapter 15 of the beach and I saw that the visual quality in the windows media 9 encoder - previewwindow was very better than the actual playbacked file in the windows media player 9. This is because the wmv-decoder uses deblocking-techniques which I can't turn off. That's my problem.

Does anyone know how to disable the postprocessing-filters of windows media 9? Please answer.

INFO: I know that XviD is also good and I test video-codecs just every second day. I don't wanna hear something of "take xvid, it's even better than windowsmedia!.

[bond]

welcome to doom9
may i remind you that we have rules here, which are there for a reason:

you dont wanna hear "xvid is better than wmv9"?
the rules will ensure that this doesnt happen

the rules also ensure that the same questions dont get asked over and over again, altough they have been answered already...

therefore
:search:

[peteag]

Bond, I was a member on many many many forums dedicated to video-codecs a.s.o. and every time I asked a question to another videocodec that wasn't the honey of the members, everyboday said let it, this codec is bulls**t, take ???, this is even the better choice and I never got any answers.

Sorry for me being to strict but I can't hear these silly I-DONT-KNOW-IT-SO-JUST-TAKE-ANOTHER-answers.I hope you understand.I don't want to hurt somebody but before I get 1000 of these answers I'll just give it up. This is a forum and I just wanted to get an answer of my question and I don't want to waste my time in getting 1000 of silly replys. That's all.

I know your rules but that's my little condition to get a quick and informative answer.

Thanks bond

[bond]

Originally posted by peteag
I know your rules but that's my little condition to get a quick and informative answer.i understand what you mean, but if everyone posts for getting "a quick and informative answer", this forum will become one big mess, like many other forums out there

there have been infos (.reg file?) posted on how to change the registry for disabling the pp in the wmv decoder, so if you stress the search function i am sure you will find what you need ;)

[peteag]

Thank you for your quick reply. Reg-Files were posted? Where can I get this? I searched up the web but I can't find anything. Would you help me?

Thank you.

[peteag]

Well, I fanally found the trick:

here it is
open the registry by executing "regedit"
\HKEY_CURRENT_USER\Software\Microsoft\Scrunch\
and set the
Force Post Process Mode to 0 (zero) and
Post Process Mode to 0 (zero)

both have to set to dezimal mode - not hexadezimal mode.

Bye Bye

[Sagittaire]

This is because the wmv-decoder uses deblocking-techniques which I can't turn off

Post-Process for WMV9 isn't deblocking/dering but smoother filter. PP1 is the best setting for WMV9. PP4 is defaut setting but it's very too high smoother level. PP0 cut off PP but I don't like "MPEG4 Noise Compression" in this mode. PP1 is perfect for medium resolution/bitrate encoding and PP0 could be better for high resolution/bitrate and CPU ressource ( Athlon ~2400+ for 720p PP4 but Athlon ~1400+ for 720p PP0) ...

[peteag]

Maybe, but in my case I want to test the encoders real quality-level compared to DivX 5.2 and XviD 1.0.1 and any postprocessing effect doesn't make any sense to me, because it trys to push up the quality by smoothing out blocks (and this means even details).

For them who just want to watch their wmv-files, they mustn't turn this off or to zero. It's just for a quality-detection. And everyone who makes a codec-comparison (doom9's) should disable any postprocessing filters because they are no part of the ENCODER himself (I guess in doom9's it wasn't so).

[Sagittaire]

CO-DEC is Compresseur and Decompresseur ... if you want test CO-DEC you must test best setting for Compresseur and Decompresseur:

For me VP6 is the best CO-DEC but if you test VP6 without PP4 that blocks everywhere: Visualy VP6 without PP4 isn't a very good codec. In fact you must activate in post-process all the functions which improves the image quality without modifying it (-> best PSNR result)

- MPEG4 ASP PP4
- WMV9 PP0 or PP1
- VP6 PP4

[peteag]

Yes, that's right. But if you want to test a codec you have to test that what takes the longest time. We all know that the postprocessing part isn't comparable to the work the encoder has to bring. So, you talk about VP6. Yes, with postprocessing filters the VP6 looks slightly better. But if this should be the golden way to get the best out of vp6 why doesn't it encode these powerfull processing within the image while it encodes? Postprocessing-Filters are just a quick enhancement to erase artifacts which the encoder produces at low bitrates or very complex scenes. The encoder work is just testable without postprocessing filters.

Something more. You know XviD can be played back with DivX-Decoder and otherwise. So if the DivX-Decompressor (PP-Filter) produces a much better picture at XviD content which codec is then the best?

PP isn't the encoders work, otherwise it wouldn't be called POST-Processing.

[CruNcher]

In fact you must activate in post-process all the functions which improves the image quality without modifying it (-> best PSNR result)


wrong there is no magic pp if pp changes psnr it also changed the texture data i never saw a decoder pp that didn't sacrificed texture quality at least not in mpeg ok vp6 is no mpeg but wm9 is. In general no pp = better detail preservation (texture quality). And Psnr usage to compare diferent codecs is plain wrong also a better psnr result doesn't mean initialy that the visual quality is higher their are easy ways actually even to cheat people who belive that.

[Valeron]

Hi,peteag,please please remember the VCM codec is slightly different from the one work with WMP9/10(which was based on WMV Decoder DMO).As you see,the VCM can not handle b-frame but WME can.
So the reg key for PP setting is just for VCM decoder.But you playback the clip with WMP9.

I can't found any official document from MS about PP setting for WMV9 decode with WMV Decoder DMO till now.

[Sagittaire]

And Psnr usage to compare diferent codecs is plain wrong also a better psnr result doesn't mean initialy that the visual quality is higher their are easy ways actually even to cheat people who belive that.

Everyone say that because XviD isn't best with these test ... lol ... but nobody is able to show an example: A test with a sample which shows that a codec can be visually very better and obtain worse Average PSNR, Overall PSNR, SSIM and VQM ...

All developpers use PSNR for codec improuvements. All developpers use PSNR to compare codec with concurence ...

Personally my visual impressions always go in the direction of the Average PSNR, Overall PSNR or SSIM ...

[peteag]

I make a little codec comparison (http://forum.gleitz.info/showthread.php?t=14672&goto=newpost) together with some others to view which codec is better.

And. I nevere said that XviD isn't the best. I just wanted to turn off the pp-filters.

[Sharktooth]

Originally posted by CruNcher
wrong there is no magic pp if pp changes psnr it also changed the texture data i never saw a decoder pp that didn't sacrificed texture quality at least not in mpeg ok vp6 is no mpeg but wm9 is. In general no pp = better detail preservation (texture quality). And Psnr usage to compare diferent codecs is plain wrong also a better psnr result doesn't mean initialy that the visual quality is higher their are easy ways actually even to cheat people who belive that.
Well not exactly...
Yes, Vp6 is not MPEG but it is very similar, it shares the same principles. However the VP6 PP is the most visually and numerically advanced (PSNR tests) i've ever seen.
I think the PP is an essential part of the vp6 codec, and it INCREASES visual and numerical quality.
It's proven that PSNR is not an absolute quality indicator BUT it still is a signal to noise ratio.
PSNR on single frames is useless... but an overall PSNR or average PSNR can be an absolute quality indicator.
Now i'm not saying that 45.3000db is better than 45.0000db but i can state that 45.3000db is absolutely better than 42.0000db.
With the word "better" i mean close to the original.
Obviously there are ways to make the image look good or better even if it not so close to the original (see the VP6 highest quality PP).

[peteag]

VP6 is even good with turned on PP. But have a look at H.264. The deblocking-process is made while encoding and it is part of the encoding process. Every h.264-codec I've seen until now has no option to turn anything deblocking feature off while decoding. This is just better than any decoder PP. But, what a pity, it's to slow at the moment.

[Sharktooth]

VP6 relays on PP!!! For example it gains the max PSNR setting a specific PP level.
It gains the best quality setting another specific level of PP.
To be honest i dont know if the "in loop" filtering could be better than any other PP.
It just removes the need to have PP to remove artifacts but i prefer to choose wich filters i wish to use instead of having only 1 choice...

[bond]

sagittaire, you know the rules on doom9, dont you? there is no ultimatively best codec existing, so stop spreading stuff like this

[Valeron]

Originally posted by peteag
VP6 is even good with turned on PP. But have a look at H.264. The deblocking-process is made while encoding and it is part of the encoding process. Every h.264-codec I've seen until now has no option to turn anything deblocking feature off while decoding. This is just better than any decoder PP. But, what a pity, it's to slow at the moment.

Not just H.264 support in-loop deblocking.RV10 and WMV9 Advanced Profile also have in-loop deblocking feature.

[On2Tech]

Originally posted by peteag
Yes, that's right. But if you want to test a codec you have to test that what takes the longest time. We all know that the postprocessing part isn't comparable to the work the encoder has to bring. So, you talk about VP6. Yes, with postprocessing filters the VP6 looks slightly better. But if this should be the golden way to get the best out of vp6 why doesn't it encode these powerfull processing within the image while it encodes? Postprocessing-Filters are just a quick enhancement to erase artifacts which the encoder produces at low bitrates or very complex scenes. The encoder work is just testable without postprocessing filters.

Something more. You know XviD can be played back with DivX-Decoder and otherwise. So if the DivX-Decompressor (PP-Filter) produces a much better picture at XviD content which codec is then the best?

PP isn't the encoders work, otherwise it wouldn't be called POST-Processing.

The reason that our post processing helps us more than real's or microsofts help them is is that we haven't already done some deblocking in a loop filter. Its not because our post processing is better than theirs.

Other codecs chose to clean up their reconstruction buffers using a loop filter. The loop filter often cleans blocking and ringing artifacts from the internal frame store ( real, h264).

You ask a relevant question though if the post processing produces a better result why not use it for predicting the next frame? VP6 uses other (patented) methods that adaptively filter predictor blocks rather than the frame store as a whole.

The end result is that if you don't use VP6 post processing, the current frame is not deblocked at all. That's not true for (264 / real / WMV9 ) of as far as I know and so without even basic deblocking our results are not so good.

IMHO you should do the tests with the best results each codec can get. If you can get better results using an xvid encoder and a divx decoder than by all means do so. Just create a graph labeled
XVID encoder / DIVX decoder then compare it.

PPS. Maybe it would just be simpler if we didn't let people shut off our post processor altogether...

[CruNcher]

@On2Tech
i respect On2 but what i don't like is the comparsion on your page that shows this lotr scene, everyone knows that the in-loop filter is on for the Real frame and thats couseing the blurryness if you want to compare fairly the sharpness turn Reals in-loop filtering off.

[Sirber]

and enable HFE2 ^^

[Sagittaire]

i respect On2 but what i don't like is the comparsion on your page that shows this lotr scene, everyone knows that the in-loop filter is on for the Real frame and thats couseing the blurryness if you want to compare fairly the sharpness turn Reals in-loop filtering off.

For RV10 it's an adaptative inloop (quant decision for activation). If inloop is activate quant for frame is high and frame perhabs blocky ... and make comparaison with Capture is useless ... make sample ...


and enable HFE2

HFE2 is Sharp in Post-Process. it decreases the PSNR: it modifies origin image even if it seems more pleasant. That should not be used to compare the codecs ...

[Manao]

Originally posted by On2Tech
VP6 uses other (patented) methods that adaptively filter predictor blocks rather than the frame store as a whole.That's still in loop filtering ( at least the spirit of it ), even if you allow user at decoding to choose between the frame before or after the in loop filter. I wonder, what exactly did you patent ? The principle ( adaptive predictor blocks filtering ) or the filter itself ?
Originally posted by Sharktooth
It just removes the need to have PP to remove artifacts but i prefer to choose wich filters i wish to use instead of having only 1 choice...
You can't compare in loop filtering and post processing, they really aren't on the same level. You can do things with in loop filtering you couldn't make with a simple PP. When using an undeblocked frame as reference frame, as it is with MPEG-4 ASP, you're in fact using a frame that presents artificial edges ( the blocks ). These edges mess up the motion estimation, and after that the motion compensation, which brings edges into the residual which has to be codec with DCT, which brings more ringing.

As soon as the in loop filtering strength is adapted to the quality of the picture ( and it is with h264 ), you can only improve the results with it.
Originally posted by Sagittaire
That should not be used to compare the codecs ...The fact that you wouldn't use it to compare codec doesn't imply it shouldn't be used. Picture is clearly more pleasant on the samples I've seen when enabling HFE2, so why would you ignore it when comparing codecs ? For the sake of PSNR ?

[CruNcher]

@Sagittaire im aware that this might couses blocks but i allready saw implementations of h264 that you didn't and i can say it's not allways the case especialy not in low motion with a good tweaked RC.

[Sagittaire]

objective of codec is to have: output ~ input

If I want more Sharp for my source for have more pleasant image I modifie source with Sharp.

All the image processing (in post-process or post-process) which decrease PSNR (denoise, noise, sharp, blur ...) are modifications of the source which imply a loss of information. Compare modified images isn't a codec comparaison:

exemple

1) source (with noise) -> denoising pre-process -> codec X -> Video A
2) source (with noise) -> codec Y -> Video B
3) source (with noise) -> codec Z -> Video C -> denoising post-process

Visualy codec X will make better result than codec Z and codec Z will make better result than codec Y ... but you can't say that the codec X is better than the codec Y ...


if you want make comparaison you must make this comparaison with source and video not modified ...

source -> codec -> Video
or
source -> codec -> Video -> Post-process which increases PSNR

[Manao]

Sagittaire : Why do you allow postprocessing and not preprocessing ? Codecs may have hidden preprocessing of the source which could improve the results ( when comparing the encoding result and the source unprocessed, with PSNR or SSIM ).

Hypothetically, that preprocessing could even be adjust by the codec and become a part of the encoding process itself, without turning into a kind of in loop filtering.objective of codec is to have: output ~ inputIndeed, but for you '~' is a PSNR/SSIM value, while I prefer the eye. That changes everything. A sharpening filter will almost always decrease PSNR, whereas a blur can improve it. But the sharp picture, for me, is more pleasant, and perhaps closer to the original than the blur one. So which do I trust ? PSNR ? My eyes ?

[Sagittaire]

Sagittaire : Why do you allow postprocessing and not preprocessing ? Codecs may have hidden preprocessing of the source which could improve the results ( when comparing the encoding result and the source unprocessed, with PSNR or SSIM ).

pre-process which increase PSNR ... ???
Exemple please ... !!!

For exemple I try that with c3d:

Source A -> codec -> video A

Source A -> source A' (pre-process c3d) -> codec -> video A'

and PSNR(source A, video A) > PSNR(source A, video A')

for me the pre-process always decreases the PSNR/SSIM but it's perhabs an error. If there is a developer of codec which can deliver its opinion

[MfA]

Originally posted by Manao
As soon as the in loop filtering strength is adapted to the quality of the picture ( and it is with h264 ), you can only improve the results with it.

There is always a chance it will increase distortion (objective and subjective).

[Sirber]

Originally posted by Sagittaire
HFE2 is Sharp in Post-Process. it decreases the PSNR: it modifies origin image even if it seems more pleasant. That should not be used to compare the codecs ... HFE and Sharp is 2 different filter. You can use HFE2 whitout Sharp filter. But, since it'S not orignal grain, it might hurt PNSR tests.

[Manao]

MfA : you're right, of course. But cases in which it decreases quality would be pathological.As soon as the in loop filtering strength is adapted to the quality of the picture ( and it is with h264 ), you can only improve the results with it.I initially wanted to say that even at lowest quant, in loop filtering almost always improved PSNR, but I somehow got lost in the sentence :rolleyes:. I should definitely check what I'm writting.

Sagittaire : I'll make a test and report back.

[Manao]

Test done : source was Amelie, 1000 frames of one of the last chapter ( my processor is still overheating when encoding, so I won't make longer test ).

Avisynth script for encoding was mpeg2source without PP, cropping and no resizing ( why bother ? ), the denoiser was temporalsoften(2,3,3,6,2).

Xvid's settings were H263, no (bframes / qpel / gmc / aq / treilis), VHQ 1, and one pass ~ 1000 kbit/sec ( very low movement on the scene )

The results are :
* Unprocessed : PSNR overall : 46.0565, filesize : 4914KB
* TEmporalSoften : PSNR overall : 46.2626, filesize : 4232KB

Filesize are different, but it's normal, because the temporalsoften clip was saturating at quant 2, while the unprocessed one had 2/3 of quant 3.

Visually, it's even more impressive, because walls are a lot more stable with temporalsoften. I can't make the clip available, I don't have the required bandwith with my connection.

[Sagittaire]

Interessing ... ;-)


You try that with TemporalSoften:

Source A -> codec -> video A

Source A -> source A' (pre-process TS) -> codec -> video A'

and PSNR(source A, video A) vs PSNR(source A, video A')



Or that with TemporalSoften:

Source A -> codec -> video A

Source A -> source A' (pre-process TS) -> codec -> video A'

and PSNR(source A, video A) vs PSNR(source A' , video A')

[Manao]

I made the right test, meaning the first one. The second gives an overall PSNR of 47.1908 ( but serves almost no purposes, except proving that soft clips are less distorted by the encoding process in that case )

[CruNcher]

@Manao
cpu=4 should allready help big time with noise and it isn't a detail killer :)

[Manao]

It's slightly off topic, but, anyway : with cpu=4 in mpeg2source, PSNR overall falls to 46.0618 ( which is better than without, but not as good as temporalsoften ).

Anyway, for more information, Wilbert made an almost exhaustive test some time ago, with SSIM : http://forum.doom9.org/showthread.php?s=&threadid=62332&highlight=denoising

[Sagittaire]

Strange ... here my test with HPII Trailer

XviD q2 for I,P,B and no qpel / gmc / aq / treilis, VHQ 1


Source A: 33 600 Ko

Source=Mpeg2Source("G:\Mes dossiers\B.A\Harry Potter\azerty.d2v")
Source=Trim(Source,70,3145)
Source=Crop(Source,16,76,688,426)
Source=LanczosResize(Source,640,272)
Return(Source)



Source B: 32 384 Ko

Source=Mpeg2Source("G:\Mes dossiers\B.A\Harry Potter\azerty.d2v")
Source=Trim(Source,70,3145)
Source=Crop(Source,16,76,688,426)
Source=LanczosResize(Source,640,272)
source=temporalsoften(source,2,3,3,6,2)
Return(Source)



PSNR(source A, video A)

# --> Video Opening <--

Source=Mpeg2Source("G:\Mes dossiers\B.A\Harry Potter\azerty.d2v")
Source=Trim(Source,70,3145)
Source=Crop(Source,16,76,688,426)
Source=LanczosResize(Source,640,272)
Source=ConvertToYUY2(Source)

video=AviSource("G:\Mes dossiers\B.A\Harry Potter\VA.avi")
video=ConvertToYUY2(video)

# --> PSNR analysis <--
Compare(video,source,"","SA-VA.txt")



PSNR(source A, video B)

# --> Video Opening <--

Source=Mpeg2Source("G:\Mes dossiers\B.A\Harry Potter\azerty.d2v")
Source=Trim(Source,70,3145)
Source=Crop(Source,16,76,688,426)
Source=LanczosResize(Source,640,272)
Source=ConvertToYUY2(Source)

video=AviSource("G:\Mes dossiers\B.A\Harry Potter\VB.avi")
video=ConvertToYUY2(video)

# --> PSNR analysis <--
Compare(video,source,"","SA-VB.txt")



Source A -> codec -> video A
Source A -> source B (pre-process TS) -> codec -> video B


PSNR(source A, video A)

Average PSNR = 47.4108 dB
Overall PSNR = 46.9511 dB


PSNR(source A, video B)

Average PSNR = 47.1295 dB
Overall PSNR = 46.6857 dB

http://jfl1974.free.fr/Video/Test.JPG

[Manao]

Sagittaire : your test is not fair, you are encoding at q2. I encoded at 1000 kbps. The difference, on my clip, was that the filtered clip was at q2 with less than 1000 kbps, while the unfiltered clip needed q2 & q3 to reach 1000 kbps.

[Sagittaire]

My test

Source A: 33 600 Ko and 2184 Kbps
Source B: 32 384 Ko and 2104 Kbps


Your test

filesize : 4914KB and 982 Kbps
filesize : 4232KB and 846 Kbps


...... ???

[Manao]

XviD q2Don't you understand the unfairness of your test ? The denoising / softening can't help if you're saturating both encodes. It helps only because it allows the use of quant 2 where a quant 3 would have been used.

[Sagittaire]

another test with temporalsoften(source,2,3,3,6,2) XviD q4 without bframe ...

Video A: 14 652 Ko
Video B: 14 376 Ko

PSNR(source A, video A)
Average PSNR = 44.1680 dB
Overall PSNR = 43.6381 dB


PSNR(source A, video B)
Average PSNR = 43.9815 dB
Overall PSNR = 43.4971 dB

Frame by Frame
PSNR(source A, video A)

Comparing channel(s) YUV

Mean Max Max
Absolute Mean Pos. Neg.
Frame Dev. Dev. Dev. Dev. PSNR (dB)
-----------------------------------------------------
1000 1.3700 +0.0574 16 -17 42.3957
1001 1.4107 +0.0095 16 -18 42.1470
1002 1.3921 +0.0787 20 -19 42.2564
1003 1.4034 -0.0199 15 -16 42.1914
1004 1.4144 +0.0902 22 -17 42.1427
1005 1.4152 +0.0147 16 -19 42.1681
1006 1.4164 +0.0449 17 -20 42.1588
1007 1.4578 +0.0348 15 -20 41.9044
1008 1.3853 +0.0435 20 -17 42.2745
1009 1.3716 -0.0246 14 -19 42.3582
1010 1.3337 +0.0386 20 -19 42.5020
1011 1.3677 -0.0271 16 -18 42.3456
1012 1.3446 +0.0645 16 -17 42.4915
1013 1.3451 +0.0128 16 -21 42.4908
1014 1.3271 +0.0473 19 -20 42.6968
1015 1.2896 +0.0046 18 -22 42.9481
1016 1.2643 +0.0551 16 -16 43.0771
1017 1.2706 +0.0156 14 -16 43.0946
1018 1.1972 +0.0490 14 -25 43.5297
1019 1.1199 +0.0133 17 -21 43.8406
1020 1.2450 +0.0583 14 -18 43.0846


Frame by Frame
PSNR(source A, video B)

Comparing channel(s) YUV

Mean Max Max
Absolute Mean Pos. Neg.
Frame Dev. Dev. Dev. Dev. PSNR (dB)
-----------------------------------------------------
1000 1.4020 +0.0657 15 -21 42.2393
1001 1.4357 +0.0165 18 -19 42.0101
1002 1.4229 +0.0755 18 -20 42.1119
1003 1.4344 -0.0202 18 -17 42.0299
1004 1.4547 +0.0696 16 -18 41.9369
1005 1.4547 +0.0054 17 -17 41.9577
1006 1.4528 +0.0416 19 -21 41.9751
1007 1.4975 +0.0565 16 -17 41.7269
1008 1.4214 +0.0528 17 -23 42.0937
1009 1.4011 -0.0114 17 -20 42.1925
1010 1.3803 +0.0269 19 -18 42.2719
1011 1.4079 -0.0319 14 -18 42.1693
1012 1.3948 +0.0450 15 -17 42.2546
1013 1.4039 +0.1093 14 -18 42.2277
1014 1.3326 +0.0753 15 -21 42.6879
1015 1.3008 +0.0156 16 -25 42.8781
1016 1.2704 +0.0687 16 -18 43.0384
1017 1.2690 +0.0189 15 -19 43.0986
1018 1.1963 +0.0553 14 -25 43.5292
1019 1.1211 +0.0105 15 -20 43.8400
1020 1.2889 +0.0633 15 -17 42.8851

[Sagittaire]

Anyway, for more information, Wilbert made an almost exhaustive test some time ago, with SSIM : http://forum.doom9.org/showthread.p...light=denoising

I think it isn't metric(source A, video A) vs metric(source A, video B) but metric(source A, video A) vs metric(source B, video B) ...

If to increase PSNR/SSIM it was necessary to put pre-process I think that all the codecs would do it ... And if it's possible why doesn't use this technique ... ???

[Manao]

Please, dear moderators, cut this thread in two parts, it's becoming heavily off topic

Sagittaire : stop playing dumb, I know you know better than that. Which part of "allow the use of q2 where q3 would have been used" did you not understand ? Making a test at quantizer constant is groundless. Just have a look at the following analogy, which is not entirely accurate but should help to illustrate my thinking :

Lets say that at constant quantizer, the codec works as if it was modifying each pixels by a value ( if quantizer 2, it adds 2 to each pixels, quantizer 5, 5 to each pixels, and so on ). ( In reality, it's adding a noise whose strength is related to the level of the quantizer )

Now, let say the denoising modify each pixels by 0.5 ( there again, it's closer to adding a noise, but anyway ).

Now, at constant quantizer, prefiltering will hurt quality, because it will bring wore distorsion ( if we assume that distorsion are cumulative ).

But, if we encode at a fixed bitrate, the denoising will for example allows 2/3 of the frame to be encoded at a lower quantizer, and then we will gain a little if we denoise before encoding.I think it isn't metric(source A, video A) vs metric(source A, video B) but metric(source A, video A) vs metric(source B, video B) ...I think not. Please do reread the thread, particularly : Compare original source to the filtered and compressed source
That's what I did.
If to increase PSNR/SSIM it was necessary to put pre-process I think that all the codecs would do it ... And if it's possible why doesn't use this technique ... ???Because it's almost impossible to know in which case apply which filter. And some codecs may do that without you knowing it ( you don't have the sources of VP6, RV10, DivX5 )

[On2Tech]

You can't compare in loop filtering and post processing, they really aren't on the same level. You can do things with in loop filtering you couldn't make with a simple PP. When using an undeblocked frame as reference frame, as it is with MPEG-4 ASP, you're in fact using a frame that presents artificial edges ( the blocks ). These edges mess up the motion estimation, and after that the motion compensation, which brings edges into the residual which has to be codec with DCT, which brings more ringing.


I understand where you are coming from. But please take my word for it. We do not have a loop filter, and we get better results using our method than if we did have a traditional h264 like loop filter (we've done comparisons and have nothing that would restrict us from using one).

The end result is that if you don't use postprocessing on our stuff vp6 is hurt more than if you don't use postprocessing on most other codecs. Our PSNR / visual results etc are definitely better with the deblocker, as are the other codecs.

If codec A + postprocessing A is better than codec B + post processing B who really cares if codec A is worse than codec B without postprocessing?

[Sagittaire]

The end result is that if you don't use postprocessing on our stuff vp6 is hurt more than if you don't use postprocessing on most other codecs. Our PSNR / visual results etc are definitely better with the deblocker, as are the other codecs.

I think that too ... :D

[MfA]

Originally posted by On2Tech
I understand where you are coming from. But please take my word for it. We do not have a loop filter, and we get better results using our method than if we did have a traditional h264 like loop filter (we've done comparisons and have nothing that would restrict us from using one).

If there is filtering being done in the loop it is in loop filtering ... whether it is done on on predicted blocks used during MC or the entire frame is rather irrelevant.

In principle if you have the cycles to spare your method of doing seperate post processing on the reconstructed frame without an in loop filter applied should obviously be better ... a good in loop filter is not necessarily the best postprocessing filter for viewing.

By the by, if anyone is interested ... Microsoft finally is revealing some details about wmv9, they will have an article on it in "Signal Processing: Image Communication". At the moment only a preprint is available at elsevier's science-direct (and here (http://home.student.utwente.nl/m.f.al/wmv.pdf)). They also use a loop filter, and lapped block coding of the intra frames.

[On2Tech]

Originally posted by MfA
If there is filtering being done in the loop it is in loop filtering ... whether it is done on on predicted blocks used during MC or the entire frame is rather irrelevant.


not quite. If you deblock during prediction only the predictor is deblocked. So in effect you stop blocking artifacts from moving inside the block and forcing yourself to correct a high frequency edge inside the block. It doesn't stop blocking artifacts from appearing at block edges due to quantization of the current frame. That is to say the reconstructed frame still has the blocking artifacts any new blocking artifacts from quantization of the current frame will still show unless you remove them via post processing.

[lexor]

If codec A + postprocessing A is better than codec B + post processing B who really cares if codec A is worse than codec B without postprocessing?

Seriously that's the dumbest argument I have ever read anywhere.

hmm... I don't know... who whould care? All the people with weaker PC's and Stand Alone makers, who don't want to waste precious cpu clocks postprocessing for A, when they can get same picture without postprocessing on B? But nah... they just gonna spend money buying more powerful equipment, and then again when new codecs are developed, and then again, 'couse you know how we all rich, righ?

[lexor]

BTW, why is there a discussion? The guy asked how to turn off something, what's with all the tests and arguments?

p.s. made this separate so it doesn't get consumed by the flames above :)

[On2Tech]

Originally posted by lexor
Seriously that's the dumbest argument I have ever read anywhere.

I'm sorry that you seem to have missed some of my blatantly stupider arguments. :)

hmm... I don't know... who whould care? All the people with weaker PC's and Stand Alone makers, who don't want to waste precious cpu clocks postprocessing for A, when they can get same picture without postprocessing on B? But nah... they just gonna spend money buying more powerful equipment, and then again when new codecs are developed, and then again, 'couse you know how we all rich, righ?

You are right to point out that some machines might not see a postprocessed image. Of course if the complexity's built in to the loop filter, you are just plain screwed, and won't be able to play the clip no matter what.

VP6 runs with minimal filtering ( prediction / loop) whatever the term is, is turned off in hi-def situations. We also don't support B frames ( they add to complexity). The end result is that we should be able to afford to do some post processing in most situations and we do offer different levels of post processing for different situations. By default the codec times itself and attempts to pick the best post processing it can do given the time its got available.

[lexor]

Originally posted by On2Tech
I'm sorry that you seem to have missed some of my blatantly stupider arguments. :)

I'll make a search on your user name ;)


VP6 runs with minimal filtering ( prediction / loop)

well I suppose that's a plus in this case, but I never actually argued agains VP6, your argument was for any codec A vs. codec B, that seemed very presumptious.

[CruNcher]

@On2Tech
the only problem i see quality wise with Vp6 is the RC i mean other allready realized this like Real and changed to a more efficient XviD alike one whats On2 doing in this sector and will we see improvements in that direction ?

[Sagittaire]

It's bitrate calculation for 2 pass encoding ABR and oversize is very little with VP6 default setting ...


Bitrate 500 Kbits/s 1000 Kbits/s 1500 Kbits/s 2000 Kbits/s
XviD 87 920 Ko 175 928 Ko 264 232 Ko 352 360 Ko
RV10 88 362 Ko 176 397 Ko 264 780 Ko 353 382 Ko
VP6 89 542 Ko 178 532 Ko 266 106 Ko 354 322 Ko
WMV9 88 362 Ko 176 482 Ko 264 550 Ko 352 730 Ko
DivX5 88 614 Ko 176 972 Ko 265 094 Ko 353 100 Ko
DivX3 88 518 Ko 176 516 Ko 264 516 Ko 352 520 Ko

True 88 125 Ko 176 250 Ko 264 375 Ko 352 500 Ko


But if you want a security for VP6 use true bitrate - 1%

for exemple 1024 Kbps for XviD ~ 990 Kbit/s for VP6

[salatec]

You can find Windows Media Postprocesser at this site (http://www.hot.ee/salasource/) (bottom of that page).