Log in

View Full Version : [SOLVED] Blotchy Blacks


73ChargerFan
15th February 2012, 06:23
Is there a way to eliminate the blotchy blocks I get in dark / black scenes? I have a MPEG2 vid that I'm encoding with x264 with Ripbot264 and CQ16. Even that doesn't get rid of it.

I can be seen in the encode at 6-8 seconds (samples, 8MB) (http://www.mediafire.com/?y81qm8q2qr17k5w) but not in the original MPEG2 snip.

I've tried for years to encode Batman TAS episodes, but the blacks turn into blocks all over, so I've failed. I'd like to know what I'm doing wrong.

I can view both in the same player (mpc-hc) and orig no blocks, encode is blocky, so it isn't my LCD calibration or video driver settings.

Thanks for any thoughts.

LoadPlugin("C:\Apps(x86)\RipBot264\Tools\dgindex\DGDecode.dll")
video=MPEG2Source("C:\Temp\RipBot264temp\job1\job1.d2v")
video=AssumeFPS(video,"ntsc_film")


avs2yuv.exe job1.avs -o - | x264_x64.exe --crf 16 --stats job1.stats --fps 24000/1001 --force-cfr
--min-keyint 24 --keyint 240 --frames 500 --sar 64:45 --level 4.0 --tune film --aud --nal-hrd
vbr --vbv-bufsize 25000 --vbv-maxrate 25000 --b-pyramid none --stdin y4m --output video.264 -

Blue_MiSfit
15th February 2012, 10:25
What about deblocking / degraining the source, maybe adding dithering afterwards? What about 10 bit?

Blue_MiSfit
15th February 2012, 10:33
I downloaded your sample piece of source with the matching transcode. I really don't see the issue you're describing.

nibus
15th February 2012, 10:58
increasing psy-rd can help with retaining dark gradients. Try something like --psy-rd 1.20:0 and adjust to your liking. Also --no-dct-decimate can help with this.

Didée
15th February 2012, 11:46
Some strong gamma/levels adjustment to see more clearly.

source -
http://thumbnails32.imagebam.com/17491/75fa75174901216.jpg (http://www.imagebam.com/image/75fa75174901216)

encoded -
http://thumbnails45.imagebam.com/17491/6bef62174901224.jpg (http://www.imagebam.com/image/6bef62174901224)


Source is crappy, and the encoding reproduces the crappiness very faithfully. :)


Maybe you have a problem in the playback chain (different filters/renderer settings/whatever for mpeg2 and AVC), go figure. The encoding in itself does not have any particular problem.

Taurus
15th February 2012, 12:06
Yeah,
I can't see the blockiness your describing.
x264: decoded with ffdshow/libavcodec/deblocking/on
mpeg2: decoded with ffdshow/libmpeg2
Bumped up the brightness on my monitor...
Sh.. in, Sh.. out :D
Think, Didée's suggestions are right.
Are the colours identical for both clips on your monitor?

CruNcher
15th February 2012, 14:11
a good way to see any small artifact is avisynths luma view http://avisynth.org/mediawiki/Histogram though you will see things you also not supposed to see and they might look weird ;)

i would suggest using unblock on the source from Didées screenshots it's slow though not so slow (like certain scripts) and it's results are great, still no one optimized that damn thing yet http://avisynth.org.ru/unblock/unblock.html :)

or hardcore do a complete reconstruction with mvtools and overlaped deblocking (very slow)

73ChargerFan
15th February 2012, 18:13
Thank you everyone - I'll try out the suggestions.

Blue_MiSfit
15th February 2012, 20:56
I did see these blocks, I thought you were talking about blocks ONLY in black areas. Sorry about that :)

I did play with fft3dfilter a bit, and got some decent results. I'm sure some MVTools magic would give better results. You could try dfttest as well. I'm just now realizing that I haven't thought about AviSynth denoising / cleanup filters in a long time!

Derek

73ChargerFan
16th February 2012, 08:36
So, I'm not an expert, but the source at second 7 appears clean to me - a flat black. The naive encode gives blocks, so that's why I asked.

