VUC515 & A Couple of Observations About YouTube

Dual-Dell-Monitor.jpg

Last week’s VUC515 with Tsahi Levent-Levi was a great call and a fine example of why the VUC continues to garner audience. Kudos to Randy, Tsahi, Tim, Emil at the cast of several who brought it about.

Dual-Dell-Monitor

The production of the call was a bit unusual. Further, it’s post-call existence is continuing that trend line. In the moments just before the call YouTube decided to ignore the video stream that I was sending from Wirecast. When this has happened in the past stopping & restarting the stream once or twice has resolved the matter.

On this occasion, nothing that I tried could make YouTube acknowledge the stream, so we resorted to abandoning the YouTube Live event, making a local recording instead. That local recording was later uploaded to YouTube.

We use Wirecast in production of VUC calls in one of two ways;

  1. When the call is hosted using a Google+ Hangout we use Wirecast to insert the opening sequence into the call. The connection between the Hangout and YouTube is handled entirely by Google.
  2. When the call is hosted using Jitsi Video Bridge we use Wirecast in a more comprehensive manner. It inserts the opening sequence, but it also captures the JVB session and sends that stream to a YouTube Live event. This is necessary since there’s no direct connection between JVB and YouTube.

The result is that a call hosted on JVB places a greater burden on my production PC. I suspect that the manner in which I’ve been configuring my desktop for VUC calls via JVB is sub-optimal. During last week’s call the CPU usage, which is shown in Wirecast, was in the 80%+ range for the entire call That was with the stream to YouTube disabled, but local recording engaged.

A little recent experimentation seems to indicate that YouTube is sensitive to the timing of streams for live events. My current desktop simply may not be fast enough to reliably do the event on its own when it’s using the Local Presenter aspect of Wirecast to capture the second monitor’s display of the JVB session.

To quote Leonardo Da Vinci from a 1973 appearance in a Caramilk commercial, “I thought this might work, but I need more time. More thought.”

In truth, I have an idea of how to split the work between two systems; use one system to join the Jitsi Video Bridge, then pipe that output of the system into my desktop using an HDMI connection. It will take some experimentation to get the audio working correctly.

VUC515-in720P60

The recording captured locally was in 720p30. However, once it was uploaded to YouTube I see that it was converted to 720p60. I have to wonder why they bothered? The source material was p30 and in fact, just barely p30, given the aforementioned workload of the PC that was making the recording.

In fact, the 720p60 playback streamed from YouTube seems to show some nasty motion artifacts. These were very obvious to me in viewing the opening to VUC515. The cross-fades between the sponsor logos should be smooth and fluid. They appeared awkward and flickery, so does much of the payback when streamed online.

Moreover, what might be the benefit of talking heads in p60? Zero. Nada. None. It’s pointless from a viewer perspective. It’s primarily beneficial for video that contains fast movement, like video gaming, sporting events or concert videos. I wonder why Google thinks that P60 has any value for common YouTube Live events or Hangouts?

Update (11/26/2014) –  this afternoon I happened to revisit the YouTube recording of this call. YouTube no longer offers the 720p60 variant that I found so troublesome. Now the best that they offer is 480p. That’s a little disappointing given that we did send them a 720p30 stream. At least it indicates that they’re still tinkering with the new p60 capability, even f they’re doing it in their typical, completely opaque, Google style.