Log in

View Full Version : blocking on scene cuts


leoenc
22nd February 2008, 19:45
Any idea what could cause blocking on scene cuts?
Encoding is fine overall but on some scene cuts, ugly blocks appear on the following frame or few.

This is my CLI (x264 is 736, tried with VAQ and without):

x264.exe --bitrate 2000 --level 3 --keyint 40 --ref 3 --mixed-refs --bframes 3 --b-rdo --bime --weightb --subme 6 --trellis 1 --analyse p8x8,b8x8,i4x4 --vbv-bufsize 3000 --vbv-maxrate 2050 --vbv-init 0.3 --ratetol 0.1 --qcomp 0.0 --threads auto --thread-input --sar 37:25 --progress --no-psnr --output "test.264" "test.avs"

Dark Shikari
22nd February 2008, 19:46
Tried doing twopass VBV encoding instead of onepass?

Sasovics
22nd February 2008, 19:50
I've got the same issues, but only when I turned decoder's Inloop deblocking off. If you're using CoreAVC as your H264 decoder, make sure it's deblocking feature is set to on. It might help...

leoenc
22nd February 2008, 20:19
Tried doing twopass VBV encoding instead of onepass?

I did, 2pass eliminates this problem, but VBV is not compliant - I get many underflows.
I patched 736 with the latest VBV patch and it didn't help.
I also tried with pre-patched builds on the forum (bobor's x264.736.modified.02.exe) but x264 hangs on the beginning of 2nd pass, i think it has to do with VAQ (when I built with no VAQ it doesn't hang).

x264.exe --pass 1 --stats ".stats" --bitrate 2000 --level 3 --keyint 40 --ref 3 --mixed-refs --bframes 3 --b-rdo --bime --weightb --subme 6 --trellis 1 --analyse p8x8,b8x8,i4x4 --vbv-bufsize 3000 --vbv-maxrate 2050 --vbv-init 0.3 --ratetol 0.1 --qcomp 0.0 --threads auto --thread-input --sar 37:25 --progress --no-psnr --output "test.264" "test.avs"

x264.exe --pass 2 --stats ".stats" --bitrate 2000 --level 3 --keyint 40 --ref 3 --mixed-refs --bframes 3 --b-rdo --bime --weightb --subme 6 --trellis 1 --analyse p8x8,b8x8,i4x4 --vbv-bufsize 3000 --vbv-maxrate 2050 --vbv-init 0.3 --ratetol 0.1 --qcomp 0.0 --threads auto --thread-input --sar 37:25 --progress --no-psnr --output "test.264" "test.avs"

Dark Shikari
22nd February 2008, 20:20
I did, 2pass eliminates this problem, but VBV is not compliant - I get many underflows.
I patched 736 with the latest VBV patch and it didn't help.
I also tried with pre-patched builds on the forum (bobor's x264.736.modified.02.exe) but x264 hangs on the beginning of 2nd pass, i think it has to do with VAQ (when I built with no VAQ it doesn't hang).

x264.exe --pass 1 --stats ".stats" --bitrate 2000 --level 3 --keyint 40 --ref 3 --mixed-refs --bframes 3 --b-rdo --bime --weightb --subme 6 --trellis 1 --analyse p8x8,b8x8,i4x4 --vbv-bufsize 3000 --vbv-maxrate 2050 --vbv-init 0.3 --ratetol 0.1 --qcomp 0.0 --threads auto --thread-input --sar 37:25 --progress --no-psnr --output "test.264" "test.avs"

x264.exe --pass 2 --stats ".stats" --bitrate 2000 --level 3 --keyint 40 --ref 3 --mixed-refs --bframes 3 --b-rdo --bime --weightb --subme 6 --trellis 1 --analyse p8x8,b8x8,i4x4 --vbv-bufsize 3000 --vbv-maxrate 2050 --vbv-init 0.3 --ratetol 0.1 --qcomp 0.0 --threads auto --thread-input --sar 37:25 --progress --no-psnr --output "test.264" "test.avs"x264 has historically not been very good at keeping to within VBV limits, unfortunately.

Try using VAQ with sensitivity 0 [auto] if you plan to use it, since you're doing CBR (auto sensitivity is best with CBR).

leoenc
22nd February 2008, 20:36
I must also add that when using --threads 1 it helps a lot to eliminate the artefacts (i'm on dual core).

DeathTheSheep
22nd February 2008, 20:36
When I saw this thread, at first I thought he meant fades. x264 isn't all too good with fades, at least with p-frames.

DS, would you by any chance be up to hacking together a p-wpred? I recall you saying something about this before (but somehow involving reference frame trickery or something like that).

Dark Shikari
22nd February 2008, 20:39
When I saw this thread, at first I thought he meant fades. x264 isn't all too good with fades, at least with p-frames.

DS, would you by any chance be up to hacking together a p-wpred? I recall you saying something about this before (but somehow involving reference frame trickery or something like that).Akupenguin already has a patch--he tried it a while back and it didn't seem very useful.

Fades are a Hard Problem (TM).

CruNcher
23rd February 2008, 20:18
@leoenc
see this
http://forum.doom9.org/showpost.php?p=1098689&postcount=16
http://forum.doom9.org/showpost.php?p=1098902&postcount=35

but this i-frame appears long before the actuall fade out