СПОСОБ ПЕРЕДАЧИ ПАКЕТОВ В СИСТЕМЕ ПЕРЕДАЧИ
METHOD FOR TRANSFER OF PACKETS IN TRANSFER SYSTEM

Документ RFC 2250 [3] описывает способ транспортировки нескольких транспортных потоков MPEG2 и пакетов потока программы в полезной нагрузке пакета RTP (протокола реального времени), а также определяет, что отдельная метка времени прикреплена к каждому пакету RTP.
Спецификация [1] MPEG-2 описывает способы включения меток времени в поток MPEG2, использования других меток времени на стороне-адресате для восстановления тактового сигнала в синхронизме с тактовым сигналом на стороне-источнике и использования различных меток времени для подачи на декодер MPEG и управления на предмет того, когда следует отображать элементы переданного потока.
Спецификация [4] DVB-IP описывает обобщенную архитектуру для распространения мультимедийных услуг по IP-сетям. Эта спецификация принимает RFC2250 в качестве механизма для транспортировки потоков MPEG-2 по RTP. Возможно это стандарт, использующий RFC 2250.
Поскольку несколько пакетов MPEG2 транспортируются в отдельном пакете RTP, требуются некоторые предположения, если временные характеристики всех пакетов MPEG2 должны быть действительно восстановлены на стороне-адресате. Обычно предполагается, что весь поток MPEG2 является потоком с постоянной битовой скоростью или что он является, по меньшей мере, кусочно-постоянным, то есть битовая скорость изменяется только во время, когда в поток вставлены метки времени PCR или SCR. Это не обязательно является истинным, и, главным образом, но не только, при транспортировке только частичного транспортного потока MPEG2 (MPEG2-TS) (потока с «дырами»), например потока, который первоначально являлся потоком с постоянной битовой скоростью, но из которого было удалено определенное (возможно большое) количество пакетов.
Если некоторое количество пакетов MPEG2 транспортируется внутри такого пакета RTP, то метка времени RTP создается в то время, когда формирование пакета RTP завершено, то есть в то время, когда последний пакет MPEG-2 достигает отправителя. Формирование пакетов RTP из частичного транспортного потока (TS) осуществляется согласно Фиг.3.
Предшествующий уровень техники
На стороне-адресате, это означает, что известным является только время этого последнего пакета, время всех остальных пакетов MPEG-2 может быть только оценено. Восстановленные временные характеристики пакетов включают в себя дрожание (джиттер), которое характеризуется неопределенностью времени, когда пакет MPEG-2 помещен в буфер RTP. Это дрожание равно разнице времен передачи двух последовательных пакетов RTP (то есть разности их временных отметок). Теперь при восстановлении тактового сигнала MPEG-2 извлекают из этого характеризуемого дрожанием потока метки времени PCR или SCR и подают их на схему фазовой автоподстройки частоты (PLL) для восстановления тактового сигнала MPEG. Дополнительное дрожание, введенное передачей RTP, налагает на эту PLL требование большей эффективности по сравнению со случаем непосредственной передачи (без RTP) потока MPEG. Это также приводит к более длительному времени перед синхронизацией тактового сигнала.
Изобретение частично признает вышеупомянутую проблему и частично предлагает ее решение определенным в формуле изобретения способом.
Изобретение касается способа передачи первых пакетов, заключенных во вторые пакеты, в системе передачи, в которой часть первых пакетов содержит первый опорный момент времени для синхронизации тактового сигнала приемника, а по меньшей мере часть упомянутых вторых пакетов содержит второй опорный момент времени для сокращения дрожания при передаче вторых пакетов в приемнике, характеризуемого выполняемыми в передатчике этапами, на которых:
- выполняют сбор первых пакетов;
- определяют, содержит ли собранный первый пакет первый опорный момент времени,
- инициируют передачу второго пакета, заключающего в себе собранные первые пакеты, включающие в себя упомянутый первый пакет, содержащий первый опорный момент времени, в ответ на положительный результат определения.
Согласно варианту осуществления изобретения способ дополнительно содержит этап инициирования передачи второго пакета в случае, если количество собранных первых пакетов достигает предопределенного значения.
Согласно варианту осуществления изобретения первые пакеты являются пакетами транспортного потока MPEG 2, а первый опорный момент времени является PCR (опорным временем программы).
Согласно варианту осуществления изобретения вторые пакеты являются пакетами RTP, а второй опорный момент времени является меткой времени, определяемой передатчиком для введения в отдельные пакеты RTP.
Согласно варианту осуществления изобретения способ дополнительно содержит этап соблюдения максимального временного интервала между передачей двух последовательных пакетов RTP.
Дополнительные преимущества изобретения будут проявляться благодаря описанию конкретного неограничивающего варианта осуществления изобретения. Вариант осуществления будет описан со ссылкой на чертежи, на которых изображено следующее:
Фиг.1 - диаграмма, иллюстрирующая проблему дрожания, происходящего в результате заключения пакетов транспортного потока (TS) MPEG 2.
Фиг.2 - диаграмма, подобная диаграмме, изображенной на Фиг.1, где вариант осуществления изобретения используется для сокращения дрожания.
Фиг.3 является блок-схемой передатчика согласно предшествующему уровню техники.
Фиг.4 - блок-схема передатчика согласно настоящему варианту осуществления.
Фиг.5 - блок-схема приемника и декодера пакетов RTP, заключающих в себя пакеты транспортного потока (TS) MPEG 2.
Настоящий вариант осуществления касается частичного транспортного потока (TS) MPEG-2. Однако изобретение не ограничивается частичным транспортным потоком (TS) MPEG-2. Оно может быть применено к полным транспортным потокам (TS) MPEG-2, а также и к другим видам передачи пакета, где присутствует подобие проблемы синхронизации и дрожания.
Изображенная на Фиг.1 диаграмма иллюстрирует процесс внедрения дрожания. Верхняя линия, изображенная на чертеже, иллюстрирует мультиплексированный полный транспортный поток (TS) MPEG 2, содержащий отдельные пакеты транспортного потока (TS) MPEG 2. Частичный поток извлекается из полного потока. Показаны пакеты, содержащие метки времени PCR системы MPEG 2. В данном случае предполагается, что полезная нагрузка пакета RTP составлена из четырех пакетов транспортного потока (TS) MPEG 2 и что пакет RTP отсылается каждый раз, когда в буфере передатчика присутствуют четыре пакета транспортного потока (TS) MPEG 2. Как изображено, dTA и dTB соответственно представляют собой интервалы реального времени между последовательными пакетами RTP на уровне передатчика. Они также являются интервалами, требуемыми для сбора количества пакетов транспортного потока (TS) MPEG 2, достаточного для заполнения полезной нагрузки каждого пакета RTP. После отсылки этих пакетов это соотношение временных характеристик изменяется посредством дрожания, введенного сетью. После приема временные отметки RTP используются для восстановления dTA и dTB. Однако изобретателями было признано, что приемником предполагается, что все пакеты транспортного потока (TS) MPEG 2 отдельного пакета RTP были приняты в одно и то же время (то есть они подаются в буфер приемника в качестве пачки, когда метка времени RTP, находящаяся в заголовке пакета RTP, соответствует тактовому сигналу RTP приемника). Следовательно, вводится дополнительное дрожание, поскольку временной интервал между двумя последовательными пакетами транспортного потока (TS) MPEG 2 в первоначальном потоке может быть отличным от временного интервала между записями каждого из этих пакетов в буфер декодера приемника.
Предлагается отсылать пакет RTP, как только присутствует пакет транспортного потока (TS) MPEG-2, содержащий PCR MPEG-2, а не ждать систематически до тех пор, пока пакет RTP не достигнет максимального собственного размера (обычно соответствующего полезной нагрузке в 7 пакетов транспортного потока (TS) MPEG-2) для отсылки пакета RTP. Таким образом, метка времени RTP формируется с постоянной задержкой по сравнению с приемом пакета MPEG 2, содержащего опорный момент времени.
Частичный транспортный поток (TS) MPEG2 извлекается из полного транспортного потока (TS) на стороне отправителя. Заголовки всех пакетов транспортного потока (TS) анализируются, и определяется, содержат ли они метку времени PCR (это легко достижимо, так как об этом сообщается в заголовке). В обратном случае пакет транспортного потока (TS) помещается в буфер RTP. Если буфер заполнен (обычно после семи пакетов транспортного потока (TS) для того, чтобы не превышать максимальную полезную нагрузку Ethernet; могут присутствовать другие критерии или другой максимальный размер), пакет RTP обеспечивается меткой времени посредством обычно работающего в автономном режиме тактового генератора, работающего с частотой 90 кГц, и отсылается обычным способом. Если пакет транспортного потока (TS) содержит PCR, он также помещается в буфер RTP, но затем этот пакет RTP немедленно обеспечивается меткой времени и отсылается без ожидания другого состояния (например, буфер заполнен). Таким образом, обеспеченные меткой времени пакеты MPEG 2 всегда помещаются в конце полезной нагрузки пакета RTP.
Фиг.4 - блок-схема, изображающая важные компоненты приемника.
После приема пакета RTP на другой стороне он буферизируется. Пакеты выдаются из буфера в случае, если их метка времени RTP соответствует локальному тактовому сигналу 90 кГц плюс постоянной задержке. Локальный тактовый сигнал 90 кГц может быть синхронизирован с тактовым сигналом 90 кГц отправителя любым способом, например PLL в сетевом интерфейсе может анализировать метку времени в пакете RTP во время поступления и откорректировать значение локального тактового сигнала так, чтобы он оставался в синхронизации с тактовым сигналом отправителя. На выходе описанного на Фиг.5 целого механизма в декодер MPEG2 подаются пакеты транспортного потока (TS) MPEG2 с ритмом, по существу идентичным ритму пакетов RTP. Вследствие того что пакет транспортного потока (TS) MPEG2, транспортирующий PCR, всегда является последним пакетом, находящимся в пакете RTP, метки времени RTP обеспечивают ритм, по существу идентичный ритму пакетов транспортного потока (TS) MPEG2. Дрожание, упомянутое со ссылкой на Фиг.1, устраняется, поскольку временной интервал между любым пакетом транспортного потока (TS) MPEG2, содержащим PCR, и началом транспортирующего его пакета RTP фиксирован. Несмотря на то что в настоящем варианте осуществления пакет транспортного потока (TS) MPEG 2, содержащий PCR, всегда является последним пакетом, находящимся в пакете RTP, это обосновывает то, что его местоположение в каждом пакете RTP, в котором он присутствует, остается неизменным. На стороне приемника, поскольку ритм RTP перестроен, ритм пакетов PCR транспортного потока (TS) MPEG2 также перестраивается с большей точностью по сравнению с непосредственным пакетированием, изображенным на Фиг.1. Фиг.2 изображает пример схемы согласно настоящему варианту осуществления с заключением в пакет RTP максимум четырех пакетов транспортного потока (TS) MPEG2 для каждого пакета RTP. В этом случае разность времен между двумя пакетами транспортного потока (TS) MPEG2 на стороне приемника достаточно близка к разности времен на стороне отправителя, и, таким образом, повторная синхронизация тактового сигнала декодера MPEG будет более быстрой.
Следует отметить, что это может быть объединено со следующими состояниями: например, согласно варианту осуществления может быть полезно ограничить максимальный временной интервал между последовательными пакетами RTP для облегчения восстановления тактового сигнала RTP в приемнике.
Изобретение также может быть усовершенствовано посредством задания IP-пакета, содержащего PCR или SCR, с максимально возможным приоритетом. Например, в кадре DVB-IP (см. ссылку в конце этого текста) возможно задать индивидуальные приоритеты пакета с целью обеспечения определенного качества обслуживания (например, используя точку кода DiffServ в заголовке пакета). Это гарантирует, что такой IP-пакет пострадает в наименьшей степени от возможной перегрузки маршрутизатора, создаваемой другим сетевым трафиком, и поэтому добавляет большую стабильность в отношении времени, используемого для отсылки такого IP-пакета от сервера-источника к клиенту.
Изобретение сокращает дрожание при восстановлении тактового сигнала MPEG, не отступая от RFC2250. Кроме того, стандартные декодеры MPEG2 могут быть использованы даже для частичных транспортных потоков, если буфер декодера достаточен для сохранения содержимого одного пакета RTP (обычно семь пакетов транспортного потока (TS) MPEG2 = 7·188 байтов).
Это также относится к системным потокам MPEG2, если они транспортируют, например, сжатое видеоизображение MPEG4-Part10 [2].
Ссылки:
ISO/IEC 13818-1:2000
[1]  Information technology - Generic coding of moving pictures and associated audio information: Systems, International Standards Organization.
http://www.iso.org/iso/en/CataloqueDetailPaqe.CataloqueDetail?CSNUMBER=315 37
ISO/IEC 13818-2:2000
http://www.iso.orq/iso/en/CataloqueDetailPaqe.CatalogueDetail?CSNUMBER=31539.
Information technology - Generic coding of moving pictures and associated audio information: Video, International Standards Organization.
[2] MPEG-4 Video: ITU-T Rec H.264 | ISO/IEC 14496-10 Information Technology - coding of audio-visual objects - Part 10: Visual.
[3] IETF RFC 2250, RTP Payload Format for MPEG 1/MPEG2 Video, D. Hoffman et al., January 1998, available for example at http://www.ietf.org/rfc/rfc2250.txt.
[4] DVB TM3022, Digital Video Broadcasting (DVB) - Transport of DVB Services over IP, ETSI, RTS/JTC-DVB-93, 2004-03-26.
Дополнительная информация, касающаяся видео MPEG2 и систем MPEG, может быть найдена в следующих документах: ISO/IEC 13818-1:2000 'Information Technology - Generic coding of moving pictures and associated audio information: Systems, ISO' and ISO/IEC 13818-2:2000 'Information Technology - Generic coding of moving pictures and associated audio information: Video, ISO'.