x264 blocky on blue backgrounds

[madoka]

x264 settings are as follows:
x264 -p 1 -B 1477 -b 3 -A none --me dia -m 1
x264 -p 3 -B 1477 -b 3 -A none --me dia -m 1
x264 -p 2 -B 1477 -b 3 --b-pyramid -r 5 -A all -w --me umh -m 6 -8This is just the most obvious example, but frequently if there's a large patch of blue then highly visible blocking artifacts would be visible. Considering what the source material (anyone want to guess?) is, there's a lot of blue. :(

Curiously, if I isoloate only the problem ranges and encode them separately using the same setting as above, then the artifacts go away. Only when I encode the entire source would the artifacts be visible.

[Sirber]

Try:

x264 -p 1 -B 1477 -b 3 -A none --me dia -m 1
x264 -p 3 -B 1477 -b 3 --b-pyramid -r 5 -A all -w --me umh -m 6 -8
x264 -p 2 -B 1477 -b 3 --b-pyramid -r 5 -A all -w --me umh -m 6 -8

Fast First Pass screw I think.

[CiNcH]

I am experiencing exactly the same problem, but with almost(?) every codec. I have a short test clip from "The Mummy Returns" where there is a scene with a lot of blue sky. It's being coded with the same blocking artefacts.

I have tried almost every setting in x264, nothing really solves the problem, except dramatically increasing bitrate. Using Soulhunter's AVC v2 CQM seems to minimize the effect for me but introduces different problems.

Have a look at the attached screenshot...

[Caroliano]

A bit of topic but is this Nausicaä? This credits fonts are familiar for me... and the year match.

I see much more definied blocks in BSplayer but almost none blocking in MPC. What is wrong? I'm using FFDshow to decode and the defaut setings in both.

[madoka]

Try:

x264 -p 1 -B 1477 -b 3 -A none --me dia -m 1
x264 -p 3 -B 1477 -b 3 --b-pyramid -r 5 -A all -w --me umh -m 6 -8
x264 -p 2 -B 1477 -b 3 --b-pyramid -r 5 -A all -w --me umh -m 6 -8

Fast First Pass screw I think.I'm currently in the process of trying this. I'll report back when the encode's done.

In general, is it the case that one can only "cheat" on the first pass, and should use the same settings in Nth pass and last pass?

A bit of topic but is this Nausicaä? This credits fonts are familiar for me... and the year match.Yes, good eye! Here's a cookie! :)

[Sharktooth]

the "cheat" can be done in the 1st pass!!! (that's why in vfw it's called fast FIRST pass...)

@CiNcH: try my matrix too. it will help with blocks.

[Sirber]

@CiNcH

Convolution3D ?

[yaz]

@cinch
yep ... keeping shallow luma gradients is a pita for all codecs. imho, the only solution is giving 'enough bits' for that scenes (enough=as many as just can). there are some other workarounds, sharpening, adding artificial details (=noise), aso, aso, but all these have some side-effects.
an other way round is using pp-deblocking. (i don't mean db in x/h264, but some tricking w/the postprocessor)
shrinking a movie to 10-20% may work w/some animes (i doubt it hardly, anyway) but not w/'natural' sources. x/h264 is very effective but not miraculous. it has its own limitations. if u go extreme it starts blocking/ringing/... just as any other codec.

btw, i cannot see any 'dramatic' blocking in yor pic. isn't it your monitor a/o graphics card a/o decoder a/o ... so sg on the playback side ?

the bests
y

[CiNcH]

@CiNcH

Convolution3D ?

Well, you are right, there is a lot of noise in the blue sky of my clip. Convolution3D denoiser does not seem to remove it. Probably it is only a heavy task to code that much noise...


btw, i cannot see any 'dramatic' blocking in yor pic.

It looks much worse if you watch the whole sequence and especially when resized to fullscreen.

Probably you are right and the effect is much worse because I am doing my tests on my notebook with crystal clear 15.4" TFT widescreen display.

[Sirber]

those "blocks" are still anoying... even if not easy noticable.

[madoka]

Okay, my second attempt's done. Actually this is my 3rd; the 2nd went FUBAR due to a stupid error I made. The big problem areas's fixed (such as the one above), but a few still remains, such as:

http://www.geocities.com/ayanami_rei_ii/misc/artifact2.png

(The linked image above is PNG. In case my bandwidth runs out, I also attached it in JPEG--PNG is too large to attach. But the blocking is definitely not caused by JPEG. In fact, the JPEG is marginally less blocked.)

I also encoded the source with XviD; the result doesn't look as good overall compared to that of x264's, but it doesn't block catastrophically in the problem areas either.

I'm currently encoding it again, this time without using fast first pass settings; hopefully this'll fix all the problems.

[madoka]

Okay, the encode where no corner's cut is finally finished. Almost all of the problem areas are eliminated or reduced to acceptable levels. However, there are still problems that just won't go away:

http://www.geocities.com/ayanami_rei_ii/misc/compare-avc.png
http://www.geocities.com/ayanami_rei_ii/misc/compare-xvid.png

(The actual video frames are twice the size in each dimension; I halfed the screenshots to save bandwidth.)

On the left is x264, and on the right is XviD. Even at half the size the artifacts are painfully visible.

I believe the cause of these artifacts are either bugs or poor handling of corner cases in x264. IMO x264 looks much better than XviD everywhere else except for the problem spots--I saw ~10 such spots in my last encode.

Perhaps I should just increase the bitrate (but at 1477 it's already very high), or maybe I should decrease the bitrate instead?

[Sirber]

Update FFDShow. I think yours could be outdated and don't inloop proprely. Can you post a file with the anime clip?

[madoka]

Update FFDShow. I think yours could be outdated and don't inloop proprely. Can you post a file with the anime clip?
I'm using 7/3/05 snapshot of ffdshow, which is the latest version I can find. I don't remember if I have the MSVC build or not.

I'd love to proivde a clip, but there's no way to cut a mp4 file yet AFAIK. And as I noted before, if I only encode the source near the problem areas, then the problem goes away.

EDIT: just tried both ffdshow builds; there's no difference.

[omion]

You could use MKVmerge to split the .mp4 into multiple Matroska files, then post the one which has the error.

If you use MMG (the MKVmerge GUI), drag the .mp4 file onto the "input files" field. Then go to the "Global" tab and enable splitting by timecodes. You'll get back multiple files, cut at the keyframe after the times you specifed.

There may also be a native .mp4 program that does it, but I'm a Matroska guy ;)

[edit: got rid of quote]

[madoka]

You could use MKVmerge to split the .mp4 into multiple Matroska files, then post the one which has the error.
Nifty! That's a cool trick to remember.

http://www.geocities.com/ayanami_rei_ii/misc/clip.mkv.zip

[Doom9]

mp4box can split mp4 files

[yaz]

@madoka
your clip is unavailable. check the link, pls.

anyway, my 1% would be a kinda rendering problem. i used to get such heavy blocking on plain surfaces when the 'video output' is set improperly (color depth, rendering mode, decoder output mismatch, whatever) check this also.

the bests
y

[CREXbzh]

Perhaps I should just increase the bitrate (but at 1477 it's already very high), or maybe I should decrease the bitrate instead?
Maybe you should try to raise the inloop filter settings a bit.

[madoka]

@madoka
your clip is unavailable. check the link, pls.
The link is fine, it's just that GeoCities isn't very generous in terms of bandwidth. The cap is lifted after a while, so please try again later.

anyway, my 1% would be a kinda rendering problem. i used to get such heavy blocking on plain surfaces when the 'video output' is set improperly (color depth, rendering mode, decoder output mismatch, whatever) check this also.
http://www.geocities.com/ayanami_rei_ii/misc/ffdshow.png

This is what my settings look like. Do you see anything out of the ordinary? :eek:

[Sharktooth]

could you try re-encoding the clip with the new rev.281 and see if it fixes the prob?

[Chainmax]

Sorry for the slight hijack, but "use overlay mixer" should be checked in order to playback anamorphic encodes with the proper aspect ratio, right?

[Sharktooth]

yep...

[bond]

mp4box can split mp4 filesand qt7 can propably do it too i guess

[yaz]

@madoka
i grabbed and checked your source. bad news, blocks are there. however, i don't think it's an encoder problem, rather seems like a kinda bad upsampling or so. that annoying blocks are fakes, definitely. (just watch the pictures attached above). the blocks are fake shades of that greyish-brownish-color of the boots and the trousers. this shade is not there(! see the pict from xvid !) sg introduced it during the process. (it reminds me the 'skin-color problem' of the early xvid pretty much.)

pls, try the latest version of x264, both the cli and the vfw version. maybe it's just some block misalignment, but it may have many other sources.

the bests
y

ps. imho, there's no need for such a high bitrate. your source is pretty compressible. the average frame quantizer of your clip waves betw 16-20. imho, u can lower the bitrate safely.

[akupenguin]

No decoder bug; JM decodes the same artifacts.

Hmm... the artifacts appear in an I-frame, that makes things easier. (1) It excludes ME and skip algos. (2) It means that you don't have to worry about exact sequences of quantizers -- encoding that section with the right constant quantizer should produce an identical frame. See if you can reproduce it that way, and try minimize the necessary size of the input clip (a 1 frame input should be possible).

Comments on the symptoms: The errors appear in vertical or diagonal-down-right lines, with the areas to the left being correct, and the area to the right has wrong DC. Additionally, in both in the blue titlescreen and in the last clip, the macroblocks at the top edge of the screen on the artifact border contain some extraneous white dots. Combine that with the fact that they're I-frames, and I hypothesize:
x264 doesn't know about the artifacts. In a couple of macroblocks, the DCT coefficients written to the stream are different from what it uses to reconstruct the block. Or since it's only on the edge of the frame, maybe they use DC_128 instead of DC_LEFT prediction, or the like (which are written identically in the bitstream). This reconstruction error then propopgates to the rest of the frame via intra prediction, and to following frames via motion compensation.

[madoka]

Sorry for the slight hijack, but "use overlay mixer" should be checked in order to playback anamorphic encodes with the proper aspect ratio, right?
Well, I don't do anamorphic encodes. Resizing before encoding is simpler, and my eyes aren't good enough to tell the difference.

No decoder bug; JM decodes the same artifacts.

Hmm... the artifacts appear in an I-frame, that makes things easier. (1) It excludes ME and skip algos. (2) It means that you don't have to worry about exact sequences of quantizers -- encoding that section with the right constant quantizer should produce an identical frame. See if you can reproduce it that way, and try minimize the necessary size of the input clip (a 1 frame input should be possible).
Sorry, but can you give me a more detailed instruction in how to do that?

[foxyshadis]

Save the frame you're interested in from the source (via vdub, avisynth trim(), etc) and create a video using just that frame. Use a constant-quant encode, and you might need to disable b-frames. (Perhaps several const-quants, see where it shows up at.)

[madoka]

Save the frame you're interested in from the source (via vdub, avisynth trim(), etc) and create a video using just that frame. Use a constant-quant encode, and you might need to disable b-frames. (Perhaps several const-quants, see where it shows up at.)
Sorry, I should have been more clear about my confusion. I know to isolate the problematic bits, but I'm not sure how to force x264 to output only I-frames.

Turning off B-frames: -b 0
Constant quantizer: --qpmin N --qpmax N, where N is some number
Force I-frames only: ? (--ipratio, -r, --qpcomp don't do the trick)

BTW, I noticed that x264 doesn't output identical mp4 files given the same settings and source file. Raw output matches, though. What's even more odd is that mp4box exibits the same behavior. Furthermore, if extract the raws stream out of the mp4 using mp4box, the extracted raw file doesn't match the original raw file! In other words, suppose I did the following:

x264 [flags omitted] -o output1.mp4 input.avs
x264 [flags omitted] -o output2.mp4 input.avs

x264 [flags omitted] -o output1.264 input.avs
x264 [flags omitted] -o output2.264 input.avs

mp4box -add output1.264 -fps 23.976 muxed.mp4
mp4box -raw 1 muxed.mp4 [generates muxed_track1.h264]Then:

output1.mp4 and output2.mp4 will differ
output1.264 and output2.264 won't differ
output1 and muxed_track1.h264 will differ


What's up with that? :confused:

[etran1]

Try adding -I 1 -i 1 to your command line. I believe that should force your GOP size to be one and only give you I frames.

[Doom9]

no b-frames is the default, and you set constant quantizer mode using the --qp flag. Just make sure your video starts with the affected frame and it'll automatically be an I-frame ;)

[madoka]

Additionally, in both in the blue titlescreen and in the last clip, the macroblocks at the top edge of the screen on the artifact border contain some extraneous white dots.
I ran a script that encoded the problem spots at constant quantizer setting, ranging from 10 to 51 (the default range). Unfortunately, I was unable to replicate the exact error. However, I did spot the white dots at certain quantizer settings:

http://www.geocities.com/ayanami_rei_ii/misc/dots.png

The fact that there doesn't seem to be a pattern between the quantizer and the dots' appearance got me thinking. I tried encoding each quantizer setting twice with raw output (earlier I noted that x264 doesn't give bit-identical mp4 output even for the same input and settings). Nonetheless, the raw outputs don't match! To be absolutely sure, I tried 4 times, and each time x264 gave a different raw file.

Now I thought perhaps the problem has nothing to do with x264. Maybe I have faulty RAM, etc. But then I tried encoding with --no-asm, and the outputs become identical, and the white dots go away. I also tried to encode it on another machine, a 1.2 GHz P-III (all previous outputs were encoded on an Athlon XP 2700+ running at regular clock speed). On the P-III, the outputs between setting and omitting --no-asm are identical, and they also match the --no-asm output from my XP 2700+.

IIRC, when I first encountered the problem I wasn't using r281, but since neither CPU supports SSE2 it shouldn't make a difference anyway. So maybe I do have bad hardware... :(

[Manao]

> Nonetheless, the raw outputs don't match! To be absolutely sure, I tried 4 times, and each time x264 gave a different raw file

Is your system overclocked ?

Edit : I should read more thoroughly, sorry.

[Sharktooth]

r281 has this fix also:

Revision: 281
Author: pengvado
Date: 18.07.17, martedì 26 luglio 2005
Message:
update i_mb_b16x8_cost_table[] for I8x8 mb type (r278 only fixed a symptom).
----
Modified : /trunk/common/sparc/pixel.asm
Modified : /trunk/common/sparc/pixel.h
Modified : /trunk/encoder/analyse.c
Modified : /trunk/matroska.c
Modified : /trunk/matroska.h

[akupenguin]

But then I tried encoding with --no-asm, and the outputs become identical, and the white dots go away.
Then try running checkasm to see if it's one specific function (not built by default; type "make checkasm" first).

[CiNcH]

http://members.aon.at/cinch/checkasm.exe

[madoka]

Then try running checkasm to see if it's one specific function (not built by default; type "make checkasm" first).
x264: MMXEXT against C
- pixel sad : [OK]
- pixel satd : [OK]
- pixel avg : [OK]
- sub_dctXxX : [OK]
- add_idctXxX : [OK]
- (i)dct4x4dc : [OK]
- (i)dct2x2dc : [OK]
- mc luma : [OK]
- mc chroma : [OK]
x264: All tests passed Yeah :)
I guess it's time for me to run memtest86 and Prime95 again... :( Sorry for all the trouble when it appears just to be faulty hardware. :o

@CiNcH:
Thanks, but I've already built my own. Wish I had saw your post earlier though.

[CiNcH]

I guess it's time for me to run memtest86 and Prime95 again... Sorry for all the trouble when it appears just to be faulty hardware.

Yes, but the main problem, blocking, is not due to faulty hardware.

http://forum.doom9.org/attachment.php?attachmentid=4121&stc=1

This is another example posted recently. Blocking appears on the wall behind the man coming out of the house, it becomes much more apparent when watching the whole sequence resized to fullscreen...