So this is a really weird issue… We are running Mimo on the latest iMac non M1 iMac
Radion Pro 5700 XT w/ 16Gigs Vram
64 gigs of DDR4 Ram
Pretty good machine… For video input we are running a PCIe Expansion box over thunderbolt with two Blackmagic Decklink Pro 8K SDI cards… We also have a Blackmagic Genlock mini box that we are running into the ref in on the cards and into the genlock in on our cameras… We are running audio in from a mixing board into an XLR boot on one of the cameras… So in theory its kinda impossible for the audio to be out of sync
Everything is on the system says genlock is functioning properly and when we record to disc on the computer its in perfect sync…
But for whatever reason when we stream to YouTube the video is 1.5 frames early… Which is crazy… Switching to any camera keeps the same offset…
We tested the sync by download the video from YouTube and lining it up to a clap so there was not an offset from YouTube starting the stream… and the video is consistently 1.5 frames early…
We tested putting the cameras in drop frame and changing our entire frame rate from 29.97 to 59.94 and no luck with anything…
And since the issue is not happing on the local video out put the issue has to be coming from the encoder for the live stream…
Anyone had this issue? I have never seen anything like it…
Hi @actionTurtle Sorry for the troubles and thank you for spending all that time troubleshooting this.
If the local recording is perfectly in sync, the stream output from mimoLive should also be in sync as it is the same data we are sending to the encoder.
YouTube does re-encode the video you send to it, so the data you download is not the same as the one sent out from mimoLive. Do you know your way around FFmpeg? If so, it would be easy to set up a local RTMP server that simply receives the output from mimoLive and saves it into a file and check the offset there. I will try to think of a setup that could replicate this here, but I don’t have the genlocked source. For me personally, 1.5 frames is perfectly acceptable, but I understand that you have other requirements.
@actionTurtle I just did a test with streaming from mimoLive via RTMP to a local ffmpeg recording to disk and don’t see an audio/video delay, but of course I used a different system and a very basic test file.
You can replicate this by following this:
- Install FFmpeg via Homebrew
- Start a local RTMP server that saves the incoming video to a file by using this command:
ffmpeg -listen 1 -i rtmp://127.0.0.1:1935/live test.mov
- Use a Live Streaming output destination for streaming to your local server. Use this in the “Streaming Server” field:
BTW, mimoLive has a special A/V Sync Source to provide a test signal.
Let me know if there is a delay in the test.mov file.
Yes, YT has a significant audio drift within the reencoding procedure: This video is very interesting (not only because of the drift);