I tested the output on two other computers, all different hardware and different rendering, and the blocks show up there as well. Then I started looking elsewhere and saw more. (I'm sensitive to this, like some are bothered by LCD screen door effects or DLP rainbows which thankfully I can ignore.)

I didn't have time today, but will try adjusting psy-rd & --no-dct-decimate. I don't know much about 10bit yet, have heard about it.

Thanks again.

Ghitulescu
16th February 2012, 11:11
If the source is original, maybe you have the PC-TV levels issue.

Didée
16th February 2012, 11:36
That coud be possible as well. In any case, the encoding of x264 is not at fault. Using a simple Avisynth script to compare source/encoding side-by-side:

v1 = ffvideosource("source MPEG2 PAL 10sec.mkv")
v2 = ffvideosource("encode X264 CQ16 Film 10sec.mkv")

stackhorizontal(v1,v2)
levels(15,2.0,128,16,235,false)

Conclusion: The blocks are virtually identical in the mpeg2 source and the x264 encoding.

You cannot improve the encoding in itself when there's nothing wrong with it.

7ekno
16th February 2012, 11:52
Probably the same issues found at the end of this thread:
http://forum.doom9.org/showthread.php?t=163880

7ek

hello_hello
16th February 2012, 12:05
Judging from a few recent threads here regarding blocking in dark areas, it seems incorrect TV/Monitor calibration or sending the TV the wrong levels is often the culprit. I discovered I had the same problem myself. Same thread 7ekno linked to.

I agree with Didée. Maybe I'm missing something but I can't see any significant difference between the source and the encode, and at the 7 second mark where the picture is totally black (or supposed to be) that's all I can see. No blocking at all. I can see blocking if I increase the brightness though, but it's not like the source is free of it.

Are you absolutely sure when you play the encode vs the original, black is displaying with the same level of black? And it's really black, not dark grey?

73ChargerFan
16th February 2012, 18:31
Bingo! It is color space playback in the two different decoders. They default to different levels. I'll retest & post the question with the MPC-HC people. And maybe switch to ffdshow permanently.

Solved. Thank you everyone.

hello_hello
18th February 2012, 08:26
That seems weird. I'd have thought neither change the levels by default, but I guess it's another "gotcha" to keep in mind for "blocky encode" threads.
I just checked my setup and the MPC-HC mpeg decoder isn't set to change the levels and the h264 decoder doesn't appear to have the option. Could it be the renderer or video card?

If you discover the "why" could you post back?

73ChargerFan
18th February 2012, 18:38
1.6.1.4072 has lots of settings. Output levels was set to Auto, changing it to PC (0-255) is what I did.

Color space issues really bug me about watching videos, though. The MPEG2 decoder defaults to TV levels, everything on my computer is set to PC levels but I keep running into this problem. Not the encoder's fault though. Maybe MPC-HC thinks .vob files are dvd, while .mkv files must be broadcast tv or high-def? I don't know.

nm
18th February 2012, 19:32
Maybe MPC-HC thinks .vob files are dvd, while .mkv files must be broadcast tv or high-def?

All of those are encoded at TV levels and that's what a decoder should normally output. It's the renderers task to convert to PC levels when necessary. However, sometimes the renderer might not be signaled properly, or it might not convert levels at all.

I don't know what MPC-HC does and how it should be configured. What renderer and splitter are you using?

hello_hello
18th February 2012, 20:17
Color space issues really bug me about watching videos, though.

My solution, at least with my video card, is to get it to expand all video to PC levels. Then it doesn't matter what the renderer does. It seems, from the bit of testing I've done, if the renderer is already expanding to PC levels the video card won't expand them again. If however, I use a MPC-HC shader to expand the levels, then they do get expanded twice. I don't know why it happens one way and not the other, but using a shader to expand the levels isn't something I'd do anyway.....

The only snag I've hit with that cunning plan.....
For some reason my video card's software (Nvidia) refuses to remember the output setting for the secondary monitor between reboots. Which of course happens to be the TV, so I'm now in the habit of changing it first thing after the PC has booted. My next plan is to put a second card in the PC (I've got a spare of the same model) to see if it'll remember the setting if each monitor is running off a different card.

On a completely off topic note, although I'll probably try it while I'm swapping cards around..... if I was to install an older card not capable of hardware decoding, while a second card in the PC is, will hardware decoding only be used when playing video on the monitor connected to the second card, or would one card decode even while the other is displaying?

Asmodian
18th February 2012, 21:03
On a completely off topic note, although I'll probably try it while I'm swapping cards around..... if I was to install an older card not capable of hardware decoding, while a second card in the PC is, will hardware decoding only be used when playing video on the monitor connected to the second card, or would one card decode even while the other is displaying?

I use an Nvidia card (GT545) to do CUDA decoding with LAV Video but an ATI card (HD6950) connected to the TV and main monitor. The Nvidia card also needs a monitor connected or it will not turn on, though a second connection to the TV works.

Blue_MiSfit
21st February 2012, 04:34
Try MadVR ;)