Filter for eliminating DCT blocks

[MaTTeR]

Originally posted by iago
@MaTTeR

What settings are you considering to try? I wanna compare it with mine! ;)

Well the 4:3 source I'm testing has quite a few noticeable blocks with lots of scenes containing walls:( Overall this movie is soft and not very sharp so I thought I'd use UnFilter for faces and main objects. Walls are becoming a dirty word for me these days. lol So I started my encode with the following-
mpeg2source("D:\DIvX RIPs\Apostate\apost.d2v",iDCT=2)
crop(4,4,712,472)
Convolution3d(preset="movieHQ")
Blockbuster(method="sharpen",block_size=4,luma_offset=-1,luma_threshold=25,detail_min=1, detail_max=16)
Unfilter(3,3)
BicubicResize(528,392,0,0.4)
undot()
Limiter()

[cult]

@MaTTeR
what is Limiter() ??

[SansGrip]

And know what! Just before BlockBuster I have FluxSmooth in my test scripts too, with some more aggressive settings than the defauls! ;)

Awesome! What settings? How do you like it?

[MaTTeR]

cult,

From sh0dan
If anyone is testing the alpha, you could also try the new version, with the new "limiter" filter. It works like SansGrips Legalclip, except you can specify parameters, and it's much faster (ISSE optimized).

Usage:

Limiter(minimum luma, maximum luma, minimum chroma, maximum chroma)

Default parameters are the same as LegalClip (default YUV range). Funny thing is that it can also be used for color correction.

In short it's "clamping" the color scale for TV output(16-235/240) respectively. I haven't tested it that much yet, sort of waiting on the subtract filter to see the difference.

[drebel]

SansGrip,

million thx for the fast reflexes...

Ok.Back to business!(eventhough the aspirin didnt help much..)

For "torture" movie i selected the Spanish production "Todo Es Mentira" with Penelope Cruz.Garbage quality, dark,blocky and slightly blurry (but no other "noise-like" artifacts.

I've tried many times to encode those vobs with xvid,usind Convolution3d and many many combination of filters.The result was not good enouph : one has the feeling that he 's waching the movie through a thick glass(hyperfiltered to avoid those blocks,but with no luck).PP didnt help either and the lack of details was obvious.

It gives me great pleasure to test it with Blockbuster in YV12.I'll try to focus on "noise" method this time.About luma_offset=-1,the effect i was talking you about was softer but,from my point of view, it's better to pinpoint a problem than to cover it if we're looking for solutions(sorry,i'm not a coder... )

For now ,a first asharp tryout is in the "oven" waiting to face the jury.So the only thing i can do for now is preparing the .avs and some partial-testing.:eek:


best regards to everyone prelonging our insomnia,
george

[MaTTeR]

Well my full 2-pass encode finsihed awhile ago and watched some of the scenes that had been giving me problems. All I can say right now is that I'm very encouraged by what I seen:)

Overall the encode was nice and clean with very few left over blocks moving around on walls. I noticed a nice side effect as well, BlockBuster seems to help get rid of the XviD B-Frames noise smearing problem. I've encoded this movie 8 times in 3 days and this new BlockBuster is by far the most pleasing to my eyes. I think with some more agressive settings I might be able to knock this movie out after all. I just wanted to drop this quick note before I went to bed. I'm very anxious to test more settings and hear what others were testing with! Great work SansGrip!

Setting this up in the queue now-
crop(4,4,712,472)
TemporalCleaner(2,2)
Blockbuster(method="sharpen",block_size=3,luma_offset=-1,luma_threshold=28,detail_min=1, detail_max=25)
Unfilter(3,3)
BicubicResize(528,392,0,0.5)
undot()
Limiter()

Edit- Oh and I'm also very curious to see where we can get optimal quality by placing BlockBuster in the chain. I'm starting to think maybe it might work better before a smoother type filter now, I'll try it tomorrow.

[kilg0r3]

i just had a look on the american pie screen shots with the different noise settings. as far as i can say, it seems to me that the blocks are still there although they will be less visible with noise when watching the movie. Still, i don't see the advantage to add noise during the encode sacrifcing bitrate and consequentially causing higher quantizers to be used when it is possible to achieve the same effect by using ffdshow's noise feature, which admittedly needs some improvement.

