如何提高4G网络环境传输的可靠性（RTP丢包问题）

一端的海思编码器对视频编码、打包后，通过4G网络传输到另一端海思解码器上，由于4G无线信道带宽不稳定,数据传输过程中丢包、延时、乱序不可避免，所以当海思解码器收到数据包后解码输出时，会引发一些问题：丢包、乱序导致解码出来的视频卡顿或者花屏，延时导致解码出来的视频忽快忽慢（视频抖动）。
经过大量实验发现丢包和延时问题经常发生，乱序出现的概率很小。所以暂不考虑乱序问题。
关于码流发送方式，官方文档这么描述的：
VDEC 解码器提供两种码流发送方式：
− 流式发送（VIDEO_MODE_STREAM） ：用户每次可发送任意长度码流到解码
器，由解码器内部完成一帧码流的识别过程。须注意，对 H.264/H.265/MPEG4而言，在收到下一帧码流才能识别当前帧码流的结束，所以在该发送模式下，
输入一帧 H.264/H.265/MPEG4 码流，不能希望马上开始解码图像。
− 按帧发送（VIDEO_MODE_FRAME） ：用户每次发送完整一帧码流到解码器，每调用一次发送接口，解码器就认为该帧码流已经结束，开始解码图像，因此
需保证每次调用发送接口发送的码流必须为一帧，否则会出现解码错误。通过该发送方式可以达到快速解码的目的。

1.关于丢包花屏问题
最开始做法是把解码器配置成按流发送（VIDEO_MODE_STREAM），只要网络收到一个rtp包就直接发给解码器，并没有等到一帧收完再发送，这样如果丢包的话会导致花屏，用户体验较差，后来改成这么做：把解码器配置成按帧发送，从网络上收rtp包做缓存，当缓冲成一个帧后再发送解码器，但并没有打上时间戳，当丢包后，就把丢包的这一帧到下一个I帧之前的所有帧扔掉，这样做可以避免花屏，但会引起卡顿，用户体验比之前稍微好点。
2.关于网络忽快忽慢导致视频播放抖动问题
最开始做法是做了抖动缓冲区，网络收包是一个线程，往解码器送包是另一个线程，往解码器送包的线程具体实现如下：假设现在帧率为25fps,则每延时40ms去缓存里读取一帧（延时是通过select实现的），但实际的效果是解码出来的视频跟慢动作一样,比实际要慢，后来通过打印调试发现，select延时并不精确，设置的40ms，但大概为50ms到70ms之间（通过gettimeofday），随着时间的增长，视频会越来越滞后。因此放弃此方法。
后来查看官方文档中的解码器部分，关于时间戳是如下描述：
在模式 VIDEO_MODE_FRAME下发送码流时，解码输出的图像时间戳 PTS 为发送码流接口(HI_MPI_VDEC_SendStream)中用户送入的 PTS，解码器不会更改此值；如果用户配置的 PTS 值为 0，则表示用户不进行帧率控制，而是由视频输出模块（VO）进行帧率控制；如果用户送入的 PTS 值为-1，则表示此图像不会被视频输出模块（VO）显示；如果是其他值，则表示视频输出模块（VO）根据用户设置的 PTS 值进行帧率控制。在模式 VIDEO_MODE_STREAM 下发送码流时，解码输出图像的 PTS 统一设为 0，表示用户不进行帧率控制，而是由视频输出模块（VO）进行帧率控制。

因此，把解码器成按帧发送，并打上时间戳。这样视频效果会稍微好一些，不会出现忽快的情况，但如果网络拥堵，会出现忽慢，卡顿情况。
后来上网查资料找到，针对丢包情况，需要使用一些错误控制技术来提高视频数据在网络上传输的可靠性，其中通常采用的两种方式是：ARQ(automatic repeat request)和 FEC(forward error corection)。ARQ通过反馈应答方式来保证数据的可靠性，当接收端正确接收到数据后，必须向发送端发送确认信息，否则发送端将重传数据直至收到确认信息后再发送新的数据。这种方式的优点是可以保证数据的正确性，但是会消耗发送端很多资源而且延迟较长，因此不适合实时应用；FEC通过产生一定的冗余数据来检测和纠正数据错误，虽然 FEC 会浪费一定的网络带宽，但是延迟短，所以 FEC 更适合于网络上的视频传输。

想请问一下，有人做过FEC前向纠错技术吗？这个效果如何，容易实现吗