x264 bframes block on anime content

[Sirber]

Hi

I have a strange blocking problem with x264 (b130 - b144):

http://www.detritus.qc.ca/files/snapshot20050226125259.jpg

This is with 3 bframes, I have something similar with none. Tested at 536kbps and 800kbps, 16 ref.

[Sagittaire]

inloop desactived ... ???
and 16 ref frames are useless

[Sirber]

activated, both setting at 0. It looks like over quantizating :(
Tryed with 1 ref, 0 bframes. Looks the same.

[Tommy Carrot]

There can be 2 reasons. FFdshow doesn't deblock the b-frames (but Akupenguin already committed the b-frames deblocker code into ffmpeg, so we just have to wait until ffdshow gets updated too), and it's also possible that the flawed decoding of weighted prediction causes the heavy blocking (see this thread (http://forum.doom9.org/showthread.php?s=&threadid=90511)), which is also fixed in libavcodec, but not in ffdshow.

[Manao]

It's not bweighted prediction ( rev130 didn't have it ). It's not deblocking on bframes ( since without bframes, the problem is still there ).

What was the quantizer of that particular frame you showed us ?

[Sirber]

Around 40. I'll redo some tests.

[Manao]

40 ??? You disabled in loop deblocking then. That or you were wrong when you stated previously that even without bframes, you're getting these blocks

[Sirber]

I just made two tests, one with bframes and one whitout. It seems in my older tests bframes were at 3 (screenshot and the other test with ref at 1, but bframes at 3).

The test whitout bframes has no blocks and quant is ~30. With bframes (3), quants goes up to 40 for bframes and ~26 for P. By default, settings for bfrrmes are "Reduce 30%", maybe that's why..

[Manao]

Ok, so it's indeed a combination of lack of inloop deblocking on bframes ( will soon be corrected in ffdshow, already corrected in ffmpeg if i'm not mistaken ) and very high quantizers ( or too low bitrates ).

Even with bframe deblocking, you might want to lower the bframe reduce factor to 20 %

[dragongodz]

can you try increasing ref (say 5) for 3 B frames ? or even test with just 1 B frame ?

[Sirber]

My bitrate goal is 536kbps (600kbps with audio). Should I disable bframe reduce %?

Originally posted by dragongodz
can you try increasing ref (say 5) for 3 B frames ? or even test with just 1 B frame ? With 1 ref or 16 ref, same problem.

[Manao]

Try to lower it to 1.1 / 1.2, to see if it's better

[Sirber]

I'll retry that when the new ffdshow with deblocking will be avalible.

Thanks for the help! :D

[DeathTheSheep]

In a previous thread entitled "The Coolness of B-Frames," I've outlined a similar problem.

The problem is, extreme blocking occurs in anime encodes with 1 or more b-frames.

Try using 0 or 1 b-frame(s), and set reference frames to 15. You may want to increase the bitrate just a *tiny* bit to compensate for the immediate quantization decrease (no more than 10-15%).

You will see marked improvement, especially if all settings are checked (except B-frame search if using 0 b-frames, which is recommended for anime).

Bi-directional prediction of exteremely fast-moving content (like that Naruto intro, when the clouds are moving at 400mph) or choppy content (such as animation characters, which don't move with the liquid motion of people), tends to be absolutely terrible, even with deblocking, which reduces detail considerably on b-frames. (And I daresay they had reletively no detail to begin with).

Solution: Use max settings with 0 b-frames, 15 refs (or 1-bframe if you're desperate).

Cheers!

[Sirber]

Better wait when deblocking will be working on ffdshow. BFrames are really good to lower the bitrate... and I love lower bitrate :p

[hpn]

Your screenshot actually looks very decent. An average DVD encode with almost no or very little downsizing (W-Zoom 95% to 98%) usually has a 688x288 frame size, or 744 16x16 blocks. In your case the frame size is 640x480 or 1200 16x16 blocks. It means that your 536kbps encode has the same quality as a 9/16 DVD encode at 332kbps! (744/1200x536). I don't think in this case you could expect miracles from your encode and maybe at such a low bitrate ffdshow simply does not trigger the deblocking part (not sure about it however), trying to preserve as much picture contrast as possible, otherwise you'll really get a blocking-free picture but so blurred out that no text would be readable. Just try the same encode at about 900-1000kbps and if the blocking persists this maybe really a bug that needs to be fixed.

[Sirber]

I don't have that blocking issue with RV10 or VP6. IMO it's really a decoder problem (deblock bframes) as well as untuned bframes % (my bad).

[bond]

Originally posted by Sirber
[B]Better wait when deblocking will be working on ffdshow.ffmpeg does it already, now only milan needs to update to the latest libavcodec

[Sirber]

Yeah, I know. That's why I'm waiting...

[hellfred]

Originally posted by Sirber
Yeah, I know. That's why I'm waiting...
Sirber, just help yourself to a homegrown mplayer win32 binary. Once MinGW/MSYS is set up, you get it in 30 minutes on a PIII 550MHz - and can easily link it to latest x264 for encoding, which by the way, gets compiled in less than 5 minutes in my system.

Hellfred

[Sirber]

yeah, but "common user" uses ffdshow in MPC, which I do :) I'm not in a hurry, I still have RealAnime 3.0.0 to finish :rolleyes:

Thanks for the hint though :)

[Tommy Carrot]

Milan updated the libavcodec in ffdshow, so we just have to wait the next build.

[Sirber]

Great! :D

[Sharktooth]

hey... the build with the new libavcodec is available since yesterday...
http://ffdshow.sourceforge.net/tikiwiki/tiki-index.php?page=Getting+ffdshow

[Sirber]

got it today :)