the only case that might justify using a noise generator is the black blocking issue. yet, for this, it would be very nice to have a filter that adds the noise only in areas with a low luma value; 20 and less.

[MaTTeR]

Why add more noise? Well for me I absolutely refuse to use Post Processing to cover artifacts up for a crap rip. I wan't the best possible encode from the start even if it does require me to use more space. Why not have the best if you can afford it?

@all
I really don't see any problems using the luma offset parameter. In fact, when darkening it's very difficult to see any change at all with -1 or -2. The only way I was able to notice any difference in the Vdub preview window was to use a crazy setting such as -40. So it seems safe to use but I'm not sure how much it's going to help us.

My 2nd encode finishe dup over night and I'm still fighting the same problem for now...ringing artifacts. This seems to be a side effect of using YV12 but it's also amplified when using BlockBuster IMO. Has anyone else seen this yet?

My final thought is that the second script I posted above is working much better on this movie. More agressive settings were needed but that might be depending on the rest of our filter chains. In theory, UnDot or UnFilter might just be UnDoing our BlockBuster settings:D

[SansGrip]

My 2nd encode finishe dup over night and I'm still fighting the same problem for now...ringing artifacts. This seems to be a side effect of using YV12 but it's also amplified when using BlockBuster IMO.

When you say ringing artifacts, what exactly do you mean? Can you post a framegrab?

My final thought is that the second script I posted above is working much better on this movie.

I have my doubts about using smoothers etc. after Blockbuster, because sharpening then smoothing is never going to be as good as simply sharpening less in the first place. And wrt to adding noise then smoothing, the second step is never going to make the noise more random, always less. Less random means perhaps noticible patterns appearing in what used to be noise. The brain is very good at ignoring noise and very good at spotting patterns :).

[SansGrip]

i just had a look on the american pie screen shots with the different noise settings. as far as i can say, it seems to me that the blocks are still there

DCT blocks will always "be there", because that's what an MPEG frame is made up of. However, the blocks in the grabs with noise added contain more details, are internally graduated consistently with the entire wall, and have much less noticible boundaries between each other.

Still, i don't see the advantage to add noise during the encode sacrifcing bitrate and consequentially causing higher quantizers to be used

Generally sacrifices are made for a reason, and this is one of those YMMV things. If you think encodes look fine with noticible DCT blocks all over smooth surfaces then that's great. I personally don't think they look fine, I think they look awful, and they jump around and flash on and off in what I find to be a most distracting manner. Thus I am willing to raise the bitrate slightly to improve quality by dithering.

Yes, more bits will be used but since the problem is caused by over-compression in the first place, that's to be expected.

when it is possible to achieve the same effect by using ffdshow's noise feature, which admittedly needs some improvement.

First, ffdshow doesn't work on my standalone DVD player. Second, not everyone has it. Third, are you really arguing that destroying details then faking them later is better than keeping the existing details in the first place? That doesn't make sense to me.

This argument could easily be extended to resolution. Why use all those bits to encode at 640x480 when we could encode at 320x240 and just use our player's double-size feature? Of course, because it doesn't look as good. As always, the trade-off is quality for bits.

Dithering is used in many places to improve quality. Almost all music is recorded, edited and processed with at least 20 bits these days, but CDs are only 16-bit. When this 20-bit+ music is transferred to CD it is dithered during conversion. This retains more details in the material --noticible ones -- than simply truncating to 16 bits, and is standard industry practice. Admittedly it's a much more targeted application of noise (at least in the more sophisticated/expensive systems), but then a lot more research has been done into audio dithering than video dithering -- at least, research I have access to :).

[MaTTeR]

Originally posted by SansGrip
[i]When you say ringing artifacts, what exactly do you mean? Can you post a framegrab?

I have my doubts about using smoothers etc. after Blockbuster Yeh, I'll find a good example of ringing and post it tomorrow after I get back from work. Ringing artifacts are basically what appears to be large multi-colored rings most commonly seen on darker stable backgrounds. It's hard for me to describe but a picture is worth a thousand words:)

