Уважаемые,кто хорошо знает цифровое видео? Там есть такое понятие как "Коррекция PCR",ясно как выполнять эту коррекцию в мультиплексорах,модуляторах и т.д. А вот как эта коррекция выполняется в сетях IPTV? И делают ли её в этих сетях?Задержки пакетов непредсказуемые,большие да и единых часов нет чтобы корректировать PCR с точностью до +-100нс.

У нас товарищи в мультиплексоре делают БАльшой буфер на максимальную задержку пакетов до 60мс. потом вычитывание с PCR recovery clock'ом. Потом можно дальше в IP засовывать. А какая коррекция нужна в IP для TV??

Да, а зачем там коррекция? Большой буфер, все непредсказуемые задержки им компенсирутся, а если буфер все же опустел, значит quality of service канала не выдержано. Его обычно в потоковых каналах стараются держать... Или Вы хотите потоковое видео транслировать в single frequency net и синхронно эти пакеты выкидывать в разных передатчиках?

Может Вы и правы. Но вот такой пример - на выходе кодера MPEG-2 у нас есть транспортный поток с видео,звуком и пакетами байт-стаффинга. Вроде как не логично передавать по эзернету байт-стаффинг (трафик только занимает). Но если из потока вырезать пакеты байт-стаффинга, то PCR у потока сразу гробится.Вот и вопрос - как его восстановить на приёмной стороне?Кстати,чем Вы контролируете значения PCR? Мы пользуемся адаптером DТU-245 от Dektec.



Передатчики SFN мы делали (правда не для IP),прекрасно синхронизируются при помощи эластичного буфера + ФАПЧ + GPS. Для IP сейчас такая задача не стоит.

делал что-то подобное, нужно было вставить еще один PID отдельно и не убить идущие потоки.
брал свой счетчик PCR (27 MHz, и локально считал им.), брал входящий поток, вычитал текущее значение LocalPCR из всех PCR полей потока, подмешивал свои пиды (ну там типа очередь пакетов) и снова прибавлял LocalPCR во все поля PCR в потоке. таким образом поток не нарушался.
в вашем случае нужно тоже самое, только пакеты TS_NULL выкидывать из потока, между операциями вычитания сложения.
К сожалению, никакого тестового оборудования не было для MPEG-TS в тот момент, но VLC нормально декодировал поток с подмешиным PID.

кажется такой метод называется Accumulator based PCR restamping. делал по статье из IEEE

Спасибо!
Ну мы так и делали,это нормально проходит,например,когда в потоке в текущий момент должен быть пакет видео,а в это время вставляется новый пакет TS_NULL - пакету видео придётся обождать пока не закончится пакет TS_NULL и его PCR нужно будет скорректировать.
Но тем не менее если просто отфильтровать TS_NULL (без вставки новых) этот метод не работает.
А с VLC нужно быть осторожным,у меня был случай что он нормально воспроизводил битый поток из файла,долго мучались пока не догадались просмотреть файл через PowerDVD - вот он чётко отловил дефект.

Ну кроме VLC есть куча средств для проверки MPEG-TS потоков. названия сейчас не скажу, но если в Инете поискать то можно найти их в том числе и "вылеченные" по запросу "MPEG-2 Transport Stream Packet Analyze".

Кстати, хочу еще обратить ваше внимание, что имеются поля Adaptation, которые могут в себя содержать NULL значения. С их помощью скорость потока еще более четко может быть задана, тк их можно вставлять не ровно 188 байт, а хоть 27. обычно такую подставу устраивал как раз VLC, когда ему поручали данную операцию.

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

Согласен,нужно всё дотошно проанализировать.Эта работа у нас не сегодняшнего дня,а на перспективу.Просто решил забросить камень,и видно не зря.Спасибо!