[Alex_AZ 0]

Занимаюсь разработкой 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 или сможет подсказать, где возможно наличие подводных камней.

[Zig 27]

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

[Alex_AZ 0]

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

 

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

[Zig 27]

Рассмотрим мультиплексор на вход которого поступает ТП с постоянной скоростью 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 минуя мультиплексор и модулятор.

[Alex_AZ 0]

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

 

Рассмотрим мультиплексор на вход которого поступает ТП с постоянной скоростью CBR (constant bit rate).

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

 

При приеме, на входе мультиплексора, пакета с полем PCR мы из этого поля вычитаем текущее значение счетчика системной частоты SCR...

 

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

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

 

PCR accuracy error выходного потока будет зависеть от:

- PCR accuracy входного потока;

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

- времени нахождения транспортного пакета в буфере (чем дольше находится пакет в буфере, тем больше PCR accuracy error).

При этом, если значение системной частоты точно равно частоте из которой формировались метки PCR, то PCR accuracy error не будет зависеть от времени нахождения пакета в буфере.

- PCR accuracy входного потока - 40нс. Выходной получается 500-600нс.

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

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

 

...Любые флуктуации скорости приведут к дополнительной PCR accuracy error.

 

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

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

 

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

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

 

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