Your right, I've ran multiple tests tonight and indeed I get better visual results when using smooothers before BlockBuster. Also, I'm convinced drebel was correct in using the smallest block size. In fact if I could go lower than 3 I would. For whatever reason larger block size are showing diminished returns. Well here's my 6th revision of my script for this 4:3 flick I've been encoding-
mpeg2source("D:\DIvX RIPs\Apostate\apost.d2v",iDCT=2,cpu2="oxoxoo",moderate_h=50,moderate_v=70)
crop(4,4,712,472).undot().Blockbuster(method="sharpen",block_size=3,luma_offset=-2,luma_threshold=30,detail_min=1,detail_max=35).BicubicResize(512,380,0,0.4).Limiter()

Edit- Grhh...when will Mozilla ever fix these friggin line breaks?!?! Doom9 will get a kick out of this if he spots it:D

[drebel]

Hope i waited long enough for all other tests to be completed before posting some new hints....
About blockbuster in YV12 now:

- Algo errors seem to be fixed!No more flashing pixels,regardless of the params selection(thx SansGrip).Looks like you didnt just port the filter to YV12...:)

- Method "sharpen" is still giving the best result and ,of course ,sharper image(no nedd for extra sharpenning most of the times)."Noise" is reducing artifacts but also gives a "motion" on walls etc.This effect could be used to give a retro feeling to certain B&W old movies while keeping soome of the noise(director's opinion)

- Block size should,i think, be kept as low as possible when encoding movies.This could prevent several "mistakes" at the selection of the perfect parameters to be shown clearly at the final result(the effect of tiny dots and the chesstable-like grid are far less obvious).This doesnt neccessary mean that bigger blocksize is unuseful.Certain anime films(not tested)could benefit from size 6 or 8(reminds me of another old thread about "solid coloured areas"...

- As detail now is(?) without errors,a detail_min=1,detail_max=30 is enough.When human skin contains blocks ,detail_max could be raised to 40 or even 50

- Strength more than 40 is aggressive and not beautiful (for my eyes)


Edit- Oh and I'm also very curious to see where we can get optimal quality by placing BlockBuster in the chain. I'm starting to think maybe it might work better before a smoother type filter now, I'll try it tomorrow.

- I totally agree with MaTTeR on this one.I just wanted a second opinion and your test just gave me what i needed.Thanks :)


-Your opinion is always a great help and a step forwards.The filter is now mature enough for everyone to use it.


best regards to all,
george

[SansGrip]

- Algo errors seem to be fixed!No more flashing pixels,regardless of the params selection(thx SansGrip).Looks like you didnt just port the filter to YV12...:)

I think that's all I did ;). Would you be able to do my a favour and try a ConvertToYUY2() before Blockbuster in your script? If the flashing pixels are still gone then I guess I did fix a bug too...

"Noise" is reducing artifacts but also gives a "motion" on walls etc.

I find this happens when the variance isn't set correctly, either too low or too high.

Block size should,i think, be kept as low as possible when encoding movies.

Interesting. I'll have to remember to include this in the docs.

Strength more than 40 is aggressive and not beautiful (for my eyes)

Yes, it's a pretty powerful sharpening matrix.

The filter is now mature enough for everyone to use it.

Well, normally I would take this kind of remark to mean next release I should go ahead and bump the version to 1.0, but I just got a book on assembly language so I don't want to come out of the beta stage just yet...... :D

[SansGrip]

In fact if I could go lower than 3 I would.

The only reason I set that as a minimum is because the sharpen/blur matrices are 3x3. Since you're using a block size of 3, only the very centre pixel is being affected. I'm surprised it's working like that, tbh ;).

Hmmm, this gives me an idea for an algorithm that would process every pixel and not require the image to be split up into blocks at all...

I'll have to think about that one :).

[iago]

@SansGrip and all

I must admit that I have also got the best results with the filter using the "sharpen" method so far. I agree that a strength value of more than 40 (imho default 25 is also fine) would really hurt compressibility a lot and lead to unpleasant results.

As for the luma_offset and luma_threshold parameters, I haven't experienced any problems with "luma_offset=-2", but if you set the luma_threshold too high (>25-30) it may lead to some artifacts at shady parts, some sort of very visible annoying border lines between the luma_offset=-2 parts and the neighbouring parts of the picture to these areas. Personally I prefer to use a luma_threshold of 20 to avoid this side-effect.

