more dancing blocks? how would one encode something like this?

[OCedHrt]

Hi, I've been reading quite a lot of the threads about dancing blocks, blocking in dark areas, etc. Most of the technical stuff just goes way beyond my head :P

Suggestions I have come across, of the top of my head, are:
1) Use lumaoff and unfilter.
2) Add noise/grain.
3) ColorYUY2 PC->TV scale.
4) Etc. :P It's late!

I have a 20s sample here (http://s90713212.onlinehome.us/images/test.avi).

This clip was encoded using XviD 1.01 with options:
Motion search precision 6, VHQ 4, use chroma motion, turbo, trellis quantization, h.263 matrix, qp, gmc, b-vop 2-1.5-1, packed bitstream, and closed gov.

The actual encode is 698mb for a 1 hr 8 min video. So bitrate is around 1300kbps.

I have also tried a bunch of combinations with atleast 15 different encodings and they all come out pretty much the same.

Problem is, none of these methods really work. ColorYUY removes most of it, using the others come out about the same. The original dvd source already has a lot of grain, and since it is a concert and thus 99% dark, I can't really zone certain areas to allocate more bitrate to. I've also tried q=2, q=1, and the blocks are still there so bitrate doesn't help either. It's not just the gradiant area from light->dark either. Even in the darkest solidest areas, the blocks are visible.

But here's the important part. On my LCD I see these blocks. On my roommate's CRT I don't see them. Do you guys see them? Or are they really that subtle and my LCD just sucks?

Is there a specific way to encode video of this type? Where it is almost always dark?

Update: Using ffdshow for decoding and enabling post processing with lumiance and full luma range seems to remove most of the blocking (http://s90713212.onlinehome.us/images/ffdshow.jpg). Not sure how it works but dark areas are darker and bright areas are brighter.

[niamh]

But here's the important part. On my LCD I see these blocks. On my roommate's CRT I don't see them. Do you guys see them? Or are they really that subtle and my LCD just sucks?
I see them , I have a LCD. :D

When I got my new LCD screen I nearly threw away all my rips. LCD will show ALL the flaws in an encode, and even on DVD's, you have to learn to live with it :)
You could
- add noise
- use RV10 if you can't live with mpeg4 blocks
- get your CRT screen back :p
- and use post processing as you discovered

Consider too that at more than 10 inches from the screen , you won't be able to see those.

[Soulhunter]

I dont see them with my CRT, even @ max brightness not !!!

Maybe lowering the gamma @ your LCD helps... ;)


Bye

[D-wizzz]

I have lcd and i can see them very minimal.
Only when i enlarged it in mpc i could see it
as niamh said from a slight distance you hardly notice it;)

see ya!

dennis

[OCedHrt]

Originally posted by Soulhunter
I dont see them with my CRT, even @ max brightness not !!!
Maybe lowering the gamma @ your LCD helps... ;)


Hmm, I've tried that. My LCD is so crappy that from min brightness -> max brightness it's only like 10% brighter lol. They are still visible with everything on lowest though.

@D-wizzz
Yeah, they're not very noticable until I fullscreen it :P

Like niamh suggested, I will probably just have to learn to live with it :P

Thanks for the response.

[BoNz1]

Originally posted by OCedHrt


Suggestions I have come across, of the top of my head, are:
1) Use lumaoff and unfilter.
2) Add noise/grain.
3) ColorYUY2 PC->TV scale.
4) Etc. :P It's late!



None of these suggestions work obviously. Filtering is useless in this situation IMO, it is easy to see that it doesn't work. Usually, the problem is when there is big flat areas in the background and macroblocks are not skipped. This is especially noticable in dark scenes. Filtering is stupid because usually you end up removing more of the detail and make it even flatter. Or you add noise which makes the background swim and block. The cvs HEAD branch contains a better skip detection. If I were you I would try to get one of gamr's builds http://xvid.gamrdev.com./ from cvs head. It will cope better with the problem than 1.01.

[OCedHrt]

