Remix.run Logo
amluto 8 hours ago

> do time sync by having A/V sync and good clocks on each device and aligning based on audio loud enough to be recorded by all devices

Why do you need good clocks? For audio, even with simultaneously playing speakers, you only need to synchronize within a couple of ms unless you need coherence or are a serious audiophile. If if want to maintain sync for an hour I suppose you need decently good clock.

But as long as you have any sort of wire, basically any protocol can synchronize well enough. Although synchronizing based on visual and audible sources is certainly an interesting idea. (Audio only is a completely nonstarter for a sporting event: the speed of sound is low and the venues are large. You could easily miss by hundreds of ms.)

> then mix, reencode and distribute on normal GPU-equipped datacenter servers using GPU acceleration

Really? Even ignoring latency, we’re talking quite a few Gbps sustained. A hiccup would suck, and if you’re not careful, you could easily spend multiple millions of dollars per day in egress and data handling fees if you use a big cloud. Just use a handful of on-site commodity machines.

rezonant 36 minutes ago | parent | next [-]

> Why do you need good clocks? For audio, even with simultaneously playing speakers, you only need to synchronize within a couple of ms unless you need coherence or are a serious audiophile. If if want to maintain sync for an hour I suppose you need decently good clock.

There are many microphones involved in a production, and humans are quite good at detecting desync between audio/video when watching a presenter talk. You cannot fix desynchronization further down the chain if the desynchronization is variable for each source.

pjc50 6 hours ago | parent | prev [-]

Frame sync. In order to reduce latency, these systems tend to be unbuffered, which means that the frames have to arrive at a very specific time, and you can't afford significant jitter or (worse) phase drift. If you have one source at 25.000FPS and one at 25.001FPS eventually you're going to be a frame out between them.

geerlingguy 6 hours ago | parent [-]

Surprisingly, the timing requirements for digital seem to be slightly lower than it was for analog, at least if I heard the engineer correctly on site. It was something like 1.5 microseconds in the old days, but can be like 10 microseconds now. I could be wrong there.

jacquesm 3 hours ago | parent [-]

No, you are right. And it is because digital has a much wider 'lock' range than analog. Analog only works 'in the moment' whereas digital can take the history of the signal so far into account and so not lose lock. If it gets too extreme it will still happen though so cumulative problems will still show up only much later.