There are more causes for this bug.
The one I've talked about earlier only affects 5D3 and 60D (it appears when changing video modes and recording right away, and I could reproduce it and fix it).
It can also appear if a pink (corrupted) frame appears right when ML is computing the black level (though this one is quite hard to reproduce).
It can also appear because of some Canon code overwriting the raw buffer - remember that raw mode is just a debugging flag written by Canon, but they didn't design it for everyday usage. For example, in 500D, if you take a picture in LiveView and hold the shutter button for a little longer, the raw buffer will be overwritten by LiveView data and the raw zebras will be wrong. This has nothing to do with raw video, but it's a test case that can be reproduced (very useful for testing the fix).
It may also appear because of race conditions (I've tried to avoid it and make the raw backend thread-safe, but I'm not an expert in multithreaded programming, so I may have missed something).
The workaround from MLV (which is enabled by default -
not by me) is incorrect for 5D2 and many other cameras. The pull request removes the workaround and fixes the raw backend properly IMO. It checks the optical black area, so it should also detect bad black levels caused by a pink frame (though not with 100% chances).
On the pull request page, I've listed the relevant tests needed to make sure the fix is portable, and got zero feedback on these for about one week. I simply didn't have the time to do these early tests myself, and without code review and early feedback, I'm not going to include the fix in the nightly builds.
