Bug in latest x264?

[ajp_anton]

Was going to start a big encoding project but luckily I quickly noticed some issues with the picture.

I got x264.exe from www.x264.nl, but couldn't find older versions (didn't look very hard), so I used builds from techouse.project357.com for the tests, which appeared to have the same bug.

x264 tested:
r805, r808, r815, r816 (bug only happens in r815+)

Decoders tested:
ffdshow r1870
VLC 0.8.6c (same as ffdshow)
CoreAVC 1.6.5.0 (worse than ffdshow)

Screenshot from r808 and r816 (ffdshow):
http://img174.imageshack.us/img174/6294/r808im4.th.png (http://img174.imageshack.us/my.php?image=r808im4.png)http://img81.imageshack.us/img81/2792/r816nh3.th.png (http://img81.imageshack.us/my.php?image=r816nh3.png)
In motion it looks like there's a keyframe missing. It gets "fixed" suddenly after a few frames, but then slowly starts appearing again.
300-frame sample (http://rapidshare.com/files/106753456/816.mp4.html) (672 kB)

Stripped down the commands until I found that it also happens with the following:x264_816.exe --crf xx -o 816a.mp4 encode.avs
x264_816.exe --qp xx -o 816b.mp4 encode.avs
x264_816.exe --qp 0 -o 816c.mp4 encode.avs

Anyone else noticed anything?

[Dark Shikari]

I actually heard of what might have been a similar issue in #x264... perhaps it could be an error in the border case of the hpel_filter changes?

[Snowknight26]

So it doesn't happen when you specify a bitrate?

[9876]

<<removed>>
Download this anime via emule and try to compress using x264 rev816.....

...It's so terrible :(

Screen corrupted at 0:13 with HQ-Slowest preset.... (megui)

With x264 rev806, it's all ok.

[Terranigma]

Please read the forum rules. :(
Warez is not allowed here my friend. :D

[ajp_anton]

So it doesn't happen when you specify a bitrate?The sample is encoded using 2-pass 1000kbit/s.

[foxyshadis]

9876, if you ever post links to copyrighted material without permission again you'll be struck or banned.

[Dark Shikari]

Its hpel_filter.

09:20 < pengvado> bug is in hpel_filter sse2 and not mmx

[9876]

I think it is just an ED, not include story, so I posted it :(

Sorry

[DanielSun]

818 is released, is this bug fixed?

BTW:where can I get a changelog of x264?

[Dark Shikari]

818 is released, is this bug fixed?

BTW:where can I get a changelog of x264?
changelog (http://git.videolan.org/?p=x264.git)

and yes its fixed.

[Underground78]

I've encoded something with rev. 816, should I encode it again with revision 818 ?

[Dark Shikari]

I've made an encoding with rev. 816, should I make it again with revision 818 ?probably.

[Snowknight26]

changelog (http://git.videolan.org/?p=x264.git)

and yes its fixed.

Speaking of which, I can't seem to find a way to determine what the current revision # is.

[Dark Shikari]

Speaking of which, I can't seem to find a way to determine what the current revision # is.That's because git has no revision numbers; the version numbers come from a script run during compilation.

[Snowknight26]

Thought that was the case. Somewhat inconvenient when I'm trying to pinpoint the changes for a certain revision. Oh well, at least I can compile it to find it.

[bob0r]

When you scroll down on x264.nl, you will read "older versions:"

Mirror05 has the oldest files.

[Sharktooth]

r818 is on megui auto-update.

[CruNcher]

changelog (http://git.videolan.org/?p=x264.git)

and yes its fixed.

not 100% it seems still buggy on AMD64 here
http://s7.directupload.net/images/080413/ji4y7gkq.png
only --no-asm fixes it

AMD64 user with SSE2/SSE3 should be carefull i guess it's better to remove the patch for now until a proper fix is ready

[kumi]

Using r818 (the one in MeGUI update) and a 32-bit Athlon, I am seeing this problem. Currently testing r808...

[Dark Shikari]

not 100% it seems still buggy on AMD64 here
http://s7.directupload.net/images/080413/ji4y7gkq.png
only --no-asm fixes it

AMD64 user with SSE2/SSE3 should be carefull i guess it's better to remove the patch for now until a proper fix is readyActually, its a bug in the MMX version, not the SSE version :p

That's why its fixed on Core 2s, which use a pure SSE2 hpel_filter.

Akupenguin has a fix for it, but he's not committing it just yet because he doesn't know why it fixes it. Until then, if you're on an Athlon, use a pre-816 build.

[kumi]

Thanks for confirming it. I thought I was going crazy, my CPU doesn't have SSE2.

[CruNcher]

Actually, its a bug in the MMX version, not the SSE version :p

That's why its fixed on Core 2s, which use a pure SSE2 hpel_filter.

Akupenguin has a fix for it, but he's not committing it just yet because he doesn't know why it fixes it. Until then, if you're on an Athlon, use a pre-816 build.

indeed wired forceing it to sse2/sse3 fixes it :D

[microcosmos]

I see "more hpel fixes" in revision 819
is that one safe to use on the Athlon64 now?

[Dark Shikari]

I see "more hpel fixes" in revision 819
is that one safe to use on the Athlon64 now?Yes, its finally fixed.

[DeathTheSheep]

Oh my gosh, and here I thought this "trailing gunk" problem was due to me messing something up in the latest revisions... Do you know how long I hunted trying to find out what I could've done to break it? Much loss of sleep, my friend.

Glad it's fixed. Funny though how the "better cavlc" overflow "fix" results in a marginally larger output file with identical ssim and visual appearance (identical frame appearance).

[Dark Shikari]

Glad it's fixed. Funny though how the "better cavlc" overflow "fix" results in a marginally larger output file with identical ssim and visual appearance (identical frame appearance).That's for two reasons:

1. It uses RD scores to weight heavily against possible overflows.

2. It costs more bits to encode an overflow correctly than to clip it (clipping it of course can drastically hurt quality).

[akupenguin]

Funny though how the "better cavlc" overflow "fix" results in a marginally larger output file with identical ssim and visual appearance (identical frame appearance).
If you got your ssim score from x264, that's because it was wrong before. It encoded with the ideal coef value, calculated ssim from that, and then wrote a truncated coef to the bitstream. You must not have looked at the right frame.

[DeathTheSheep]

Ah, that does make sense. I would imagine quality goes up then at cqp--erroneous truncation usually wouldn't go with one's intuitive understanding of 'quality'.