Может быть и дешевле...
Очень много перекопАл на эту тему. Плучается так:
поставщики данной услуги с пеной у рта доказывают? что всё работает "на урА", а большенство
клиентов не довольны.
Причём к-во недовольства прямо пропорционально к-ву абонентов отдельно взятой сети.
В переводе на русский плучается так:
чем больше пользователей - тем хуже!
Вы, уважаемый Server, честно ответьте, как на самом деле дела с IPTV услугой?
Вот, что нашел в журнале "625" (http://rus.625-net.ru/625/news/):
Цитата:
Взаимодействие вещательных и IP-инфраструктур и надежная доставка телевизионных услуг
Дэнни Вильсон
Введение
Все большее и большее число компаний использует интернет-протокол (IP) для передачи видео по сети. Однако, несмотря на многочисленные преимущества использования IP, существует и ряд существенных проблем. Передача видео по IP является относительно ненадежной, и такие простые вещи, как переключение каналов, могут вызвать проблемы в IP-сети.
При передаче видео по IP возникают серьезные проблемы в сфере качества услуг QoS (quality of service), которые компании зачастую игнорируют на свой страх и риск. Мониторинг сети на предмет выявления проблем усложняется по мере резкого возрастания числа каналов. Сами программы содержат несколько звуковых дорожек на разных языках, титры и служебную информацию (close caption). Имея в виду, что передача программ сама по себе является проблемой, нужно понимать, что есть и проблема локализации источника.
Компании, планирующие передавать видео по IP-сетям, нуждаются в системе превентивного мониторинга, которая не была бы привязана к оборудованию какого-то конкретного производителя, могла бы осуществлять мониторинг в дистанционном режиме, а также проверять и сравнивать данные на каждой стадии передающей цепи. Такая система должна выявлять проблемы еще до того, как они доставят неудобство пользователю, а также быстро локализовать источник каждой проблемы. В противном случае результат один: пользователь оказывается неудовлетворенным.
Общие сведения
По мере совершенствования технологии видеокомпрессии, интернет-протокол (IP) получает все более широкое распространение, поскольку позволяет пересылать цифровое видео посредством цепи передачи. Пересылка цифрового видео с использованием компрессии MPEG-2 по IP-сети дает массу преимуществ. Например, это позволяет компаниям очень эффективно использовать дорогую полосу пропускания, поскольку сжатое видео требует для передачи значительно меньшей полосы. Кроме того, те же самые IP-сети позволяют передавать также цифровой звук, телефонию, данные и метаданные. Это является несомненным преимуществом для кабельных и телефонных компаний, которые хотят реализовать стратегию triple play на основе своих уже существующих инфраструктур.
Тем не менее, хотя IP-сети обладают рядом несомненных достоинств, им свойственны и серьезные недостатки. Компании, использующие IP для передачи видео, сталкиваются с существенными проблемами в области QoS. Если компании не придают должного значения этим проблемам, то в итоге будут иметь неприятности с клиентами, поскольку последние, в свою очередь, столкнутся с низким качеством услуг.
Чего хочет пользователь?
Сегодняшний потребитель отличается тем, что хочет очень многого. Телезрители хотят иметь возможность включить телевизор, пощелкать по каналам в поисках чего-нибудь интересного, а потом смотреть найденную программу целиком, без сбоев в ее трансляции. И они совсем не ожидают, что такая простая вещь, как переключение канала, может занять две секунды. Они не хотят смотреть телепрограмму, которая «заикается» в течение всех 30 минут ее трансляции.
Все ожидают, что телевидение будет нормально работать. Но это не так уж просто для компаний, планирующих использовать IP-сети для вещания телевизионных передач.
Переключая каналы
Такое простое действие, как переключение с канала на канал, представляет собой довольно сложную сетевую инженерную задачу, которую приходится решать компаниям, занимающимся доставкой видео по IP.
Переключение каналов — это наиболее часто встречающийся вид действий, предпринимаемых телезрителями, причем они делают это не задумываясь. Телезритель просто сидит в своем удобном кресле, нажимает кнопки на пульте дистанционного управления и легко переходит с одного канала на другой в поисках чего-либо интересного для просмотра. Однако, когда видео доставляется по IP-сети, любители переключать каналы могут испытать нечто вроде шока. Потому что возможна следующая ситуация: зритель пытается переключить канал, экран телевизора гаснет на несколько секунд, и только после этого появляется изображение с другого канала. Переключение каналов превращается в прохождение полосы препятствий.
Причина, по которой обычный телезритель может легко и быстро переключаться с канала на канал, состоит в том, что его телевизор постоянно принимает все доступные каналы, из которых отображается только выбранный.
При вещании в открытом эфире телевизионные передатчики уже передают все возможные телевизионные программы одновременно, используя радиоволны. В кабельных ТВ-системах компания-провайдер транслирует все программы по кабельной сети, которые принимаются абонентской приставкой. В обоих случаях переключение канала заключается просто в переходе на программу, которую телевизор уже принимает, но не отображает.
В сети на основе IP, однако, переход с канала на канал вызывает проблемы, потому что на телевизор передается всего один поток видео в каждый конкретный момент времени. Когда телезритель хочет сменить канал, он нажимает кнопку на пульте, посылая сигнал на телевизор, который, в свою очередь, посылает другой сигнал на коммутатор в сети. Коммутатор же должен после получения этого сигнала прекратить отправлять транслируемый поток, а затем начать передавать поток, соответствующий вновь выбранному каналу. Этим и обусловлена задержка по времени между моментами остановки коммутатором передачи одного канала и началом трансляции нового, выбранного зрителем.
Величина задержки зависит от нескольких факторов, таких как скорость работы всей сети, ее топология, скорость работы коммутатора. В итоге время отклика на действия зрителя может быть гораздо более длительным, чем многие ожидают, особенно в сравнении с мгновенным переходом с канала на канал в традиционном телевидении.
Ситуация усугубляется, когда на коммутатор поступает несколько запросов на изменение канала одновременно. В обычной IP-сети это, как правило, происходит не часто. Тем не менее, в IP-сети, по которой передаются телевизионные программы, такая ситуация будет иметь место регулярно.
Хорошим примером является трансляция финальных матчей чемпионата мира по футболу. Это одно из наиболее популярных спортивных событий в мире, собирающее у экранов телевизоров миллионы зрителей. Финальные матчи транслируются в прямом эфире по всему миру. А поэтому можно ожидать, что практически в каждой части света большое количество людей будет настраивать свои телевизоры на просмотр финалов чемпионата мира одновременно. Однако, как только в игре наступает перерыв, люди могут временно перейти на другие каналы.
В это время большинство систем загружаются практически до предела. Например, многие зрители просто принимают душ в перерыве матчей, максимально загружая локальную систему водоснабжения. В Великобритании перерыв в футбольной встрече приводит к пиковой нагрузке электросетей, поскольку зрители бросаются к своим электрическим чайникам и готовят себе чашку чая или кофе.
В IP-сети перерыв в игре во время чемпионата мира может привести к тому, что люди, смотревшие матчи по сети, одновременно начнут переключать каналы в поисках, что бы посмотреть, пока не закончится перерыв. В случае развития событий по наихудшему из сценариев это приведет к перегрузке всех сетевых коммутаторов и обрушит сеть.
Менее экстремальный, но далекий от совершенства сценарий заключается в том, что люди могут успешно переключить канал, а потом обнаружить, что не могут вовремя вернуться назад, чтобы продолжить просмотр игры. Причина — все та же перегрузка коммутаторов.
Проблемы джиттера
Другая проблема, возникающая при использовании IP-сети для передачи видео, заключается в самой природе работы сети с данными. В IP-сети данные разбиваются на небольшие пакеты, которые затем пересылаются отдельно. В пункте назначения все пакеты данных собираются вновь в одно целое.
Когда видео вводится в IP-сеть, оно тоже разбивается на малые пакеты и отправляется из источника, коим является вещающая компания, по сети, чтобы быть вновь собранным в видео, которое зритель может посмотреть на своем телевизоре. Тогда как система «чувствует себя нормально» при работе с обычными данными, при работе с видео могут возникнуть проблемы.
Файлы, содержащие видео, имеют очень большие размеры; чтобы передать по сети целый файл, может понадобиться несколько часов. Выход состоит в том, чтобы воспроизводить видео по мере загрузки пакетов. Тем не менее, из-за таких факторов, как изменение маршрутизации, перегрузка сети или сдвиг по времени, пакеты не всегда приходят с одинаковой скоростью, а порой меняется и порядок их прихода. Это явление известно как джиттер.
Решением этой проблемы является джиттер-буфер. В джиттер-буфере пакеты сохраняются по мере их прихода. Они собираются в буфере еще до того, как будут использоваться, поэтому можно добавить даже пакеты, пришедшие с опозданием.
К сожалению, решение с буфером не является панацеей. В зависимости от скорости, с которой приходят пакеты видеоданных, буфер может страдать от недогруженности или перегрузки. Недо-
груженность возникает, когда данные приходят слишком медленно. Из-за этого видео прерывается в ожидании очередного пакета и продолжается только после его прихода. Перегрузка случается, когда данные приходят слишком быстро и буфер не успевает справляться с ними, что приводит к потере некоторых пакетов. В любом из этих случаев результат примерно одинаков — видео демонстрируется с рывками и остановками, что никак не может устраивать зрителя.
Подводные камни построения IP-сети
Построение IP-сети, поддерживающей передачу видео, является достаточно сложной задачей, поскольку видео вследствие размеров видеофайлов и требования немедленной их передачи является особым случаем. Передача видео по сети данных создает на эту сеть невероятную нагрузку, поэтому инженерам необходимо найти более эффективные способы передачи данных.
Когда видео передается по IP-сети нескольким пользователям одновременно, обычно используется технология широковещания (multicasting). При широковещании, вместо видеосервера, выполняющего отправку отдельных потоков видео каждому телезрителю (эта технология известна как направленное вещание), поток видео отправляется на коммутатор, который дублирует данные, разделяет их и отправляет на другие коммутаторы в различных частях сети. Эти коммутаторы, в свою очередь, получают данные, снова дублируют их и рассылают дальше. В таком случае данные распространяются по структуре, напоминающей дерево, и нагрузка на сеть — минимальна.
Однако, несмотря на то что этот способ является очень эффективным, существует несколько технических проблем с наращиванием такой структуры. Кроме того, видео в режиме реального времени обычно передается с использованием иного протокола, чем тот, который используется для пересылки данных. Большинство данных в IP-сети передается с помощью TCP (Transmission Control Protocol — протокол управления передачей). При таком способе отправки пакетов данных в случае потери какого-либо пакета об этом сообщается источнику, и потерянные пакеты высылаются повторно. Так происходит до тех пор, пока все пакеты не дойдут по назначению. Этим гарантируется целостность всех отправленных файлов. Тем не менее, TCP не используется для передачи видео в режиме реального времени. Причина в том, что процесс обратной связи занимает слишком много времени. Вместо TCP при передаче видео обычно применяется протокол UDP (User Datagram Protocol — протокол датаграммы пользователя). UDP — это очень простой протокол, который не требует никакого подтверждения успешной передачи данных или сообщений об ошибках при их передаче. Он не предусматривает обратной связи или отправки запросов на повторную пересылку в случае утери пакетов. Из-за этого UDP не очень надежен. Если пакеты или часть данных теряется, источник никогда не узнает об этом, а до получателя они никогда не дойдут
Есть и фактор, еще больше обостряющий ситуацию. Несмотря на то что UDP предполагается использовать в определенной, оговоренной заранее манере, не во всех передачах с использованием UDP-протокола это выполняется, что еще более усложняет весь процесс передачи. Поэтому разработка IP-сети является козырной картой, способной оказать огромное влияние на качество передаваемого сигнала, от чего зависит, разумеется, и качество изображения.
Недремлющее око
Учитывая, что передача видео по IP развивается полным ходом, несмотря на все упомянутые ограничения, нужно понимать, что компаниям необходим способ мониторинга своих сетей, что гарантировало бы их способность обеспечивать своим клиентам услуги высокого качества.
Традиционно операторы вынуждены смотреть в огромное количество мониторов, чтобы вовремя выявить проблемы с передачей видео. В цифровом мире, однако, это теряет смысл. Резкий рост числа каналов означает, что визуальный контроль сотен каналов просто выходит за пределы человеческих возможностей, потому что, помимо огромного количества программ, эти программы сами представляют собой сочетание видео с многочисленными звуковыми дорожками и титрами на разных языках. Как может оператор знать, что звуковая дорожка или титры какого-то конкретного канала соответствуют тому, что должно быть?
В дополнение к этому, учитывая сложность современных сетей, выявление причин, вызывающих проблемы, также представляет собой непростую задачу. Источник проблемы может находиться в любом месте, от широковещательного коммутатора и до способа сжатия видео, либо в приемной части головной станции, куда поступает сигнал со спутника.
Принимая во внимание все потенциальные проблемы, связанные с услугами по доставке видео с использованием IP-сети, очень важно, чтобы компании, опирающиеся на IP, имели автоматизированные, экономически эффективные системы, помогающие выполнять мониторинг их сетей в целях обеспечения услуг на соответствующем уровне.
В идеале, такая система должна выполнять мониторинг и проверку целостности сигнала вдоль всей цепочки передачи данных и для всех видов передаваемых медиаданных. Системы мониторинга должны обеспечивать возможность выполнения проверки и сравнения данных на каждой стадии цепи передачи. Кроме того, эта система должна «уметь» отыскивать как проблемы в цепи передачи, возникающие сегодня, так и те, которые могут появиться в будущем.
Такая система обязана проверять доставку титров и звуковой дорожки на определенном языке в сочетании с нужной программой, а также проверять целостность сигнала, гарантируя передачу данных без проблем. Это означает возможность создания инфраструктуры с использованием оборудования различных производителей.
От такой системы требуется, чтобы она могла осуществлять мониторинг всего оборудования вне зависимости от географической точки его установки. Не должно иметь значение, где расположено тестируемое оборудование — в соседней комнате или в соседнем городе.
И, в идеале, эта система должна обеспечивать возможность подключения к другим информационным системам, таким как биллинговая платформа или информационная база данных клиентов, чтобы проблемы, возникающие у пользователя, решались как можно быстрее.
Вместо заключения
В IP-сети проблема передачи ТВ-программ не является вопросом использования не той частоты. IP-сети очень эффективны в передаче данных в целом, но передача телепрограмм, которые отличаются огромными объемами и требуют немедленной доставки, представляет собой куда более сложную задачу.
Качество услуг QoS является экономической проблемой, когда речь идет о передаче видео по IP-сети. В ситуации, когда даже переключение каналов становится проблематичным, компаниям необходимо уделять пристальное внимание пользователю, перешедшему на просмотр телепрограмм по IP.
Чтобы гарантировать целостность сигнала и услуги, нельзя рассматривать превентивный мониторинг вдоль всей цепи распространения программ как нечто необязательное, а лишь желательное. Объем, сложность и скорость потоков данных требует автоматизированной, интегрированной системы. В эру цифрового видео, передаваемого по IP-сетям, недостаточно только «зоркого глаза».
Конец цитаты.
А как у Вас на счёт "глюкАвости"?
