x264 r1583M Blockiness?

[rack04]

I have noticed significant blockiness in my last couple encodes. I compared the encoder settings and the only differences between one that exhibits blockiness and one that does is the fade_compensate=0.00 and weightb=1 vs. wpredb=1 with the one that works fine. More importantly the one that exhibits blockiness was encoded with r1583M and the one that doesn't was encoded with r1570M. Both builds were patched with x264.open-gop.20 and the r1583M was patched with x264_fade_compensation. Here are my system specs:

Windows 7 64bit
Nvidia 8800gt loaded with 197.57 drivers
MPC-HC x32 r1862
ffdshow x32 r3422 with ffmpeg-mt set to decode h264
EVR Custom Pres
Haali Media Splitter 27/03/2010

My encode settings for both files:

--preset slower --tune film --crf 18 --level 4.1 --ref 6 --bframes 3 --keyint 48 --min-keyint 2 --vbv-bufsize 14745
--vbv-maxrate 14745 --slices 4 --aud --sar 1:1 --b-pyramid strict --nal-hrd vbr --open-gop --colorprim "bt709"
--transfer "bt709" --colormatrix "bt709" --output "E:\Work\Crazy Horse-output.264" "E:\Work\Crazy Horse.avs"
--qpfile "E:\Work\Crazy Horse_qpfile.txt"

The input "E:\Work\Crazy Horse.avs" contains the following script:

LoadPlugin("C:\Program Files (x86)\DGIndexNV\DGMultiDecodeNV.dll")
DGMultiSource("E:\Output\Crazy Heart.dgi")


Here (http://www.multiupload.com/44HSZCHLNW) is a sample thats exhibits the blockiness at the beginning of the file and whenever you seek.

I'm very interested to know if anyone else experiences this problem with this sample.

[Dark Shikari]

Can you try it on a build that isn't patched to high heaven with unsupported changes?

I'm pretty sure that opengop is broken.

[shon3i]

Yes it's opengop, but some builds work, some produce this blockness.

[rack04]

Yes it's opengop, but some builds work, some produce this blockness.

Well it looks like you were right. I found a typo in x264.open-gop.20 when I updated it from r1570 to r1583. I have only myself to blame for this error.

[moviefan]

I have had similar blockiness in my last two encodes using r1583 and open gop, but I thought it's a decoder problem. However, I do not have blocks at the beginning of the clip and the only randomly occur when seeking but not always. Also they look more grey and obvious than in the sample clip from the first post. Is this definitely a bug in the build? I compiled x264 myself with the open gop patch...

[Dark Shikari]

I have had similar blockiness in my last two encodes using r1583 and open gop, but I thought it's a decoder problem. However, I do not have blocks at the beginning of the clip and the only randomly occur when seeking but not always. Also they look more grey and obvious than in the sample clip from the first post. Is this definitely a bug in the build? I compiled x264 myself with the open gop patch...Random seeking blocks are largely caused by crappy video players and crappy demuxers, like VLC.

[moviefan]

I used a pretty recent MPC-HC x64 build and both - the internal decoders as well as ffdshow tryout x64 - sometimes cause blocks after seeking. But when I jump back a few seconds and play the same part again starting from there, it decodes correctly, so the video itself does not seem to be broken. Does this sound to you like the same problem the rack04 reported or is this most probably really a decoder issue? (I hope it is the latter...)

[Dark Shikari]

I used a pretty recent MPC-HC x64 build and both - the internal decoders as well as ffdshow tryout x64 - sometimes cause blocks after seeking. But when I jump back a few seconds and play the same part again starting from there, it decodes correctly, so the video itself does not seem to be broken. Does this sound to you like the same problem the rack04 reported or is this most probably really a decoder issue? (I hope it is the latter...)This is probably a demuxer issue related to the fact that open-gop uses recovery point SEIs instead of IDR frames.

[jpsdr]

Well it looks like you were right. I found a typo in x264.open-gop.20 when I updated it from r1570 to r1583. I have only myself to blame for this error.

Do you have updated your builds, or not yet ?

[shon3i]

Do you have updated your builds, or not yet ?
Wait few more days, Trahald need something to fix. If that everyting passes, probably will merged to GIT.

[rack04]

I used a pretty recent MPC-HC x64 build and both - the internal decoders as well as ffdshow tryout x64 - sometimes cause blocks after seeking. But when I jump back a few seconds and play the same part again starting from there, it decodes correctly, so the video itself does not seem to be broken. Does this sound to you like the same problem the rack04 reported or is this most probably really a decoder issue? (I hope it is the latter...)

The blocks are gone with the typo that fixed in the open-gop patch. Which version of the patch did you use in your build? I'm still having serious studdering issues when seeking in MPC-HC but it doesn't seem like a open-gop problem since it happens with files created without open-gop. It doesn't happen with MPC-HC internal h264 transform filter or ffdshow libavcodec decoder but the problem is persistent with ffdshow ffmpeg-mt decoder. Unfortunately I can't narrow it down any farther than that.

[moviefan]

I used the patch from this post: http://forum.doom9.org/showthread.php?p=1397808#post1397808

What kind of problem did you find? I noticed that seeking with ffmpeg-mt is VERY slow! It takes a couple of seconds until the video continues playback. Neither MPC-HC's internal filters nor ffmpeg can handle seeking flawlessly. As I stated, however, if I start at an earlier point, a previously broken scene decodes correctly so I guess the video stream is correctly encoded.

[rack04]

I used the patch from this post: http://forum.doom9.org/showthread.php?p=1397808#post1397808

That is the one that I updated for r1583. Unfortunately it contains a typo that I introduced. Try this (http://pastebin.com/Jf6PeGPb) one instead.

What kind of problem did you find? I noticed that seeking with ffmpeg-mt is VERY slow! It takes a couple of seconds until the video continues playback. Neither MPC-HC's internal filters nor ffmpeg can handle seeking flawlessly. As I stated, however, if I start at an earlier point, a previously broken scene decodes correctly so I guess the video stream is correctly encoded.

I agree that seeking with ffmpeg-mt is very slow. To me it seems that libavcodec is faster seeking. I think most of my seeking problems is related to the last nvidia driver. From what I've read it has issues seeking in mpc-hc when using EVR-CP. I will test earlier drivers to see if this solves the seeking problem.

[moviefan]

Is there a way to check whether your typo broke my encoded stream? I would be glad not to encode again as it takes quite a while...

[rack04]

Is there a way to check whether your typo broke my encoded stream? I would be glad not to encode again as it takes quite a while...

Not that I know of. Pick a smaller stream to test.