<p>Are you using the "Mercury Playback Engine GPU Acceleration (CUDA)" as your renderer inside of media encoder? I've read about and had a few cases where software only rendering can cause similar issues.</p>

CC BY-SA 3.0
2016-05-16T13:59:20.417Z
So @NataliePi was on the correct track. I ended up poking a few other buttons the next day and, on a hunch, switched off CUDA-accelerated encoding. Boing, black frames gone.

I'm working from a 2014 MBP Retina, which has dual graphics chipsets (Intel Iris Pro and Nvidia GeForce 750M). Since the results so were so consistently happening about halfway through the video, and *only* on frames being recompressed from original source, I wondered, as Natalie did, if it was a graphics card issue.

Switching to CPU-only solved the problem.
snomsnomsnom
CC BY-SA 3.0
2016-05-16T14:02:30.997Z
I'll reconfirm the issue when my Akitio eGPU box arrives (along with my shiny new GeForce 1070 in June) and have the firepower to determine if it really was a VRAM, or CUDA-related issue.
snomsnomsnom
CC BY-SA 3.0
2016-05-15T12:08:09.223Z
2016-05-15T12:08:09.223Z
NataliePi
<p>My suggestion would be to forget the idea of exporting a Quicktime from Premiere using the H.264 Codec. The reason? Because it typically doesnt work. </p>

<p>The only sure-fire output module for Quicktime is the Animation codec; which will result in very very large files, if you export at 100% quality (essentially uncompressed) and especially so if you use an Alpha Channel. </p>

<p>Is there any reason why you need Quicktime as your actual wrapper?</p>

<p>I would highly suggest using:</p>

<p>Format: H.264  (Not Blu-Ray just H.264). </p>

<p>Setup the output to match your desired settings. </p>

<p>Set a target bitrate to meet your needs (for BluRay quality 1080p = 30mbps on average). </p>

<p>ALWAYS use CBR. Avoid VBR at all costs. Why? 1.) Time, VBR takes a lot more time, especially on a two pass. 2.) VBR will cause artifacting on fast flashes, such as a camera flash going off in frame, or just a white flash you've added in. The VBR engine first scans your video to approximate how to apply the bitrate frame by frame. When a camera flash is encountered (the frame goes near to all white), the preceding and following frame will suffer, because Adobe's algorithm for computing the adjustment will not adjust fast enough. It will drop your VBR very low for the white/black frame, but not ramp back up fast enough before or after that frame (which requires little if hardly any bandwidth). </p>

<p><strong>CBR will ALWAYS give you a rock solid consistent output quality.</strong> </p>

<p>**So; as far as the black frame drops, forget Quicktime. Forget Quicktime forever, unless you require lossless output with an alpha channel using the Animation codec- never use Quicktime again. Instead:</p>

<p>Output as format: H.264 with the extention <strong>.mp4.</strong>  After you have rendered out, if your <em>client</em> wants or demands an MOV file... - just change the extension to .mov and don't tell them. They will never know, the difference. Nor will any application they use to read the file see that it wasn't output using QT.  It's H.264.  The extension does not matter. Rename to .mov and boom it's now QT. </p>

<p>Simple as that. Remember Quicktime is just the wrapper - and a terrible one at that. H.264 is the codec. If it's H.264 they want, its H.264 you'll give them. It makes no difference if you name it movie.mp4 vs movie.mov. </p>

<p>So give that a shot, and I think your black flashes will be gone. </p>

<p>Again, the only valid use for Quicktime is the Animation output codec, which is great. Other than that, Quicktime is a dead format tied to a long dead OS. </p>

<p>The only time I ever use QT is in After Effects, for output of all comps before taking them into PPro for H.264 mastering. That is the only time I --ever-- use it. </p>

<p>Give it a shot. </p>