thanks!! :D

[Sharktooth]

Is the "blocking" fixed?

[Sirber]

Yes.

ffdshow deblock the video now :D. I have now to play with the settings to get the optimal image quality for 536kbps :)

But I spotted this:
http://www.detritus.qc.ca/files/snapshot20050303074318.jpg

[akupenguin]

Yes, ffdshow deblocks now. But that doesn't mean the problem is gone. If you get QP=40 in B-frames and QP=26 in P-frames, then you are using CBR, which is b0rked more than the CBR of most codecs.

[Sirber]

Originally posted by akupenguin
Yes, ffdshow deblocks now. But that doesn't mean the problem is gone. If you get QP=40 in B-frames and QP=26 in P-frames, then you are using CBR, which is b0rked more than the CBR of most codecs. I'm having mostly something like that, in 2pass :(

[ChronoCross]

my first question is why are you trying to push that down to 500kbps? tat's a little bit unreasonable for the length and resolution/

[Sirber]

VP6 and RV10 can do it pretty well. And for anime content, this is a very resonable bitrate to get between 85 and 100 MB.

[Sharktooth]

There are other problems with gcc 3.4.2... i found another case of blocking...

[Teegedeck]

Originally posted by Sirber
I'm having mostly something like that, in 2pass :(
There is a field where you can enter the allowed variance of quantizer for 2nd pass. (I cannot look up its exact name right now because my girlfriend watches a soap on the Windows box and I'm too lazy to look for the MAN pages) The default value is a whopping 40% for that variance, I cannot imagine why.

[Sirber]

I used the defaults, except 10% reduction for bframes instead of insane 30%.

[Sharktooth]

Sirber, try using my new build.
I found the bug was caused by the -fomit-frame-pointer flag. I removed it (celtic druid's build had the same problem).

[Sirber]

I tryed 149. I'll retry tonight.

[Sharktooth]

It's still 149, but i changed some compiler options. Now there is no more blocking.
Btw if you want to test it i also made an athlon64 compile: http://www.aziendeassociate.com/X264VFW_rev149_a64.exe

[Sirber]

It works, but the encode is worst. I played with the settings and I can't get out of quants 35-40 :(

The wierd block is gone too.

What would you suggest for 536kbps, naruto content? :D

[sysKin]

Originally posted by Sirber
I used the defaults, except 10% reduction for bframes instead of insane 30%. Oh? 30% is very conservative, it's like xvid's 0 offset and 1.3 ratio. It only increases qp by two.

With 10%, you're most likely using the same qp for b-frames as for p-frames.

[scorpdt]

Hi Guys ... hope I am not intruding here

Using the latest daily Build Rev149 X264 and mencoder (dev-CVS-050301-06:49-3.4.2) is giving me block artifact as follows:-

http://scorpio1.homeip.net:6970/images/bad000.jpg
http://scorpio1.homeip.net:6970/images/bad001.jpg

Only when reverting back to mencoder earlier release i.e. (dev-CVS-050222-01:18-3.4.2) everything is fine.

http://scorpio1.homeip.net:6970/images/ok000.jpg
http://scorpio1.homeip.net:6970/images/ok001.jpg

Looks like there is some problem with CD latest mencoder built.

Take Care!
Scorpio

[Sharktooth]

Yes, it's the same problem i had with x264.
Wait for a new compile, i'm just uploading the files.