It's quite amusing when I see 2-3 seconds being declared "ultra low latency" on the distribution side
In broadcast contribution, where you have someone in the studio talking to a person on the screen, anything over a second brings complaints. Typically aim for under 500ms of processing delay for low bitrate contributions, and at 25fps with a bog standard blackmagic card going SDI-IP-SDI, and add in timing, you're looking at 500ms of your budget eaten by the hardware framebuffer. OBE do a better capture card - one which allows access to the data on a line by line basis. If you go for something more hardware based and say a J2K codec you can get your latency down to a couple of frames.
I had a problem a few years ago with lives from Kiev -- the ISP we had kept dropping our packets for 125ms at a time. Didn't matter if we sent 20mbit (so 2000 packets per second) or 2mbit (200pps), the number lost in a row matched the 125ms outage.
Network people laugh when I complain about 125ms outages on the internet, but it meant that standard FEC wouldn't work (maximum of 20 burst packets, even if it recovered every lost packet that would mean errors above a transport stream rate fo 1.6mbit.
Now you can use RIST to dial in resends, but with a 100ms rtt you're looking at needing 300-500ms of buffer to cope with that type of outage (to realise the packets are missing and not just delayed (say 50ms), to ask for the retransmit (50ms), and to get them (50ms, then smear them over time as you can't do an instant retransmit)
Alternatively you can transmit twice and offset, but that still adds 150ms of delay.
In broadcast contribution, where you have someone in the studio talking to a person on the screen, anything over a second brings complaints. Typically aim for under 500ms of processing delay for low bitrate contributions, and at 25fps with a bog standard blackmagic card going SDI-IP-SDI, and add in timing, you're looking at 500ms of your budget eaten by the hardware framebuffer. OBE do a better capture card - one which allows access to the data on a line by line basis. If you go for something more hardware based and say a J2K codec you can get your latency down to a couple of frames.
I had a problem a few years ago with lives from Kiev -- the ISP we had kept dropping our packets for 125ms at a time. Didn't matter if we sent 20mbit (so 2000 packets per second) or 2mbit (200pps), the number lost in a row matched the 125ms outage.
Network people laugh when I complain about 125ms outages on the internet, but it meant that standard FEC wouldn't work (maximum of 20 burst packets, even if it recovered every lost packet that would mean errors above a transport stream rate fo 1.6mbit.
Now you can use RIST to dial in resends, but with a 100ms rtt you're looking at needing 300-500ms of buffer to cope with that type of outage (to realise the packets are missing and not just delayed (say 50ms), to ask for the retransmit (50ms), and to get them (50ms, then smear them over time as you can't do an instant retransmit)
Alternatively you can transmit twice and offset, but that still adds 150ms of delay.