Занимаюсь разработкой DVB-C модулятора. В целом все работает, возникают только вопросы к алгоритму коррекции (перештамповке) PCR. Проблема проистекает из того, что скорость входного потока в общем случае не равна скорости потока, генерируемого модулятором. Для компенсации этой разности скоростей в поток добавляются нуль-пакеты. Такое изменение структуры потока влечет за собой необходимость коррекции меток времени, так как временные интервалы между пакетами с временными метками в общем случае изменяются. Механизм перештамповки PCR использую такой как описан, например здесь:
https://electronix.ru/forum/index.php?showtopic=93519
Такой же механизм (добавление к PCR времени задержки пакета в цепях модулятора) описан и во множестве других статей. Схема в общем виде моей реализации приведена в приложении.
Смущает то, что выходное значение PCR-accuracy сильно увеличивается по сравнению со входным, если верить анализатору Dektec. А именно, при входном PCR accuracy = 40нс, на выходе получаю PCR-accuracy иногда достигающее величины 500-600нс. Источник потока - программа Astra.

Может кто-то сталкивался с проблемами приведенного алгоритма перештамповки PCR или сможет подсказать, где возможно наличие подводных камней.

Добавлять значение счетчика системной чистоты к полю PCR нужно после вставки NULL пакетов, после мультиплексора, перед модулятором.

Спасибо за ответ. Абсолютно согласен. Я похоже непонятно и не совсем корректно нарисовал схему, не хотел загромождать. Вычисление приращения и нового значения PCR происходит в момент, когда мультиплексор отправляет пакет, содержащий PCR, модулятору. Мультиплексор же и подменяет старое значение PCR новым вычисленным.

В целом, насколько понял, примененный алгоритм ситуацию улучшает, но вносимый джиттер в PCR расходится с описанным в разных статьях (если нужно, могу выложить, но не раньше понедельника), где говорится о 40нс прироста PCR accuracy. Может ли это быть как-то связанным с преобразованием размера пакета при передаче модулятором из 188 байт в 204 после кодера Рида-Соломона? Модулятор, на первый взгляд, дает постоянную задержку данных в нем, что требуется стандартом ISO/IEC 13818. Пока даже не знаю что еще проверить.

Рассмотрим мультиплексор на вход которого поступает ТП с постоянной скоростью CBR (constant bit rate).
При приеме, на входе мультиплексора, пакета с полем PCR мы из этого поля вычитаем текущее значение счетчика системной частоты SCR.
Далее, мы все, кроме входных нуль пакетов (и всего другого, что нам не нужно), записываем в буфер.

Далее формируем частоту выходного транспортного потока мультиплексора с учетом требуемой длины выходного транспортного пакета 188 или 204 байта. Скорость транспортных пакетов (их число в секунду) для пакетов 188 и 204 байта будет одинаковой. Изменится только частота байт.

Чтение из буфера.
Пока в буфере нет целого транспортного пакета формируем в выходной ТП нуль пакет. Как только в буфере есть целый транспортный пакет - вычитываем его в выходной ТП. Если в пакете есть поле PCR, то добавляем к нему текущее значение счетчика системной частоты.

Таким образом физический смысл коррекции меток PCR путем вычитания, на входе буфера, и добавления, при чтении из буфера, текущих значений счетчика системной частоты, есть не что иное, как добавление к значению поля PCR задержки данного пакета в буфере, выраженного в тактах системной частоты.

PCR accuracy error выходного потока будет зависеть от:
- PCR accuracy входного потока;
- соотношения между частотами системной частоты 27 МГц и 27 МГц из которых формировались метки PCR (чем больше разность между ними, тем больше будет PCR accuracy error);
- времени нахождения транспортного пакета в буфере (чем дольше находится пакет в буфере, тем больше PCR accuracy error).
При этом, если значение системной частоты точно равно частоте из которой формировались метки PCR, то PCR accuracy error не будет зависеть от времени нахождения пакета в буфере.


Все написанное выше справедливо для ТП с постоянной скоростью.
В вашем случае имеет место быть IP.
Из него, для работы этой схемы коррекции PCR, нужно очень точно восстановить скорость потока (что вы и делаете с помощью большого буфера). Любые флуктуации скорости приведут к дополнительной PCR accuracy error.

Для отработки схемы коррекции PCR можно временно отказаться от приема ТП из IP и подать его, например, через DVB-ASI.

Для отработки схемы восстановления скорости ТП, принятого по IP можно вывести поток через DVB-ASI минуя мультиплексор и модулятор.

Zig, благодарю за участие, особенно в выходной.


Согласен, уточнение важное, не отметил сразу. Пока речь идет именно о CBR.


Все реализовано так, просто в целях отладки пока сделал вычисление времени задержки (в количестве тактов SCR) при добавлении к выходному пакету.


- PCR accuracy входного потока - 40нс. Выходной получается 500-600нс.
- 27МГц на моей плате отличаются от номинала (если верить поверенному частотомеру) герц на 20. Вроде не должно быть критично на интервале 1 пакета при битрейте выходного потока 50МБит/с и входного 24.9Мбит/с.
- Пакет не задерживается дольше, чем на время одного выходного пакета при выходном битрейте 50Мбит/с.


Вместо этого просто задавал константой (исходя из скорости оригинального входного потока, взятого из файла) скорость чтения из большого буфера. Но уменьшить PCR accuracy ниже величин 500-600нс не получается.


Согласен, но это судя по результатам, пока проблема меньшего масштаба. Уже добился результатов, когда восстановленное значение скорости потока и заданное константой дают равный результат для PCR accuracy.

Во всяком случае, выяснил, что понимаю алгоритм коррекции PCR правильно. Возможно стоит поискать проблемы и неточности в его реализации.