Hey there. Yesterday I had problems with video playback. I’m using 2.4.0 stable, in rehearsal I was checking videos and everything went in sync, but after few hours when broadcast started, videos went out of sync, around 2-4 seconds difference.
After broadcast we did a test and restarted CCG and video came back to sync, what causes could there be?
Before restart I’ve tried mp4 (h264) and mov (proress 422) both were going out of sync.
After this one sure I will. But what could cause this thing? And from your experience how do you deal with deembedder which signal do you feed fill or key? Because AFAIK it gives atleast one frame delay or no?
The drift between video and audio when using decklink and system audio is the lack of clock locking between the two consumers. The 25Hz and 30Hz frame rates have an integer number of audio samples per frame, the 29.97Hz style frame rates use an integer number of samples per 5 frames. The audio thus exactly tracks the decklink video master clock and stays in lip sync on embedded output.
System audio accepts audio at a nominal 48 kHz clock frequency, but this is a free running clock not locked to the clocks in the decklink - hence the potential for drift. If the system audio clock is very slightly slightly lower than 48kHz, an input buffer slowly fills making the audio lag. If the system audio clock is very slightly higher than 48kHz the buffer will empty and some occasional clicks can be heard.
I tested several models of de-embedders a few years ago, and the audio delay relative to video was very small, typically 2ms for analogue audio output, maybe slightly less for AES output.
By the way, guys @didikunz, @andyw. Now I thought that in case there is no de-embedder in studio or I left my own, maybe then it’s possible to use NDI consumer and de-embed sound from it, in that case I guess Decklink output and NDI output would go in sync?
The thing is, that such “solutions” work sometimes and sometimes not. That is why I try to do it the proper way, if possible. If something goes broke one can use it’s creativity to find such workarounds. But that is an emergency then
I have never tried to use NDI and Decklink consumers on the same CasparCG channel, so I can only make a guess - which is the NDI stream will be self consistent and should maintain intra stream audio-video sync timing - but this is very unlikely to have the same delays as the Decklink card so relative audio timing from both routes may be both offset and drifting.
Here are a few lines from server V2.4 newtek_ndi_consumer.cpp. The comments after the auto buffer_size line suggest there may be some extra delays on the NDI route:
send_thread = boost::thread([=]() {
set_thread_realtime_priority();
set_thread_name(L"NDI-SEND: " + name_);
CASPAR_LOG(info) << L"Starting ndi-send thread for ndi output: " << name_;
try {
auto buffer_size = buffer_.size();
// Buffer a few frames to keep NDI going when caspar is slow on a few frames
// This can be removed when CasparCG doesn't periodally slows down on frames
while (!send_thread.interruption_requested()) {
{
std::unique_lock<std::mutex> lock(buffer_mutex_);
worker_cond_.wait(lock, [&] { return buffer_.size() > buffer_size; });
graph_->set_value("buffered-frames", static_cast<double>(buffer_.size() + 0.001) / 8);
buffer_size = buffer_.size();
if (buffer_.size() >= 8) {
break;
}
}
}
// Use steady clock to generate a near perfect NDI tick time.
auto frametimeUs = static_cast<int>(1000000 / format_desc_.fps);
auto time_point = std::chrono::steady_clock::now();
time_point += std::chrono::microseconds(frametimeUs);
Somewhere I have a simple 1080i50 test video which I designed to test A/V sync through systems. It is a few seconds duration and easy to loop. The vision is several frames of black (I think it was 24 frames) followed by a single frame that is mostly black except for a few tv lines line high white bar across the width of the screen. A few cycles of audio tone happen at the same instant as the video bar. When I find that signal (it may take a few days) I’ll make it available and post a link in this thread. We used the signal playout plus an oscilloscope to show the video and audio waveforms.
It is quite easy to create other scan standards using a simple audio program to make the audio blip (eg using Audacity) and a graphics package to create the white bar, combining the result in any video edit package. Import feature is the test signal must use an intra codec to ensure source AV sync is correct.
The audio/video sync test signal is available here.
The signal is encoded using 1080i50 scan format using ProRes LT intra frame codec. The AV test elements are present on evry 10th frame, the intermediate frames are black. To test longer delays use any suitable video editor to insert extra black frames.
And yes I know it says 60s in the file name but it actually has 70 seconds of content.
The what?