someone--else

Should be fixed in https://github.com/revmischa/cloudcam/pull/20 There are also a couple of new env vars to set in deploy-stack-*.sh: * JANUS_HOSTED_ZONE_ID: AWS hosted zone id where DNS aliases for Janus instances...

Apologies for late reply JanusCertPem/JanusCertKey aren't currently used for anything and are be removed in https://github.com/revmischa/cloudcam/pull/20, so CloudFormation ValidationError should go away As for SyntaxError: Unexpected token import, I'm not...

Also, #21 fixes the dev-ui/.env file generation, so creating the Cloudformation stack from scratch should now work properly

I think we can easily use a local MQTT broker to mock the AWS IoT↔client protocol and a GStreamer RTP sink for testing if video stream is ok

Another consideration: packet loss between camera and Janus gateways. Current setup assumes RTP over UDP for camera -> Janus link and RTP doesn't, in its original form, support re-transmission of...

I suppose we could implement PTP in both clients (running on cameras) and Janus gateway instances. This will provide various degree of time sync between the cameras sharing the same...

For 2s sync accuracy target either NTP on cameras or NTP on Janus gateways and timestamping frames there with Janus time would probably be enough; PTP aims for much higher...

As for clock drift, a 100ppm crystal accuracy (which is pessimistic) would result in 0.4s error over 1 hour, so if clocks are synced reasonably often, it should well be...

That said, I do like the PTP idea, at least for cameras inside the same LAN

On rev 3e9523c (current master) / Windows segfault happens immediately after doing RF->FFT on any demo scope waveform (see call stack below) Console output: Detecting CPU features... * AVX2 OpenCL...