I will give the newer builds a try, I have tried up to late June's build, I think 6 26? None of the methods I listed are filtering out detail though. And since every scene from beginning to end is dark, makes it all a big mess.

[MasterYoshidino]

you are getting those blocks from overcompression. b-frames = guaranteed overcompression. are you doing any spatial filtering (either with mpeg2 decoder postprocessing or with spatial blurs)? these will increase the artifacts. try q2 with 'absolutely zero' spatial preprocessing. don't expect those blocks to disappear unless you aim for high bitrates.

[OCedHrt]

I have tried q=2 with no filtering at all. They are still there (not as much of course). q=2 with no filtering comes out to about 1.4GB. Using a temporal softner actually shrinks it down to 800mb at q=2. That's how much grain there is. I have just tried the newest builds on gamrdev and they are still there as well :) Currently trying the last 711 build with HVS best. Will be done in an hour.

EDIT: I will try to upload a q=2 clip afterwards, if it doesn't turn out too big.

[OCedHrt]

The new builds with HVS seems to reduce most of the blocking. 15s clip here (http://s90713212.onlinehome.us/images/gackt2711hvs.avi)

The blocking that remains seem to be from bitrate underrun, I'll try to make a q=2 for this range and see how it turns out.

[Soulhunter]

Idea:


1st. Make a temporal denoiser only work @ low luma levels !!!

Such post processing should at least stop this blocks be floating around... :rolleyes:


2nd. Make a deblocker only work @ low luma levels as well !!!

This should reduce the blocking without degrading the other details...


Someone willing to code such a filter for AviSynth/ffdshow ???


Bye

[OCedHrt]

I think there were suggestions to use masks for this? Not quite sure since I am 99% clueless with avisynth coding :P

Edit: And TV->PC level conversion does get the job done, but totally ruins the compressibility of the source ;P

[darwin2002]

I'm having dancing block issues as well. When outputting to TV it can get absolutly horrendous, CRT it's less noticable.
I don't believe it has to do with encoding, but with decoding.
I have close to 100 movies encoded with xvid, with previous builds, all of them looked great on TV or CRT. Since upgrading to the latest build all the sudden nearly everyone of them shows dancing blocks, some to the point that it's nearly unwatchable. Tried going to the latest FFDSHOW and forcing zoomplayer to use that as the decoder, same problem. Force zoom player back to use XVID to decode, same problem. In dark styled movies its horrendous, ie "Confidence", which is a movie I encoded close to a year ago and have watched it a few times decoding with previous builds and no blocks, now it's nearly unwatchable.

I have tried the one recomendation I've seen, using post processing in FFDSHOW, this works to a certain degree but darker movies are still pretty blocky. Unfortunatly you can see the image quality drop soon as you select post processing to be active, and really this shouldnt have to be done anyway.

Anyone else have a solution?
Perhaps it's something I messed up, but it did begin happenning directly after installing the latest build. I did think it odd that XVID and FFDSHOW are both producing this image issue.
I think for now I'll try digging up a previous XVID or FFDSHOW build and seeing if that helps.

[Leak]

Originally posted by darwin2002
I have tried the one recomendation I've seen, using post processing in FFDSHOW, this works to a certain degree but darker movies are still pretty blocky. Unfortunatly you can see the image quality drop soon as you select post processing to be active, and really this shouldnt have to be done anyway.

Have you tried SPP deblocking in ffdshow's postprocessing page? Check it's box and set the slider to position 1 or 2, so it won't eat all your CPU - that should really take care of blocks caused by DCT.

Then again, artifacts *will* show up the most in very dark areas, as the contrast there is so low that even the slightest artifact will have almost the same contrast and of course stand out like a sore thumb...

np: Kuroishi Hitomi - Over The Sky (Angel Feather Version) (Last Exile OST 2)

[Sharktooth]

Have you tried adding a single zone for all the encode with Chroma Optimizer enabled?

[Didée]

Originally posted by OCedHrt
I think there were suggestions to use masks for this? Not quite sure since I am 99% clueless with avisynth coding :P

A little sledgehammer. Adjust transition_level to your likings.
LoadPlugin("X:\y\MaskTools_v1.4.16_or_later.dll")

[...]
[your script]
[...]

normal = last

transition_level = 31

dark = BlindPP(cpu2="xxxxoo", quant=20, moderate_h=10, moderate_v=10)
dark = dark.temporalsoften(2,7,11,15,2)
# dark = dark.greyscale() # perhaps even this

darkmask = normal.levels(16,1.0,transition_level,255,0,false).FitY2UV()

MaskedMerge(normal,dark,darkmask,Y=3,U=3,V=3,useMMX=true)
- Didée

[darwin2002]

I will give the SPP deblocking a shot. I did try going to an older build and did not help that much.
I think I have discovered the problem and yet again it would seem it's another bug thats NOT the fault of XVID, sorry for my implications. It would appear that adjusting the contrast or brightness via the VMR9 overlay amplifies the blocks to a huge degree. If I leave the overlay settings to default and just boost the saturation then I see almost no dancing blocks. Also, I have the same effect as some are posting, the dancing blocks are very prominent on the TV-out but hardly can be seen at all, and in most cases can't be seen at all on the CRT. I knew it had to have been something I recently changed but the only thing that stuck out was upgrading to the newest XVID and FFDSHOW, was thinking it could be an intermediary program seeing as both FFDSHOW and XVID were producing the same thing.
I was hoping the overlay would work because movies have to be a bit darker for them to look proper via the TV-out but when they aren't playing the screen is a little too dark for Internet Explorer, games, and such. Looks like I'll just make display setting profiles instead.
Anyway, not sure if this info will help other dancing blockers, let me know if it does :)