Btw, I'm still sceptical about using BlockBuster "before" smoothers, since this "may" totally undo what BlockBuster will achieve (?).

Regards and many thanks again for this powerful filter! Imho, with its current situation and its great flexibility it's more than ready for real encodes! ;)

iago

[drebel]

Would you be able to do my a favour and try a ConvertToYUY2() before Blockbuster in your script? If the flashing pixels are still gone then I guess I did fix a bug too...

Done!No flashing pixels anywhere......
Good luck with assembly ;)
If your wish is to incorporate any new ideas to the already great filter,no complaints from here :D

regards,
george

[SansGrip]

Done!No flashing pixels anywhere......

Excellent. I must admit I've never had any reports of flashing pixels from anyone else -- perhaps it was a problem with the small block sizes.

Good luck with assembly ;)

It's coming along. I'm starting with LegalClip, my simplest filter, and I think I've come up with something significantly more efficient than the compiler generated from the C++ code (but no MMX/SSE yet). Blockbuster shouldn't be too difficult to rewrite in assembler -- or at least should be easier than the smoothers.

If your wish is to incorporate any new ideas to the already great filter,no complaints from here :D

I have an idea involving a moving window instead of discrete blocks. I need to let it percolate through my brain for a few days before I look into implementing it though :).

[SansGrip]

Here's a new release which fixes a bug and adds a parameter. It'll probably be the last 0.x version -- I think I'll bump it up to 1.0 for the next release since lots of people are using it and there are very few reports of any problems.

Changes:


0.6 - Added seed parameter. Fixed a bug that might have been responsible for the access violations when using with high resolutions and the default cache size.
The new seed parameter allows one to specify the seed value for the pseudo-random number generator in the noise method. Previous versions always produced a slightly different file size over multiple encodes using the same settings (obviously because of its random nature). By specifying a seed value one can force Blockbuster to produce the same "random" noise each time it is run, which helps in certain applications that require a more predictable outcome.

As usual the source and docs are on my site.

Please let me know if you have any problems.

Edit: Removed links to old version.

[onesoul]

Originally posted by MaTTeR
mpeg2source("D:\DIvX RIPs\Apostate\apost.d2v",iDCT=2,cpu2="oxoxoo",moderate_h=50,moderate_v=70)

I shouldn't ask here but I am too curious, what does those parameters mean? btw what does limiter() do?

[SansGrip]

Originally posted by onesoul
btw what does limiter() do? Limiter is the Avisynth 2.5 built-in version of LegalClip -- it clamps the pixel value ranges to CCIR-601. If you do a search for "CCIR" you should find more information than you probably want to read ;).

[MaTTeR]

Originally posted by onesoul
I shouldn't ask here but I am too curious, what does those parameters mean? btw what does limiter() do? SansGrip answered about Limiter() and you can find all the other parameters documented on MarcFD's MPEG2Dec3 documents.

