ATEM Mini Pro cache

Questions about ATEM Switchers, Camera Converter and everything live!
  • Author
  • Message
Offline

mtbills

  • Posts: 5
  • Joined: Fri Sep 11, 2020 3:26 am
  • Real Name: Matthew Bills

ATEM Mini Pro cache

PostWed Sep 16, 2020 9:17 pm

We are attempting to stream from our ATEM Mini Pro directly to YouTube. Unfortunately, we have run into an issue in which our cache fills up quickly, thus compromising the quality of our stream.

Reading through the forums, it seems that users have two different conceptions of what the cache does. Which of the following is the cache used for:
(1) Storing raw audio & video while waiting for it to run through the H.264 encoder
(2) Storing encoded video while waiting for it to be uploaded to YouTube
(3) Both
(4) Something else entirely

The manual seems to suggest that the answer is (2), but a couple different users have reported fixes (at least for them) that suggest that the answer should be (1) or (3).

Getting this question definitively narrowed down would help focus our troubleshooting efforts. Thanks for any wisdom you can share!
Online

Dave Del Vecchio

  • Posts: 962
  • Joined: Mon Nov 25, 2013 10:25 am

Re: ATEM Mini Pro cache

PostThu Sep 17, 2020 5:35 am

I would guess that the answer is probably (2), although you could probably test this by doing a local USB-C recording while streaming and see if the local recording is affected when the cache fills up and the internet stream quality is affected.

If you are just doing live streaming without local recording, then I'm not sure that it really matters where the caching is done. If you consider the video processing pipeline when streaming, it might look something like:
uncompressed video frames -> H.264 encoding -> sending encoded video to streaming destination

So if the bottleneck is the last step of actually sending the encoded video out over the internet, this is going to cause the cache to fill up regardless of where it is inserted in the processing pipeline. Since the H.264 encoder is a hardware implementation, I'm pretty sure that it is capable of keeping up with live encoding up to 1080p60 video, so any caching is to deal with network problems not the H.264 encoder speed.

Note that if you get into the details of the H.264 encoder, I'm sure that this is a highly simplified model of what is actually happening internally, as typically with interframe codecs like H.264, there are probably multiple frame buffers in use, since you there are multiple frames (often multiple seconds worth of frames) between each i-frame that is compressed in it's entirety (without relying on previous frames). H.264 also has b-frames which can have dependencies on both earlier and later frames in a sequence (until the next i-frame). This is part of the reason why H.264 encoders introduce some latency, as they need to buffer a certain amount of video data to do this type of compression.

Anyway, for most purposes you can probably treat the H.264 encoding engine as a black box with a fixed amount of latency, so it gets uncompressed video data going in and spits out compressed video data at the other end after a fixed amount of latency. Since this latency is constant and remains the same while the H.264 encoder is running, you don't really have to worry too much about it (at least from a caching perspective anyway).

This is different from network related problems due to bandwidth or latency which can vary over time due to the nature of internet delivery.

Return to Live Production

Who is online

Users browsing this forum: ashveen, Darren B. Kelly, Dave Del Vecchio, Gary Adams, Majestic-12 [Bot], Rickett and 22 guests