4 edits |
to karbon15
Re: IPTV latencyIt's not similar to videoconferencing at all. Zoom and the likes are mostly cloud-based or peer-to-peer or a mix of both with a centralized backend, DRM-free while IPTV is linear with DRM.
Basically, we are using two ways to get feeds:
Directly from the broadcaster. The broadcaster distributes the feeds over local HD-SDI connections in RAW format to our encoders inside their facility. A first pass encoding is done at a high bitrate and converted to IP which then flows towards our IPTV head-end over our network equipment, own fiber and own IP/MPLS network.
From a partner (sat or fiber). The broadcaster distributes the feeds over local HD-SDI connections in RAW format to the third-party encoders and then network equipment inside their facility. A first pass encoding is done at a high bitrate and converted to IP which then flows towards the partner's IPTV head-end. Could be their own fiber, leased fiber, over satellite, or a mix of all. At the head-end, it might (or not) bypass re-encoding as we acquire high bitrate signals and there's no DRM. The streams are then re-distributed over sat over to us or via fiber to us.
At the head-end, it gets re-encoded but this time in different profiles, then packaged (with DRM), then redistributed to our origin caches which then feed the caches closest to our customers via unicast.
The first way would be more direct and optimized. The second way is definitely inducing some delays in the overall process. The RAW to IP and all the encoding and DRM definitely adds up but we all have to do this. A big difference between IPTV from TPIA is that our delivery method is unicast with cache servers (like any big streaming platform out there) vs. the traditional or IPTV from an incumbent where the feed leaves the head-end and then multicasted over the network directly to last-mile distribution equipment and then each STB gets the feed from their node.
There's also some extra "latency" in the upper layers between the STB, middleware, and backend compared to more traditional methods non-IP-based methods (like a sat/cable receivers) but I am less familiar with the low-level details. |
|
Zoom gets video (at varied resolutions anywhere between 360p and 4k from a USB source usually). The contents then gets interpreted by a driver, which populate framebuffers. The software captures framebuffers, and encodes it to a more suitable format, think MPEG-TS, H264, AV1.
Another layer of software, it it's done right, encrypts it in SRTP or a similar protocol. This traffic goes through wifi, copper last-mile, then a ISP, then through transit (for hundreads or thousands of kms), then through a videoconferencing provider (although peer-to-peer is possible with WebRTC and some other technologies given that NAT traversal works), and all the reverse way, transit -> ISP -> Last mile -> Encryption -> Codec -> Computer -> Analog space. Typical latencies are 150ms for this whole flow if you are conferencing within North America.
Bear with me here. Seconds are an eternity for computers.
While OTA follows a very similar process as what you are describing, it's a minute earlier or so (at least for Radio-Canada)... |