@SansGrip
I'm pulling my hair out here trying to figure out what's causing me access violations with the YUY2 (v0.6a) filter. My script looks like- mpeg2source("D:\Seals\seal.d2v",idct=2,lumoff=-1)
Telecide(guide=1)
Decimate(mode=1)
crop(4,4,712,472)
Blockbuster(method="noise",detail_min=1,detail_max=35,cache=512,block_size=3,luma_offset=-2,luma_threshold=25)
BicubicResize(544,404,0,0.5)
LegalClip()
The violations dont happen immediately when I open my script, only when I use Vdub to start seeking through the video or start an actual encode (Happens about 6th or 7th frame). Also, if I move the "BB" line to after resizing then all works very well. Sounds similar to the problem I was having in this thread. (http://forum.doom9.org/showthread.php?s=&threadid=40056&pagenumber=3)

I'm using XviD and the latest AVS 2.07 11-25-2002 build. Any ideas? Let me know if I can provide any other information. I might be slow to respond since I'm leaving the city for the holidays.

Happy Holidays Everyone!

[SansGrip]

Originally posted by MaTTeR
The violations dont happen immediately when I open my script, only when I use Vdub to start seeking through the video or start an actual encode (Happens about 6th or 7th frame). Also, if I move the "BB" line to after resizing then all works very well. Sounds similar to the problem I was having in this thread. (http://forum.doom9.org/showthread.php?s=&threadid=40056&pagenumber=3) If it is the same bug then the fact that this always seems to be fixed by running the filter after resizing suggests that it's the resize filter trying to request out-of-range frames.

While I'm still not convinced that pretending it never happened is the right way to "fix" the problem, I can add a range check and see if it helps.

I've never tried running Blockbuster before the resize myself, but shouldn't it really go after anyway? I would think that by having it before you'll at least be reducing its effectiveness and so will need a higher variance to compensate...

[MaTTeR]

Originally posted by SansGrip
I've never tried running Blockbuster before the resize myself, but shouldn't it really go after anyway? Well I'm not exactly sure to be honest. I've been testing it extensively on this crap DVD source for the 48hrs and I can't make my mind up if I like it before or after. FWIW, using BB's "add noise" feature along with XviD's Qpel option seems to help quite a bit.

Maybe it's not worth looking into if BB performs better after resize? Guess I'll know shortly since my encode just just finished, need to view it on TV now.

BB is adding random color noise correct? I was wondering how difficult it would be to add random neutral colored noise(ie. grey or black). The only reason I mention this is because the noise is very noticeable when processing full frames (detail_max=100%). I don't know, was just thinking aloud if neutral colored noise would be less noticeable to the human eye.

[SansGrip]

Originally posted by MaTTeR
Maybe it's not worth looking into if BB performs better after resize? Oh, it's definitely worth it. I'd be very interested to hear your conclusion since I've only ever used it after the resize :).

BB is adding random color noise correct? Nope... As of 0.4 (I think) it only adds noise to luma.

The only reason I mention this is because the noise is very noticeable when processing full frames (detail_max=100%). Can't you just lower the variance until it reaches a satisfactory level?

[iago]

Maybe it's not the place, nor much relevant to the topic, but DivX5 decoder's Film Effect at level 3 (out of 4) is imho the most pleasing-to-the-eye noise pattern to enhance the look of an encode and cover the encoding artifacts/blocks almost perfectly. I had to admit that somewhere, and it just happened to be here ;).

Btw, I use DivX5 only to decode Nandub SBC encodes, and never for encoding purposes! ;)

regards,
iago

[bilu]

Should I use lumoff=-2/Unfilter(5,5) with BlockBuster, or as a replacement? I read the thread but haven't seen a conclusion.
Guess I'll test it tonight :)

Please look at this thread also http://forum.doom9.org/showthread.php?s=&postid=230458#post230458 , I'm curious if the MPEG quantizing could afect the luma/chroma range for TV-output

[bilu]

@iago

After this reply (http://forum.doom9.org/showthread.php?s=&postid=230512#post230512) I really got confused :o

[Didée]

@ bilu

Once upon a time, there was a thread ... :D

... about "black-blocking" on TV-sets, and what to do about.

In this thread, as well as in some others, it was mentioned that Tom's "unfilter" adds a small amount of noise to the source. This is the main reason why it helps against the "black-blocking" problem.
And that's also why it helps with negative values as well as with positive: the noise gets added in both cases.

[iago]

Once upon a time, there was a thread ... :D (Didée)

Yeah, and what a thread it was! :D

Btw, I'm not sure if UnFilter does its nasty job by adding or keeping noise (with "+,+" values), or by darkening or something (with "-,-" values), or by some other mysterious ways which might be even much more beyond our understanding (Tom, any new theories about this? :D), but it certainly does something to help defeat the black-blocking issue! ;)

iago

[SansGrip]

I just uploaded to my site (see sig) version 0.7, which adds a new method: dithering. Basically this is very similar to the noise method, except it will add the same noise to each frame, creating a kind of "unchanging noise" effect.

I added this method because I wanted to see if such dithering would result in less artificial "movement" in otherwise static areas than with the noise method. It should be considered experimental.

Let me know :).

[iago]

@SansGrip

Welcome back, man! And thanks for the new version, gonna try asap! ;)

regards,
iago

[iago]

@SansGrip,

I have played a bit with the new "dither" method and compared the results to the old "noise" method. Yes, the results of "dither" are really very similar to the "noise" method, but that's only when you do a frame-by-frame comparison in VirtualDub. But during playback, the results of the "noise" method is definitely superior to and provides a much more natural/pleasing viewing experience than the "dither" method imho ;).

