This project is read-only.

White artefacts at bottom in dark areas with 1.0.1


I upgraded from 0.8.3 to 1.0.1 recently and since then I'm experiencing white artefacts at the bottom of an encoded video, when there is nearly black but still not full black. These white artefacts appear only at the very bottom and sometimes ranges up from there into the video the more dark/black areas there are.

I'm using the H.264 Codec with standard settings, just resizing 1080p videos down to 720p with quality 23. I played around with the settings however with no success, the white artefacts remain no matter which settings I try. I therefore deinstalled 1.0.1 and got back to 0.8.3 - and this issue is gone, all fine again. So these white artefacts surly must be an issue of the newest version.

Anyone else experiencing the same issues?

file attachments


Tekener wrote Sep 17, 2011 at 1:06 AM

Here is a screenshot of the issue, it's no playback issue as I have this on various players/platforms. It's also no issue of the source material, which is clean. And since encoding the same video with 0.8.3 (haven't tried any version between 0.8.3 and 1.0.1) is totally fine it mus be an issue of the newer version.

RandomEngy wrote Sep 17, 2011 at 2:17 AM

This is most likely a HandBrake issue. See . If they fix it in the future I'll pick it up in an update.

b00z3m0nk3y wrote Oct 7, 2011 at 8:32 AM

I get this too, but I've only noticed it on full frame (16:9) Blu-rays, wide widescreen Blu-rays and dvds seem fine. It doesn't seem to be just at the bottom for me, it's in any dark area. Currently using 1.0.4. I've tried both x86 and x64 versions with the same results, the artifacts are always in the same place. Fiddled with every setting and I can't make them go away. Essentially using same settings as Tekener.

This is where it gets odd though, I tried Handbrake 0.9.5 with exactly the same settings - NO artifacts.

RandomEngy wrote Oct 7, 2011 at 4:51 PM

I think this is a regression from 0.9.5 in the HandBrake core. There were some fixes related to this recently so hopefully picking up those changes for the next version will fix this.

b00z3m0nk3y wrote Oct 7, 2011 at 5:55 PM

Thanks for the update RandomEngy, I've been working my way though the versions and the issue seems to have been introduced with version 1.0. Looking forward to the next release of this great tool!!!

RandomEngy wrote Oct 7, 2011 at 6:41 PM

Just to remind you, I can't fix this bug myself! It's not in code that I own: if you want it fixed I suggest you test on HandBrake and ask them to fix.

b00z3m0nk3y wrote Oct 7, 2011 at 8:03 PM

No worries, I understand that. I meant that hopefully the issue will be resolved by the recent Handbrake fixes and picked up in any new versions you release. Thanks again.

sundance wrote Oct 12, 2011 at 8:42 PM

I'm quite sure it's a HandBrake issue; I tried the latest version of it (svn4279). I already reported the bug at their forum ( and attached a screenshot (this BD is NOT a full frame). The last VidCoder version WITHOUT that problem was 0.9.3 (Handbrake svn4103)

sundance wrote Oct 17, 2011 at 8:53 AM

Since Handbrake svn4291 (Oct 15), the reported VC1 decoding issue discussed here should be solved.
Is it safe to just replace the hb.dll shipped with VidCoder v1.1.1 with the latest Handbrake release ( or do we need a complete VidCoder update?

RandomEngy wrote Oct 17, 2011 at 4:43 PM

You're going to need a VidCoder update (or at least a HandBrakeInterop update, which has not happened yet). They changed some stuff with the structs that requires an update there. I'm actively working on the next version, though it may be a week or so as I'm doing significant refactoring around adding FLAC and automatically determining appropriate bitrate ranges.

sundance wrote Oct 19, 2011 at 8:15 PM

Affirmative: Just tested my Hannibal sample clip with the latest version of Handbrake (svn4297) with the VC1 decoding bug fixed - flawless encoding - artefacts gone! Thanks to the Handbrake/libav devs for the fix!

sundance wrote Oct 19, 2011 at 8:20 PM

Unfortunatelly, there still is another libav bug in the VC1 decoder that produces random blocks (see: looks like we'll have to wait another round...