Thinking about digital errors
At the very heart of this, is the idea of parity, and this concept is typically met early on as we learn about digital signals. We categorize parity schemes as being ‘odd’ or ‘even’.
If you have an 8-bit word, say 10010010, then simply counting the number of ‘ones’ in that word and appending a ninth bit (the parity bit) which makes the total (of ones) even gives a 9-bit word including even parity: 100100101. (Appending a one, rather than a zero, made the total four – an even number – this is even parity)
At the receiving end, doing the same operation on the received 8-bit word should result in the same value, 1 (in this case), for the parity bit. If the operation results in a parity bit of 0 then a bit error has been detected. An error that occurred after the word was sent.
The receiver now has the option of rejecting the errored word (or if it can, repairing it).
This approach has limitations; it would not, for example, detect an even number of errors. And of course there is the possibility that the only error is actually in the parity bit itself. But nonetheless this approach, doing a calculation before and after transmission, is the foundation of error handling.
Clearly, doing this has made the 8-bit word longer – increasing the payload, in this case, by 1 in 8 – and there will also be a time penalty (latency) whilst the calculation is made. These are the ‘costs’ of error handling.
Errors in the wider network world
Potential errors can vary from loss of a single bit to a burst of interference that corrupts a run of consecutive bits. In computer network systems, protocols such as TCP/IP give a receiver the option to request the sender to repeat a ‘suspect’ data packet. This is great for file transfer, however in real-time video systems, that ‘resend’ delay shows as a pause – seen as video stuttering - whilst the packet is retransmitted. In such systems we obviously prefer to avoid that stutter – so TCP is not the first choice for moving real-time video over an RTP network. We instead use UDP and a scheme that incorporates some capacity for handling the errors at the receiver - without reference to other nodes – in short, incorporating extra ‘check’ data in the stream. This is known as Forward Error Correction (FEC), an aspect of channel coding.
Those familiar with the layer model for communication systems will realize that error handling could be present in any of the layers – uniquely protecting the payload in that particular layer. Inevitably detection/correction in one layer will also protect error-related payload in an earlier layer. The ‘layer enthusiasts’ will also know that in different payloads we use different words for distinct clusters of bits. In IPMX media these base units are known as Datagrams (not packets). The FEC information itself is often described as packets but also constitutes a Datagram.
FEC is used on relatively low error rate systems (few errors corresponding to a good link quality).
In real systems, the implementation is more complex than this. IPMX uses a more complex arithmetic (a polynomial rather than a simple odd/even indicator) to create protection values. This is analogous to digital signatures on documents – although without the security. (These are not intended to protect against malicious changes.)
Is this approach actually used in practice?
The error detection concept was for example built into the SD-SDI bitstream since the very beginning, in a protocol known as EDH (Error Detection and Handling). A different system, CRC (Cyclic Redundancy Check), is included in the HD-SDI interface to the same end. The process is invisible to the user, but those with technical responsibilities are able to monitor error rates, and how hard the error handling is working, to make judgements on the quality of the signal path (the correction needs to work increasingly harder as you approach the distance limit). In SDI, there is no option for requesting a ‘resend’ – error handling happens after receipt.
In SRT (Secure Reliable Transport) streams, the existence of the error handling is overtly seen in the use of the word ‘reliable’. This scheme was created to address some of the vulnerabilities in other internet streaming protocols like RTMP. You will realize that this moves the goalposts from the ‘good link quality’ I mentioned earlier. (And that is the direction of travel of IPMX too.)
A well-designed transmission system may have several different mechanisms for increasing resilience to data loss. Such a scheme is an optional feature of IPv4 which means that individual protocols have to include it to be sure (it became mandatory in IPv6). IPMX, the emerging AVoIP standard, incorporates just such a scheme. The aim of such protection is to maximise the fidelity of the received bitstream. The first objective is to detect an error; the second is to, if possible, automatically correct the error.
In the simple 8-bit example above, the parity calculation was done horizontally. In practice, the calculation is conducted vertically across a block of consecutive datagrams. This has the effect of spreading out any bursty errors across multiple calculations – increasing the chance of resisting the errors.
TR10-06: the VSF’s description of the methodology
The TR-10 suite of Technical Recommendations by the VSF (Video Services Forum) effectively defines IPMX by describing the additions to the existing SMPTE ST2110 standard.
IPMX devices are not required to support FEC, but if they do, they have to do so in a prescribed way – to ensure interoperability. And even if not supporting it, IPMX devices must tolerate the presence of the extra FEC data. The particular document defining FEC in IPMX is VSF’s TR-06, and is based on SMPTE ST2022-5. The IPMX implementation of FEC uses block coding. There are many types of block codes.
As we know, (see ‘IPMX: Remind me, what is it again?’ also on Avixa Exchange) IPMX treats a signal as three essences – video, audio and metadata – the FEC data is an integral part of the essence it is protecting. TR-10 defines one FEC profile for audio and another for the higher bandwidth video flow.
Both use the ‘fixed block matrix’ method. Consecutive video datagrams are arranged as a 16 high x 2 wide block – and the FEC calculation done (vertically) for each of the two columns. This means the FEC is conducted across non-consecutive bits of non-consecutive datagrams.
The FEC stream always goes to the same IP address as the media datagrams (because that is where the calculation needs to happen!)
Keeping the quality
Starting from highest quality video is a good start, but even with good bandwidth, network glitches and dropouts can happen. And that can degrade image quality entirely independent of the compression scheme used. A method of handling these bit-errors is something that greatly benefits the end user. And that is why Forward Error Correction (FEC) is a part of the IPMX methodology.
Please sign in
If you are a registered user on AVIXA Xchange, please sign in