x264 bframes block on anime content

Sirber · 26th February 2005, 18:54

Hi

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

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

Sagittaire · 26th February 2005, 19:08

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

Sirber · 26th February 2005, 19:10

activated, both setting at 0. It looks like over quantizating

Tryed with 1 ref, 0 bframes. Looks the same.

Tommy Carrot · 26th February 2005, 19:10

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), which is also fixed in libavcodec, but not in ffdshow.

Manao · 26th February 2005, 20:35

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 · 27th February 2005, 16:48

Around 40. I'll redo some tests.

Manao · 27th February 2005, 16:51

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 · 27th February 2005, 17:06

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 · 27th February 2005, 17:11

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 · 27th February 2005, 17:13

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

Sirber · 27th February 2005, 17:13

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

Quote:

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 · 27th February 2005, 17:22

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

Sirber · 27th February 2005, 17:29

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

Thanks for the help!

DeathTheSheep · 28th February 2005, 21:56

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 · 28th February 2005, 23:07

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

hpn · 1st March 2005, 02:08

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 · 1st March 2005, 02:10

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 · 1st March 2005, 11:24

Quote:

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 · 1st March 2005, 13:00

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

hellfred · 1st March 2005, 19:13

Quote:

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

26th February 2005, 18:54	#1 \| Link
Sirber retired developer Join Date: Oct 2002 Location: Canada Posts: 8,978	x264 bframes block on anime content Hi I have a strange blocking problem with x264 (b130 - b144): This is with 3 bframes, I have something similar with none. Tested at 536kbps and 800kbps, 16 ref. __________________ Detritus Software Last edited by Sirber; 1st March 2005 at 01:23.

26th February 2005, 19:08	#2 \| Link
Sagittaire Testeur de codecs Join Date: May 2003 Location: France Posts: 2,484	inloop desactived ... ??? and 16 ref frames are useless __________________ Le Sagittaire ... ;-) 1- Ateme AVC or x264 2- VP7 or RV10 only for anime 3- XviD, DivX or WMV9

26th February 2005, 19:10	#3 \| Link
Sirber retired developer Join Date: Oct 2002 Location: Canada Posts: 8,978	activated, both setting at 0. It looks like over quantizating Tryed with 1 ref, 0 bframes. Looks the same. __________________ Detritus Software

27th February 2005, 16:48	#6 \| Link
Sirber retired developer Join Date: Oct 2002 Location: Canada Posts: 8,978	Around 40. I'll redo some tests. __________________ Detritus Software

27th February 2005, 17:06	#8 \| Link
Sirber retired developer Join Date: Oct 2002 Location: Canada Posts: 8,978	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.. __________________ Detritus Software

26th February 2005, 19:10	#4 \| Link
Tommy Carrot Registered User Join Date: Mar 2002 Posts: 863	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), which is also fixed in libavcodec, but not in ffdshow.

26th February 2005, 20:35	#5 \| Link
Manao Registered User Join Date: Jan 2002 Location: France Posts: 2,856	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 ?

27th February 2005, 16:51	#7 \| Link
Manao Registered User Join Date: Jan 2002 Location: France Posts: 2,856	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

27th February 2005, 17:11	#9 \| Link
Manao Registered User Join Date: Jan 2002 Location: France Posts: 2,856	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 %

27th February 2005, 17:13	#10 \| Link
dragongodz .... Join Date: May 2002 Location: Australia Posts: 2,797	can you try increasing ref (say 5) for 3 B frames ? or even test with just 1 B frame ? __________________ Narrator: And of course, with the birth of the artist came the inevitable afterbirth - the critic. (History of the World part 1)

27th February 2005, 17:22	#12 \| Link
Manao Registered User Join Date: Jan 2002 Location: France Posts: 2,856	Try to lower it to 1.1 / 1.2, to see if it's better

27th February 2005, 17:29	#13 \| Link
Sirber retired developer Join Date: Oct 2002 Location: Canada Posts: 8,978	I'll retry that when the new ffdshow with deblocking will be avalible. Thanks for the help! __________________ Detritus Software

28th February 2005, 21:56	#14 \| Link
DeathTheSheep <The VFW Sheep of Death> Join Date: Dec 2004 Location: Deathly pasture of VFW Posts: 1,149	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! __________________ Recommended all-in-one stop for x264/GCC needs on Windows: Komisar x264 builds!

28th February 2005, 23:07	#15 \| Link
Sirber retired developer Join Date: Oct 2002 Location: Canada Posts: 8,978	Better wait when deblocking will be working on ffdshow. BFrames are really good to lower the bitrate... and I love lower bitrate __________________ Detritus Software

1st March 2005, 02:08	#16 \| Link
hpn Registered User Join Date: Jan 2005 Posts: 191	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.

1st March 2005, 02:10	#17 \| Link
Sirber retired developer Join Date: Oct 2002 Location: Canada Posts: 8,978	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). __________________ Detritus Software

1st March 2005, 13:00	#19 \| Link
Sirber retired developer Join Date: Oct 2002 Location: Canada Posts: 8,978	Yeah, I know. That's why I'm waiting... __________________ Detritus Software