What On Earth Happened On NASA’s JWST Live Stream?

After decades of effort and delays, NASA finally launched the James Webb Space Telescope - and after a very delayed White House briefing (with excellent pre-stream music ), we saw its very first science image . Spectacular! The next day, the next four images were shared with the public in a highly-publicized NASA livestream. That stream looked like what it might have felt like if the JWST failed to fully unfold and become a failure of a mission.?

I’m writing this article to educate and prepare future live-streamers - not because I want to publicly bash the NASA production team. There are many reasons for a stream to look like this - low budget, limited crew size, tech issues, lack of producers, lack of preparation time and rehearsals. I don’t know how many of of these were in play - but I will try to break them down. Also - a lot went great in the broadcast! It's just harder to call that stuff out, and it's not the focus of this article. The one thing I'd like to point out is how great the host was. Michelle Thaller worked through all of the tech and production issues in a very professional manner.

To be clear - as someone who has produced and directed live streams for clients big and small, I have made many (if not all) of these mistakes myself! If you’re curious… shoot me a message. I’ve never lived down a production I did for a page with over 50 million followers - that never saw the light of day. I have over a decade of experience in broadcast and live streaming at different scales, so I've seen all sorts of things go wrong and right.

So - let’s get started.

Issue #1 - Transmission - Freezing and Skipping Video broadcast

If you were watching on the official NASA YouTube stream , you would have noticed how much the video was skipping and pausing. Some of this happened while the stream was active, and there were moments where it looked like the signal to YouTube was lost altogether.?

Why might this happen? My theory is that the encoder they were using to get the final line cut to YouTube wasn’t powerful enough. I would guess they were using a capture card into a computer and streaming from a computer. They likely weren’t using a hardware encoder. The way it was skipping and freezing looked exactly like a stream that was being broadcast from a device with low or no remaining CPU or GPU. There is no easy way to fix this in the middle of a broadcast without doing troubleshooting that might cause a bigger problem on the computer - or restarting the computer and the stream altogether. It’s also possible that the encoder didn’t have enough internet - but I’d put my money on limited processing.

This is an issue that just might not have come up before in a rehearsal. Internet conditions change, computers have been on for extended periods of time, or the encoder just wasn’t in the mood.

If you watched other streams, the feed was crystal clear. This leads me to think that there was a pool feed on-site that other broadcasters were using to stream their own versions of it. They could use any kind of encoder - including bonded cellular - to get the signal back to their master controls or to stream directly to the internet. You can see PBS’s perfect stream here .?

Issue #2 - Remote Contribution

The stream featured live shots from many locations - from simple viewing parties to longer segments from other parts of the country and the world.

After a weird delay trying to toss to the Canadian Space Agency, they played their loud and too long locator video. This could have been intended to soften delay between locations. Ultimately, they cut to what seemed like the wrong shot because someone started talking that wasn’t on screen. And then, an overlay popped up on screen that showed that they were actually attempting to use a YouTube stream as the “video call” transmission, which is ill-advised. You never want to be at the mercy of YouTube’s latency - as a broadcaster and as a viewer, or in this case, as the second side of a call. YouTube delays can range from around ten seconds to nearly a minute. That stream also froze and had a “loading” loop - it’s unclear if that was a broadcast issue from Canada or at NASA. The freezing was not dissimilar to what viewers experienced on the NASA stream. The producers were smart and had another expert in-person in case of issues. Even though she was on-site, her audio took a while to come up properly, and then we heard the audio get very airy and heard some unknown people whispering in the background.??

When they tossed to their Baltimore location , the Baltimore guest started talking early before the locator video was done playing. Perhaps that was a choice by the producers as it happened multiple times throughout the stream - but it generally felt like a mistake. I'd guess there wasn't a lot of rehearsal of these tosses.

Similarly, when one of the remote guests tossed to a video clip , the clip played very early and on top of her intro.

Shortly into the broadcast as the host is introducing some future guests, the program video (on a delay) is fed into the background monitor, which included the audio from seconds earlier.

When the host is saying hello to some of the viewing parties (seemingly over a zoom-like transmission), the host's audio started repeating - which I had thought was noise cancellation issues typical with a large auditorium speaker system. This happened for every group they introduced, and the remote audio was never used (which would have been natural to hear). Getting audio from that many individual sources is a challenge - though I think it's possible they used some sort of pinning feature in Zoom to make these switches. That would have kept all the audio on a single channel, and may explain why the host's audio was acting weird for the whole segment. It also makes me think that the reason that the program video was visible in the background was that the pinned video WAS the program video, which explains the very short latency. When she tosses to Perth, Australia - it seems like the TD tried to bring up the Zoom call full-screen, but because it was pinned to Program, we saw video feedback / freezing.

The lighting at the viewing parties left a lot to be desired. See below for a few examples. It's hard to get lighting right in large spaces like that if they have a projector fighting the bright room to be visible - but for the sake of the broadcast, the full house lighting should have been turned on for the pre-planned moments they'd be on the stream.

The lighting also wasn't great at one of their more prominent locations. I actually think this was an iris / exposure issue. It's likely that there wasn't an assistant director or someone to look at shots before they went to air. If there was a single operator running the main mix, it would be hard for them to look ahead when they have to focus on what they're currently working on.

