Решение:

Потеря пакетов неизбежна при передаче видео H264 в пакетной сети, особенно если сетевая среда не является хорошей при передаче потока кода h264. Потеря пакетов приведет к размытию экрана и серьезной мозаике на стороне декодирования. этой областью являются FEC и NACK. Технология прямого исправления ошибок (последняя представляет собой повторную передачу), комбинация этих двух технологий может эффективно устранить визуальные эффекты, вызванные потерей пакетов. Как правило, мелкие производители не имеют этой технологии. Если вы хотите заморозить экран, когда хотите потерять пакеты. не замораживайте экран. Самый простой способ подумать об этом: как только будет обнаружена потеря пакета, все входящие пакеты будут потеряны до прибытия следующего I-кадра. Поэтому, как только потеря пакета будет обнаружена, отметьте ее и затем начните. чтобы определить, является ли полученный пакет RTP кадром 264 I. Эталонный метод оценки i-кадра:

static bool isH264iFrame(byte[] paket)
    {
        int RTPHeaderBytes = 0;
 
        int fragment_type = paket[RTPHeaderBytes + 0] & 0x1F;
        int nal_type = paket[RTPHeaderBytes + 1] & 0x1F;
        int start_bit = paket[RTPHeaderBytes + 1] & 0x80;
 
        if (((fragment_type == 28 || fragment_type == 29) && nal_type == 5 && start_bit == 128) || 
fragment_type == 5 || fragment_type == 7 || fragment_type == 8)
        {
            return true;
        }
 
        return false;
   }

ortp — это конкретная реализация протокола RTP. Видеоконференции, которые мы проводим в последнее время, также используют этот стек протоколов. Данные необходимо передать по протоколу ortp, а затем обработать. В процессе возникла проблема. После прохождения видеоданных через ортп экран становится размытым.

• 1: Наши видеоданные используют для сжатия H264. Возможности на основе h264,Если движение объекта,видеоданные будут увеличиваться или уменьшаться (по сравнению с тем, когда объект неподвижен). В это время один видеоданный кадр будет состоять из нескольких пакетов.
• 2: Чтобы легко различать границы каждого кадра при использовании ortp для передачи, предусмотрено, что в последнем пакете каждого кадра позиция markbit заголовка RTP помечается как 1.
• 3: На принимающей стороне: в основном используйте тело цикла для получения данных в каждой временной метке.

while(rtp_session_recvm_with_ts (RtpSession * session, uint32_t user_ts)!=NULL)

Основная логика заключается в том, что после встречи с пакетом с markbit, равным 1, он собирает все полученные на данный момент пакеты в один кадр данных и отправляет его на верхний уровень для декодирования h264.

Проблема возникла в последующих тестах. Качество аудиовызова было очень хорошим, но видео зависало и выглядело размытым, когда люди двигались.

Анализ выявил проблему: когда мы используем rtp_session_recvm_with_ts (RtpSession*session, uint32_t user_ts) для получения, мы беспокоимся о задержке передачи. Невозможно, чтобы все пакеты кадра были получены в одном user_ts. Фактически мы обнаружили, что. получен один user_ts. Временная метка пакета часто меняется. Если в это время теряется большая часть пакета определенного кадра, то есть пакет с markbit = 1 теряется. Позже был получен первый пакет следующего кадра, и исходная логика обработки считала, что в это время произошла потеря пакета. Весь первый пакет следующего кадра и несколько первых пакетов предыдущего кадра объединяются в один кадр и отправляются. В результате в последующих кадрах отсутствуют заголовки. Поэтому это невозможно сделать во время декодирования.

Исправленная логика должна заключаться в том, что если временная метка изменяется или встречается пакет с битом метки, равным 1, все полученные в данный момент пакеты должны быть отправлены на верхний уровень. Абсолютно нормально после тестирования.

Подведите итог:

1. На принимающей стороне определяется, потерян ли пакет, на основе порядкового номера rtp-пакета. Если пакет потерян, он помечается.
2. Когда отметка равна 1 или изменяется метка времени,Указывает конец кадра,В это время, если это помечено как потеря пакетов,,Просто выбрось это,Если потери пакета нет, отдайте его декодеру.
3. Если потерянный кадр представляет собой I-кадр, то не только текущий I-кадр будет отброшен, но и P-кадры после этого I-кадра также будут отброшены, то есть вся последовательность будет отброшена.

Ссылка на статью: http://t.csdn.cn/Leb1c.