Why are these flickering lines appearing during a fade to black in my Premiere render?

Question

I am working on documentation of a performance/musical instrument design project I completed in the springtime. The footage I received from my cameraman was shot on a GH5, and it's technical specs are 23.976 fps, 1920x1080, and H.264 10 bit 4:2:2.

I have completed my edit in Premiere and used a couple of "Dip to Black" effects as transitions between different moments of my performance. Everything looked great and I rendered the project out. After watching the render, I noticed that on every fade to black transition, a bunch of flickering lines would appear on the white wall behind me.

Here is an example of the problem: https://vimeo.com/346004760 (the password is "help")

Does anyone have any clue as to why these flickering lines are appearing during fade to black transitions? How could I get rid of them?

I've spent the past two days trying to find a solution, to no avail: the problem continues to appear. Aside from countless hours of Googling, here is a list of things I have tried:

• Switching from GPU to Software renderer
• Removing all effects except dip to black i.e just Dip to Black on pure raw footage
• Using opacity keyframes from 100 > 0 > 100 instead of dip to black
• Rendering the project in every imaginable way i.e .avi, very high bitrates, CBR, playing with every encoding settings
• Cleaning media cache
• Installing an older version of Premiere, downgrading the project, and rendering out of the older version
• Rendering the same footage on a Macbook (I usually work on a PC)

I did learn that I can replicate the issue just by setting In and Out points on the timeline and rendering inside Premiere i.e by going to Sequence > Render In to Out. The flickering lines then appear when I preview the timeline. They do not appear if I haven't pressed "Render In to Out". This cut my troubleshooting time down considerably, as I didn't have to keep exporting footage.

Answer 1

That looks like banding. Banding is where subtle gradients run into the limits of the bit-depth in the codec, often amplified by artifacts from compression.

Imagine that you have a gradient of tones from the brightest possible white, to the darkest black. In 8-bit image (we'll use a greyscale example to simplify) this means the black pixel is at 0, and the brightest pixel is 255 (2⁸ = 256) with 254 possible values in-between.

If your gradient is more than 256 pixels long on screen, then there aren't going to be enough possible values to give each pixel a unique value. Imagine that the gradient went over the entire screen. In a HD picture this would be 1920 pixels that you have to colour with only 256 possible colours. So the colours will have to repeat - roughly 8 pixels will have to share each value. This means you get bands of colour 8 pixels wide, which will be obvious to viewers (making matters worse is the fact that there's an optical illusion that causes human vision to exaggerate steps in a gradient).

Why you notice it even more during fades to black is explained by thinking about what happens to our 0 - 255 gradient as it gets faded out. Halfway through the fade the brightest pixel will be half as bright as it was, meaning our gradient now only goes from 0-128. So now the bands will now be 16 pixels wide, and as the levels get crushed down towards 0 they keep getting wider. This is a fundamental limitation of digital imaging.

What can be done?

• Shoot in 10, 12 or 16 bit, if you can. This usually means using a more expensive camera, and doesn't help for final delivery where you often need to compress to 8-bit 4:2:0.
• Using log profiles can help cheat some extra depth in mid tones at the expense of loss of detail in bright and dark areas, and an increase in noise and compression artifacts.
• adding noise. This is counterintuitive, but what noise does is to break up the hard edges of the bands making them less noticeable. This technique is called dithering, and will be immediately recogniseable from the days of 8-bit computer graphics, where full-colour images had to be represented with only 256 colours.

Answer 2

I believe what you reference is called "artifacts".

Those phenomenons are a result of compression. Vimeo does not use the raw file you upload as playback. Instead, the file is converted and compressed for storage-purposes mainly. This might be one reason as of why this is appearing.

The second possibility is that your footage was not recorded at a deep-enough bitrate, and so it seems from the information you gave. h.264 is always a lossy codec, which means that you're gonna throw away a chunk of data when writing a file in h.264. I know that the gh5 is able to record in avchd, which would be a far better choice in terms of image quality compared to mov h264 or mp4 h264. Try recording in that format.

Lastly, using a flat profile could safe you some extra-information in those parts that get compressed could help you. The gh5 has a vlog-L profile as well as a Cinelike D one. These are so called "flat profiles" which will lower the contrast and saturation at first, but give you the ability to adjust contrast and brightness afterwards. Recording in a flat profile captures more information in very bright or very dark areas, which would otherwise get lost. Trying this might also improve your results.

However, Vimeo, youtube, Clipfish, hell what ever Streaming-Service you use - compression will take place, which means that your video will look worse there than in the original file. Depending on what you're planning on the long run (for example sending a video to a client) it might be a better idea to straight up upload the prores4444 or DNxHR or similar near-lossless codec and send the link to the client (for example via ftp-server) so he/she/it can download it directly without the use of 3rd-party streaming-services.

Hope my answer was helpful, happy filming!