5.5 Limitations - fonnes/flexible_fec GitHub Wiki
5.5 Limitations
Due to the limited time and resources of this thesis, we avoid implementing all of the specifications of the FEC draft, which leads to some limitations in our implementation. In order to protect the wireless multicast stream from both random as well as burst packet loss, it is recommended in the most recent FEC draft to use 2d parity FEC protection. For this reason, we only implement the 2d parity FEC scheme and disregard implementing the bit mask and retransmission scheme. However, as previously mentioned, it is trivial to extend our implementation to support these schemes, in future work.
We also do not implement FEC support for RTSP or SDP. Instead we use fixed payload types for the FEC stream with 115 for non interleaved repair packets and 116 for interleaved repair packets. We also set the column and row count statically, on both receiver and sender side, in addition to a static repair window at the receiver side. However, because we the RTP sequence number is generated randomly for each RTP session, we cannot know the offset of each FEC cluster base prior to the stream. The only way we know how to synchronize this is to find one non-interleaved and one interleaved FEC packet with the same base sequence number. In that case we know that sequence number and can calculate the offsets for later clusters. We do this in FEC2DParityMultiplexor by using a emergencyBuffer. Before we know the FECCluster offset, we place incoming packets in this buffer. For each packet we place in the buffer we look for the non-interleaved and interleaved packets with the same sequence number base. When we find it, we flush the packets and continue the stream in the regular fashion. Additionally, because we do not that metadata negotiation, we do not know the ssrc of the stream. We cannot know this prior to the stream, because this is also generated randomly. Therefore, we save the ssrc from the first packet we receive into a local variable which we use when repairing RTP packets.
Finally, we do not support RTP extension header in our FEC implementation. This is not a priority for us, because we stream H.264 video in our main experiment, which does not require RTP extension. This is, however, simple to add in future work.