best regards,
and thanks again for this great filter,

iago

[Kramerica]

When used with xvid, dither produces a result which looks very similar to a divx 3.11 rip. That is to say, dark areas keep their pattern, even when the area housing this pattern is moving. I don't really think this is necessarily a bad and can look better than either sharpen or noise methods in some instances.

[kwag]

Originally posted by iago
@SansGrip,

But during playback, the results of the "noise" method is definitely superior to and provides a much more natural/pleasing viewing experience than the "dither" method imho ;).


Unless you're looking at a still background, where you'll notice that if you use "Noise", there will be some movement. Like on walls, etc. But if you use "dither", the backgrounds will look still, and that is a big difference. :cool:

-kwag

[MaTTeR]

Almost 2 weeks later and I'm still trying to get a good encode of US Navy Seals, this flick is driving me nuts.

"Dither" doesn't seem to help under water scenes at all but the "noise" method does to some degree. I can see what kwag means about stable backgrounds using "dither" though, definitely less movement.

[SansGrip]

Sounds like it's a good job I marked it "experimental" :D. When I coded it I really had no idea how it would look or work, I just figured it might fix the "artificial movement" problem inherent with noise.

Now I think about it, it makes sense that noise looks more natural, since anyone with cable is already "tuned" to ignore noise anyway :).

[iago]

Btw, "dither" seems to be much more compressibility-friendly compared to "noise" ! ;)

[SansGrip]

Originally posted by iago
Btw, "dither" seems to be much more compressibility-friendly compared to "noise" ! ;) Yep, I noticed that too :).

[MaTTeR]

Anyone have any comments/advice on block_size? I'm typically using a value around 3-5 and 6-8 on darker movies like the evil one I mention above.

@SansGrip,
Indeed BlockBuster works more effeciently when put at the end of the script as you suggested. You stated that as of v0.4 that your only adding noise to the luma plane. Does some type of hidden parameter exist to still add noise to the chroma plane? I suppose this might kill compressibility in general...Did you find the effect to not be helpful? Thx again for your continued effort.

Edit- fixed vBB typo.

[SansGrip]

Originally posted by MaTTeR
Anyone have any comments/advice on block_size? I'm typically using a value around 3-5 and 6-8 on darker movies like the evil one I mention above. I've only ever used the default (except when checking for bugs of course ;)), but would be interested to hear others' input on this.

Does some type of hidden parameter exist to still add noise to the chroma plane? Nope. I did quite thorough testing on this before dropping chroma noise, but it seemed to be almost invisible to the encoder. That said, it wouldn't be difficult to add it back in if there's enough demand :).

BTW, are you the same MaTTeR mentioned in the HeadAC3he docs as a beta tester?

[MaTTeR]

Originally posted by SansGrip
That said, it wouldn't be difficult to add it back in if there's enough demand :).Well that's what I figured, so it's prolly not worth the effort. I was just curious more than anything else :-)

BTW, are you the same MaTTeR mentioned in the HeadAC3he docs as a beta tester? Yep, that would be me. Actually I'm not sure if I ever read those docs myself. LOL

[Didée]

To be honest, I did not play very much with block_size. But since we're fighting mpeg blocks, I feel the need to process only 8-pixel-blocks, or maybe 16.
With other values, I'd fear to alter the information within a block not equally, endangering some visual degration of the block's content.

I'm more curious, what strenghts are you actually using?

-----

For quite some time, I am fiddling on a completely different approach.
Unfortunately, I don't find enough time to test this thoroughly.

Basic concept:
(similar as the built-in, but completely different approach)

Apply noise to areas with little information, leave areas with plenty information alone, and a smooth transition between these two.


1. Find the edges in a frame

I do this by computing the difference between the (slightly blurred) original frame and a stronger blur of it. This might be called "edge detection by unsharp masking). Most other methods of other filters deliver "sharp" edges. Here, we need a B/W image of the edges that correspond to the "strength" of the edges in the original frame.
Alas, since current filters don't really suite (and I'm not a coder), I have to fiddle a lot to make a proper mask here.
(Waiting for MarcFD to implement "subtract" for YV12. He made a little promise of a new parameter for that ... ;) )

