Answers.Body: <p>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.</p>
  
  <p>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<sup>8</sup> = 256) with 254 possible values in-between.</p>
  
  <p>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 <a href="https://link.springer.com/content/pdf/10.3758%2FBF03211515.pdf" rel="nofollow noreferrer">optical illusion</a> that causes human vision to exaggerate steps in a gradient).</p>
  
  <p>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.</p>
  
  <p>What can be done? </p>
  
  <ul>
  <li>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.</li>
  <li>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.</li>
  <li>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 <a href="https://en.wikipedia.org/wiki/Dither" rel="nofollow noreferrer">dithering</a>, and will be immediately recogniseable from the days of 8-bit computer graphics, where <em>full-colour</em> images had to be represented with only 256 colours.</li>
  </ul>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-08-08T21:46:18.257Z
Answers.Text: Thank you for such an in-depth answer! Your explanation is the most detailed and accurate, and I believe sums up what is happening with my footage. In the future I'm going to make sure my cameraman is shooting at a higher bit depth.
Answers.UserDisplayName: rolf-the-ganger
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-08-09T01:49:28.863Z
Answers.Text: It's still a limitation of the delivery format most times when you are delivering on the web, and most streaming service. It's like the days when you had to deliver on VHS and you couldn't use bright reds or thin horizontal lines. Yes, I'm that old.
Answers.UserDisplayName: stib
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-08-05T03:08:10.717Z
Answers.LastActivityDate: 2019-08-05T03:08:10.717Z
Answers.UserDisplayName: stib
Answers.Body: <p>I believe what you reference is called "artifacts".<a href="https://i.sstatic.net/LOxOj.jpg" rel="nofollow noreferrer"><img src="https://i.sstatic.net/LOxOj.jpg" alt="See this image as an example."></a></p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>Hope my answer was helpful, happy filming!</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-08-05T02:43:38.017Z
Answers.Text: AVCHD uses h.264 compression, it just puts it into a different container format IOW: It's the same slop, just in a different bucket. On some cameras using AVCHD means that they shoot at a higher bitrate, but h.264 is quite capable of higher bitrates than the limits imposed by AVCHD.
Answers.UserDisplayName: stib
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-07-04T08:23:54.397Z
Answers.LastActivityDate: 2019-07-04T08:23:54.397Z
Answers.UserDisplayName: Florian Claaßen
Body: <p>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. </p>
  
  <p>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. </p>
  
  <p>Here is an example of the problem: <a href="https://vimeo.com/346004760" rel="nofollow noreferrer">https://vimeo.com/346004760</a> (the password is "help")</p>
  
  <p>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?</p>
  
  <p>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:</p>
  
  <ul>
  <li>Switching from GPU to Software renderer</li>
  <li>Removing all effects except dip to black i.e just Dip to Black on pure raw footage</li>
  <li>Using opacity keyframes from 100 > 0 > 100 instead of dip to black</li>
  <li>Rendering the project in every imaginable way i.e .avi, very high bitrates, CBR, playing with every encoding settings</li>
  <li>Cleaning media cache</li>
  <li>Installing an older version of Premiere, downgrading the project, and rendering out of the older version </li>
  <li>Rendering the same footage on a Macbook (I usually work on a PC) </li>
  </ul>
  
  <p>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.</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-07-04T00:25:12.427Z
Comments.Text: I could not see any flickering. If you are watching it on an external monitor via HDMI cable, I suggest changing the cable.
Comments.UserDisplayName: Rusty Core
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-07-04T00:45:24.603Z
Comments.Text: Welcome! Are you talking about the banding around the person? That looks like it might be quantization error, though I don't know what the cause is.
Comments.UserDisplayName: Michael Liebman
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-07-04T16:03:55.477Z
Comments.Text: Thanks @MichaelLiebman! Yes, I'm talking about the banding around the person. I was unaware of this term before and I think it is the proper term for what is happening. I'm going to take a look around online now.
Comments.UserDisplayName: rolf-the-ganger
Tags: <premiere><transitions><export>
Title: Why are these flickering lines appearing during a fade to black in my Premiere render?
UserDisplayName: rolf-the-ganger
ThreadText: # Why are these flickering lines appearing during a fade to black in my Premiere render?
  
  (Asked by: username_0 on 2019-07-03)
  
  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.
  
  **Tags:** premiere, transitions, export
  
  > **Comments:**
  > **username_1**: I could not see any flickering. If you are watching it on an external monitor via HDMI cable, I suggest changing the cable.  
  > **username_2**: Welcome! Are you talking about the banding around the person? That looks like it might be quantization error, though I don't know what the cause is.  
  > **username_0**: Thanks @username_2! Yes, I'm talking about the banding around the person. I was unaware of this term before and I think it is the proper term for what is happening. I'm going to take a look around online now.  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_3 on 2019-08-05. Score: 0 | Accepted answer
  
  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 (28 = 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](https://link.springer.com/content/pdf/10.3758%2FBF03211515.pdf) 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](https://en.wikipedia.org/wiki/Dither), 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.
  
  > **Comments:**
  > **username_0**: Thank you for such an in-depth answer! Your explanation is the most detailed and accurate, and I believe sums up what is happening with my footage. In the future I'm going to make sure my cameraman is shooting at a higher bit depth.  
  > **username_3**: It's still a limitation of the delivery format most times when you are delivering on the web, and most streaming service. It's like the days when you had to deliver on VHS and you couldn't use bright reds or thin horizontal lines. Yes, I'm that old.  
  
  ---
  
  ### Answer by username_4 on 2019-07-04. Score: 0
  
  I believe what you reference is called "artifacts".[![See this image as an example.](https://i.sstatic.net/LOxOj.jpg)](https://i.sstatic.net/LOxOj.jpg)
  
  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!
  
  > **Comments:**
  > **username_3**: AVCHD uses h.264 compression, it just puts it into a different container format IOW: It's the same slop, just in a different bucket. On some cameras using AVCHD means that they shoot at a higher bitrate, but h.264 is quite capable of higher bitrates than the limits imposed by AVCHD.  
  
  ---
  
  