BTW Just thought I'd add that I have made movies look proper by changing windows display setting to reduce brightness and such and no dancing blocks result from that. Just from reducing brightness and contrast via VMR9 overlay.

[Soulhunter]

Originally posted by Didée
A little sledgehammer. Adjust transition_level to your likings.
Thanks for this script !!!

But, 10fps for a 320x240 clip... :scared:


Maybe flatten the luma is already enough ???

Something like dropping the luma between 0-32 all to 16 !!!

Maybe a simple 5x blur (or even a 10x) would be enough...

Think this should be much faster !!!


Bye

[Didée]

Originally posted by Soulhunter
Something like dropping the luma between 0-32 all to 16 !!!
last.yv12LUT(Yexpr="x 32 < 16 x ?")

;)

- Didée


EDITOriginally posted by Soulhunter
But, 10fps for a 320x240 clip... :cry:

WHAT? No, Soulhunter. Must be an error on your side. Right now I'm feeding a 544*576 d2v source into it. Runs above realtime on a Cel-2800!

"Don't make me slower than I am!" ;)

[Soulhunter]

Maybe one of ffdshows filters was enabled while playback... :confused:

But what filter could make it that slow ???


No matter, the "yv12LUT" thing seems to work... :)

Would be nice if someone with a LCD could confirm this !!!


Only thing that bothers now...

There is still a visible boundary between the lum16-cap and the rest !!!


Next idea:

Making a multiple "flatten low luma" processing !!!

Something like...

Luma 0-8 = 4, 8-16 = 12, 16-24 = 20, 24-32 = 28 (or even finer steps)

Finally doing a heavy blur to interpolate the different regions...


Would this work (and is it fast enough) ???


Bye

[Didée]

A lot of avisynth scriptlets for an XviD thread. Moderators, have an open eye ... ;)

Originally posted by Soulhunter
[B]There is still a visible boundary between the lum16-cap and the rest !!!
Yes, of course. What did you expect? YOU wanted to clamp [16,32] to [16,16] - and that's exactly what you got ;) - This obviously destroys all gradients using the [17,32] range.


Something like ...
Luma 0-8 = 4, 8-16 = 12, 16-24 = 20, 24-32 = 28 (or even finer steps)Finally doing a heavy blur to interpolate the different regions...