2. Perform "blockbuster" with "noise" and "max_detail=100"

3. Layer the fully blockbustered frame onto the areas with no edges, by using the result of step 1 as a mask.


This way, I hope to avoid that the added noise disturbs the image.
My biggest "problem" with blockbuster and its approach is, that the blocks that are processed are flickering around: try "show" mode, and let it play. You see what I mean. Also, this popping-around of the processed blocks perhaps could disturb the codec's motion estimation. (?)
And, in case one is using mpeg-quants with XviD, on I- and P-frames that use quant 2, the noise may be preserved by some amount. Then, the block-wise adding of noise might get visible.

Doing the above with current AviSynth weapons is slow. Perhaps if one of our awesome filter developpers is bored and doesn't know what else to do ...


Comments to this would be very welcome.


Didée

[MaTTeR]

Originally posted by Did�e
My biggest "problem" with blockbuster and its approach is, that the blocks that are processed are flickering around: try "show" mode, and let it play. You see what I mean. Also, this popping-around of the processed blocks perhaps could disturb the codec's motion estimation. (?) Well I have to say I've this problem lately too. Using show I can see that the mask will change from one extreme to another between 2 frames that barely differ(very low motion). I was thinking the same thing about it affecting the codec's motion estimation also but from what I can see in terms of compressibility it doesn't seem to harm much. I have to admit I'm using Xvid's Qpel function though, that should help:)

Doesn't strength just affect the sharpen parameter or did I read the docs wrong?

[Didée]

No, you have read right. Stupid me, of course I meant "variance".
Excuse me, 36 hours without sleep ...

[bilu]

Could the use of a smoother such as fluxsmooth after blockbuster help?

[SansGrip]

Originally posted by MaTTeR
Yep, that would be me. Well, in that case, perhaps you know more details about the Surround 2 downmix mode other than, as the docs say, it uses "a matrix I found"? ;)

[SansGrip]

Originally posted by Didée
But since we're fighting mpeg blocks, I feel the need to process only 8-pixel-blocks, or maybe 16. I feel the same, though I tend towards the former. DCT blocks are always 8 pixels. Macroblocks are 16, and are the symptom of a different problem.

I'm more curious, what strenghts are you actually using? I usually use between 0.5 and 1.0, though I sometimes go higher if the source is very blocky. Interestingly, I just watched the three-disc AC3-Guru version of Minority Report and it looks like it had Blockbuster(method="noise", detail_min=1, detail_max=100, variance=3) applied to it. Weird effect, and not surprising it had to go on three discs ;).

Apply noise to areas with little information, leave areas with plenty information alone, and a smooth transition between these two. I like this idea. Sort of like a combination of MSmooth's edge constraints and Blockbuster's noise. It would require reworking the code, though, since it would no longer be based on blocks.

Perhaps it could be activated via "block_size=0", though this would be fairly opaque. Alternatively one could use, say, mode="edges" for this approach or mode="blocks" for the old way...

I'd appreciate some feedback on the best way to implement this wrt parameters. Oh, and whether it's even a good idea ;).

My biggest "problem" with blockbuster and its approach is, that the blocks that are processed are flickering around This is indeed a problem, and is one of the reasons I added the "dither" method. Dither helps somewhat but doesn't address your concern specifically (i.e. that the blocks considered "not detailed enough" are constantly changing).

Doing the above with current AviSynth weapons is slow. Perhaps if one of our awesome filter developpers is bored and doesn't know what else to do ... Well I'm not bored and certainly have lots of things to do, but I'll give this some thought and see what comes out the other side ;).

Comments to this would be very welcome. I second that.

[esby]

Someone (maybe Sangrip, if he want / can) can compile again the last version in order to use it with avs 2.51... ? ^^
(Blockbuster-2.5.dll saying that it is not a filter for avs 2.5 etc.)

Thanks

esby

[Boulder]

Someone already recompiled it a while ago, search the forums and you'll find it attached somewhere. You might also find a link at www.avisynth.org .

[esby]

mmm
I'll search the forums...

For information... the link on www.avisynth.org
redirects here and on sangrip page, both with a non compliant version to the last build as far i tested.

esby