CC BY-SA 3.0
2016-05-15T16:36:45.073Z
This doesn't address the OP's problem, since it happens even when exporting to MXF in a different codec.
Gyan
CC BY-SA 3.0
2016-05-15T16:44:15.330Z
He stated:  "I need to export to a quicktime wrapper around some sort of mpeg-4 codec; I've tried several configurations of H.264 and MPEG-4 with the same result."       I told him what I would try. Forget the wrapper. Get the H.264 out. then just name it as an MOV.   MXF is even more problematic.
McFlySoHigh
CC BY-SA 3.0
2016-05-15T16:45:51.387Z
Looking at his settings, also, there is no need to add keyframes every 1 frame. Add a keyframe every 30 frames. More than enough for seeking.
McFlySoHigh
CC BY-SA 3.0
2016-05-15T16:55:18.957Z
You missed this - "*I've also verified that the issue occurs when exporting to P2/MXF*". This has nothing to do with the container.
Gyan
CC BY-SA 3.0
2016-05-15T16:13:24.427Z
2016-05-15T16:13:24.427Z
McFlySoHigh
<p>I have a sub-3-minute sequence in Premiere CC, containing a single 4k DCI 23.98 AVC stream from a Sony FS7, with a couple static PNGs and 29.97 Quicktime Animation lower thirds. </p>

<p>I need to export to a quicktime wrapper around some sort of mpeg-4 codec; I've tried several configurations of H.264 and MPEG-4 with the same result.</p>

<p>My timeline plays and looks normal, but after export, I see the following result via Imgur videotogif:</p>

<p><a href="https://i.sstatic.net/KGtlB.jpg" rel="nofollow noreferrer">https://i.sstatic.net/KGtlB.jpg</a></p>

<p>Because I know some of you will ask, here is a screenshot of my export settings:</p>

<p><a href="https://i.sstatic.net/duFTl.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/duFTl.png" alt="enter image description here"></a></p>

<p>Changing resolution, codec (within variants of Quicktime), with/without previews, max render quality - all has no effect on the strobing issue.</p>

<p>Anyone have any thoughts on what the problem might be here?</p>

<p>I'm having the same issue with a visually similar sequence in the same project for the same client, and had it once before as well (you guessed it, same client, same content specs). I've never experienced this ever before so I'm inclined to think there's some little gremlin in there somewhere - but I'm dashed to figure out what it is. </p>

<p><strong>[edit]</strong></p>

<p>I've also verified that the issue occurs when exporting to P2/MXF as well as ProRes.</p>

<p>Per @Mulvya's question about source properties, here's a screencap of the properties window on one of the clips. All the footage was shot in the same session, same camera, etc, and should be completely identical:</p>

<p><a href="https://i.sstatic.net/5sq37.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/5sq37.png" alt="enter image description here"></a></p>

CC BY-SA 3.0
2016-05-12T19:18:09.737Z
What are the source footage properties?
Gyan
CC BY-SA 3.0
2016-05-12T19:29:55.677Z
Edited post with details.
snomsnomsnom
CC BY-SA 3.0
2016-05-13T06:49:03.657Z
Can you export as an image sequence and check?
Gyan
CC BY-SA 3.0
2017-11-30T00:00:54.300Z
I have the same problem, but after several exports, for some reasons, it happens inside premiere now....
Elias Bendix
<premiere><h.264>
Black frame strobing during CC export
snomsnomsnom
# Black frame strobing during CC export

(Asked by: username_0 on 2016-05-12)

I have a sub-3-minute sequence in Premiere CC, containing a single 4k DCI 23.98 AVC stream from a Sony FS7, with a couple static PNGs and 29.97 Quicktime Animation lower thirds.

I need to export to a quicktime wrapper around some sort of mpeg-4 codec; I've tried several configurations of H.264 and MPEG-4 with the same result.

My timeline plays and looks normal, but after export, I see the following result via Imgur videotogif:

<https://i.sstatic.net/KGtlB.jpg>

Because I know some of you will ask, here is a screenshot of my export settings:

[![enter image description here](https://i.sstatic.net/duFTl.png)](https://i.sstatic.net/duFTl.png)

Changing resolution, codec (within variants of Quicktime), with/without previews, max render quality - all has no effect on the strobing issue.

Anyone have any thoughts on what the problem might be here?

I'm having the same issue with a visually similar sequence in the same project for the same client, and had it once before as well (you guessed it, same client, same content specs). I've never experienced this ever before so I'm inclined to think there's some little gremlin in there somewhere - but I'm dashed to figure out what it is.

**[edit]**

I've also verified that the issue occurs when exporting to P2/MXF as well as ProRes.

Per @Mulvya's question about source properties, here's a screencap of the properties window on one of the clips. All the footage was shot in the same session, same camera, etc, and should be completely identical:

[![enter image description here](https://i.sstatic.net/5sq37.png)](https://i.sstatic.net/5sq37.png)

**Tags:** premiere, h.264

> **Comments:**
> **username_1**: What are the source footage properties?  
> **username_0**: Edited post with details.  
> **username_1**: Can you export as an image sequence and check?  
> **username_2**: I have the same problem, but after several exports, for some reasons, it happens inside premiere now....  

---

## 2 answers

### Answer by username_3 on 2016-05-15. Score: 1 | Accepted answer

Are you using the "Mercury Playback Engine GPU Acceleration (CUDA)" as your renderer inside of media encoder? I've read about and had a few cases where software only rendering can cause similar issues.

> **Comments:**
> **username_0**: So @username_3 was on the correct track. I ended up poking a few other buttons the next day and, on a hunch, switched off CUDA-accelerated encoding. Boing, black frames gone.  I'm working from a 2014 MBP Retina, which has dual graphics chipsets (Intel Iris Pro and Nvidia GeForce 750M). Since the results so were so consistently happening about halfway through the video, and *only* on frames being recompressed from original source, I wondered, as Natalie did, if it was a graphics card issue.  Switching to CPU-only solved the problem.  
> **username_0**: I'll reconfirm the issue when my Akitio eGPU box arrives (along with my shiny new GeForce 1070 in June) and have the firepower to determine if it really was a VRAM, or CUDA-related issue.  

---

### Answer by username_4 on 2016-05-15. Score: 0

My suggestion would be to forget the idea of exporting a Quicktime from Premiere using the H.264 Codec. The reason? Because it typically doesnt work.

The only sure-fire output module for Quicktime is the Animation codec; which will result in very very large files, if you export at 100% quality (essentially uncompressed) and especially so if you use an Alpha Channel.

Is there any reason why you need Quicktime as your actual wrapper?

I would highly suggest using:

Format: H.264 (Not Blu-Ray just H.264).

Setup the output to match your desired settings.

Set a target bitrate to meet your needs (for BluRay quality 1080p = 30mbps on average).

ALWAYS use CBR. Avoid VBR at all costs. Why? 1.) Time, VBR takes a lot more time, especially on a two pass. 2.) VBR will cause artifacting on fast flashes, such as a camera flash going off in frame, or just a white flash you've added in. The VBR engine first scans your video to approximate how to apply the bitrate frame by frame. When a camera flash is encountered (the frame goes near to all white), the preceding and following frame will suffer, because Adobe's algorithm for computing the adjustment will not adjust fast enough. It will drop your VBR very low for the white/black frame, but not ramp back up fast enough before or after that frame (which requires little if hardly any bandwidth).

**CBR will ALWAYS give you a rock solid consistent output quality.**

\*\*So; as far as the black frame drops, forget Quicktime. Forget Quicktime forever, unless you require lossless output with an alpha channel using the Animation codec- never use Quicktime again. Instead:

Output as format: H.264 with the extention **.mp4.** After you have rendered out, if your *client* wants or demands an MOV file... - just change the extension to .mov and don't tell them. They will never know, the difference. Nor will any application they use to read the file see that it wasn't output using QT. It's H.264. The extension does not matter. Rename to .mov and boom it's now QT.

Simple as that. Remember Quicktime is just the wrapper - and a terrible one at that. H.264 is the codec. If it's H.264 they want, its H.264 you'll give them. It makes no difference if you name it movie.mp4 vs movie.mov.

So give that a shot, and I think your black flashes will be gone.

Again, the only valid use for Quicktime is the Animation output codec, which is great. Other than that, Quicktime is a dead format tied to a long dead OS.

The only time I ever use QT is in After Effects, for output of all comps before taking them into PPro for H.264 mastering. That is the only time I --ever-- use it.

Give it a shot.

> **Comments:**
> **username_1**: This doesn't address the OP's problem, since it happens even when exporting to MXF in a different codec.  
> **username_4**: He stated:  "I need to export to a quicktime wrapper around some sort of mpeg-4 codec; I've tried several configurations of H.264 and MPEG-4 with the same result."       I told him what I would try. Forget the wrapper. Get the H.264 out. then just name it as an MOV.   MXF is even more problematic.  
> **username_4**: Looking at his settings, also, there is no need to add keyframes every 1 frame. Add a keyframe every 30 frames. More than enough for seeking.  
> **username_1**: You missed this - "*I've also verified that the issue occurs when exporting to P2/MXF*". This has nothing to do with the container.  

---