There was also weird compression / break-up on this segment . This makes me think they were using some kind of video call platform like Zoom, rather than direct satellite or SRT or bonded cellular connection. For a production at this scale and for a segment that important, consumer applications just aren't the right tool for the job.

Issue #3 - Audio

There were two main issues with the stream’s audio - the mix that went out to the public, and the mix-minuses that let the host, producers and remote contributors hear each other and interact. These two things are intertwined - because the same original audio signals are the ones that get used for both purposes.?

My theory is that the audio for both things was done by a single person. For a stream of this scale, with that many two-way sources, that’s a lot to pay attention to and get perfect. They could have had a separate audio operator for the stream and for the internal mix-minuses and IFBs.?

From the way I heard sources mute and unmute, and from how relative audio levels felt off and took a while to fix and balance (if at all), I would guess that there wasn’t even a physical audio mixer, and that all audio was mixed in the control room hardware/software. I’d guess they used something like a TriCaster or VMIX. Hard to really know though - it could just have easily been a physical mixer. If it truly was software, it is very annoying to have to use your mouse to click small mute/unmute buttons, and imprecise to use your mouse to raise and lower levels.?

The host’s very first words were cut off as the broadcast started. I’ve done that a million times as a solo operator - there’s just so much to deal with at the top of a show, including cueing if that’s also your job. I see it happen a lot in solo operator productions - not so much when there’s a dedicated audio operator.

Seconds later , when her first guest starts talking, his mic is not on and is only heard through the host's mic. It took a little over five seconds for his mic to come up. It sounded like the audio faded in, which makes me think it may have been a physical fader being brought up.

The bump / transition music they used to go from segment to segment and guest to guest was generally loud - which makes me think it was at a "set it and forget it" level. Also, at least once, it cuts off quite abruptly. The transition was probably played by the TD and not a separate video playback operator. That specialization in job responsibilities would likely have stopped this from happening.

There were definitely IFB problems. One in particular we heard because while the host thought she was muted, she mentioned it . Without a dedicated operator, it's very easy for feeds to get left on for the IFBs.

In general - it just feels like there wasn't enough rehearsal to identify and resolve these issues prior to broadcast.

Issue #4 - General Production - Directing/TDing and Camera

Based on how the production was cut and how background elements appeared, I would guess that this was a single-operator production. One person that's both calling the shots and punching them, for both the stream and the background. It takes a lot of skill to do it right - and if there are other issues out of your control, things start to spiral.

This was most notable when the program feed ended up in the background monitors multiple times throughout the production. As mentioned earlier, I think this was a quirk of how they were doing caller contribution.

Based off the audio issues and timing on video playback and lots of other weird directing choices, I think that there was just too much on the plate of what I think was a single operator. I wouldn't be surprised if the director was also doing the talent cueing.

Camera work was also somewhat shaky at times . I'm not sure if they had a Steadicam or a similar rig - but it looked very shaky and handheld when they weren't on locked-off shots. I actually think they may have been using a jib for shots that it's not truly meant for. This could as likely be user error as much as equipment issues.

There were also times where the host was addressing what seemed to be the wrong camera . This blocking may or may not have been discussed in rehearsals.

Set-wise, I'm not sure if this is a permanent set or if it was built for this purpose. I liked the look - it fit the feel of the stream and the content quite nicely. Unlike the White House conference which was criticized fairly for not immediately showing the full screen high resolution images, the NASA broadcast went full screen right away. And took advantage of a monitor wall to keep the images up on more of the screen for more time.

That said - for a production about amazing looking photos and resolution and clarity, I would have preferred not to have breaks in the image on multiple TVs. If they used a bigger TV or were closer to the image on a single TV, we would have gotten the same idea with less breakup. A monitor wall like they used at the White House would be preferable for this kind of event, but those are expensive and I understand why they didn't have it!

The last production decision I didn't understand was the progress bar. Possibly inspired by the status image on SpaceX launch streams , the host told us that this bar would tell us where we were in the broadcast and what was coming up next. But when it was first introduced , as soon as the host said it was at the bottom of the screen, it disappeared. It rarely showed up through the broadcast. It didn't have that much value to the viewer.

Conclusion

As I mentioned earlier, a lot went right, but a lot went wrong for the audience to see and hear. I think that they likely needed a larger crew, more rehearsal, and a better understanding of the technologies they were using for the production. The bottom at line is that I had higher expectations from NASA when they were showing off some of the most impressive photos ever taken.

The easiest thing they could have done to improve the stream would have been to record most of it, make fixes and edits, and then stream that and intermingle it with parts of the production that truly had to be live. The viewing parties that showed up on screen detracted from the experience, and were pretty much the only parts that truly had to be live. Apple has done a great job with their pre-recorded keynotes - NASA and other productions should take note. It's exciting to be live - but unless there's a reason to be truly live (newsworthy or interactive), it's generally cheaper, easier, and more reliable to pre-record the show. While this stream was newsworthy from the photos it was premiering - nearly all of the discussion about them was done by small groups of people with no audience.

What were your thoughts about the broadcast? About my critique? Let me know in the comments!