Don't see any benefit on your luma thingie. You're creating banding with bigger step size than the blocks you want to fight ...
Smart histogram manipulation is something I could think of, theoretically - but thats complicated, and slow as well.

But the "dark luma blur" you can have:
blockyLL=last
ox=blockyLL.width oy= blockyLL.height
blur8=blockyLL.bicubicresize(round(ox/8/4)*4,round(oy/8/4)*4).bicubicresize(ox,oy,1.0,.0).greyscale
maskedmerge(blockyLL,blur8,blockyLL.ylevels(16,1.0,31,255,0).FastFitY2UV(),Y=3,U=3,V=3,useMMX=true)

This will, however, create "glowing" e.g. where a bright foreground meets a dark background. Not my fault - would need a thresholded box blur filter. We don't have such a one :(

Would this work (and is it fast enough) ???1. Yes
2. Dunno

Above scriptlet renders a 704*416 clip @ 35 fps in Vdub, on a Cel-2600. You can speed it further up by setting "Y=3,U=1,V=1", to disable chroma processing.

After all, are we talking about pre-processing for encoding, or post-processing on playback?


- Didée

[Soulhunter]

Originally posted by Didée
A lot of avisynth scriptlets for an XviD thread. Moderators, have an open eye ... ;)
Hey, at least its all about solving a XviD problem... :devil:

Originally posted by Didée
Yes, of course. What did you expect? YOU wanted to clamp [16,32] to [16,16]...
Sorry, I get my ideas mostly before the expectations... :D

Originally posted by Didée
After all, are we talking about pre-processing for encoding, or post-processing on playback?
IMO post-processing is the only way to solve this problem !!!

What I know, there is no pre-processing method that is able to solve it...

So, I thought post-processing is the way to go !!!

Would also prevent re-encoding all the old stuff... ;)


Bye

[OCedHrt]

Pre-processing works, just comes with a high price :P I haven't had time to give the script a try since I deleted the dvd files off my hard drive *blink But if you have a clip you want to test I can take a look at it on my crappy LCD ;)

[geoffwa]

Why not just blur the crap out of them?

[OCedHrt]

Blur the blocks? The blocks aren't in the source, they're in the result. Even at q=2.

[Didée]

Yes, but ... the whold DCT+IDCT process, and the correlation [spatial frequency]<-->[DCT frequency] is not as obvious as one might think.

Strong blurring *will* help somewhat on the one hand, and OTOH comes along with other risks, at the same time. (But here I'm already on the edge of speaking beyond my knowledge.)

For a somewhat compact overview, get Shalcker's DCTcheck package ... waitaminute ... here (http://web.etel.ru/~shalcker/DCTCheck_v05.zip), and read the included documentation.

In any case, I'd say for the given problem it's a good idea to take out all color information of the darkmost image areas. That way you have at least a better chance that any dark-blocks, IF they occur, are not *colorful*, which usually makes them even more annoying.

- Didée

[lordadmira]

How about this. Apply a levels correction in preprocessing to equalize the histogram. This will exagerate all the gradients and let the codec handle them better. Then in postprocessing reverse the levels correction so that the brightnesses are back to normal. This should get rid of the low luma block problem.

LA

[peterhuh]

lordadmira,
hmm... IMO, this may work, but at an expense of bitrate

[Manao]

lordadmira : how do you postprocess ? from a flat histogram, how do you reconstruct the original one ?

[lordadmira]

U wouldn't squash it to a flat histogram, I probably shouldn't have said equalize. The fact that the source has a narrow histogram means that there's headroom to expand the histogram into. It's a remapping of the histogram. If the original remap is deterministic it can be unmapped. It's like plotting a logarithmic function on logarithmic graph paper to get a straight line so u can do straight line functions on it. This could only be done on a source, or portion thereof, that didn't utilize the full spectrum of the histogram. Whatever was where we're expanding into would be lost. There must be "spare bandwidth".

LA