Jump to content
Калькуляторы

А почему так никто не делает?

Добрый вечер/день/ночь. Поделюсь (за бутылку/+1 к карме/любое барохло, кому чего не жалко) ТВ каналами по http unicast. Западная Сибирь. Начинающим start-up кабельшикам, или "крутым" для резерва. Почему этого никто не делает для своих коллег, пускай "начинающих", но тем не менее? Тут много бывших пионеров. Жалко upstream? Незаконно?

Например, есть оператор ШПД. Начальство ставит задачу - хотим ТВ. Например DVBovIP. Конечно нужен проект, etc, выбрать ГС, апгрейдить доступ для multicast, заморочится с антенным постом. А ведь можно для теста поднять Astra, попросить у соседа 10-20 каналов и погонять всё это в своей ПД, покрутить биллинг, потестировать доступ, etc. Цена вопроса - любой x86 с 2 eth и 40-120 минут времени.

Вообщем аналог home-ip.tv, только free и для "своих".

Share this post


Link to post
Share on other sites

Еще как делают. У меня с миру по нитке собрано, у некоторых каналов 4-5 ретрансляций в цепочке, забавно иногда внезапно узнавать, что источник тех или иных каналов, оказывается, в соседнем порту со мной на коммутаторе вышестоящего провайдера, а я беру через двух-трех посредников ) А еще забавно, когда некоторым экс-домосетям проще отдать каналы, взятые со спутников, уникастом в аплинк, чем распространить в свою сеть) Т. к. в сети до сих пор зоопарк и мыльницы.

Share this post


Link to post
Share on other sites

Вообще - да, это незаконно. И к тому же не всегда удобно - никто тогда не гарантирует бесперебойной доставки. Для запуска коммерческой услуги не очень хорошая база. К тому же - отдавать каналы по HTTP Unicast не очень то приятно.

Вообще после 50 активных абонентов (при наличии популярного HD канала) вы можете испытать слегка перегрузку на одной из сетевух.

Edited by zedsh

Share this post


Link to post
Share on other sites

Законно незаконно, это дело десятое. По поводу нагрузки - вы немного не правы, тут рассматривается соединение через паблик интернет двух прокси серверов, между которыми полоса всегда постоянная и зависит только от количества каналов, а не от количества абонентов за прокси. Внутри своей СПД можете раздавать то как хотите, хоть uni хоть multi хоть IPtoQAM. Тут tcp unicast рассматривается исключительно как магистральный транспорт. И скажу я вам, вполне удобно, да и tcp лучше udp, да и прекрасно работает через маршрутизацию, не надо делать стык по l2 в случае multicast.

Share this post


Link to post
Share on other sites

Если вопрос незаконности не волнует - все же сильно дешевле мелкий тазик на 3колор да астру на мелкосистемнике под ним.

10-20 каналов это легко мегабит в 50 выйдет, а за них еще и платить надо же...

Share this post


Link to post
Share on other sites

Если вопрос незаконности не волнует - все же сильно дешевле мелкий тазик на 3колор да астру на мелкосистемнике под ним.

10-20 каналов это легко мегабит в 50 выйдет, а за них еще и платить надо же...

Согласен, кому то 50 мБит "внешки" дорого, а если брать через местный IX? Astra не очень удобна в плане работы с шифрованными каналами. А вот в плане proxy IPtoIP - элементарно и быстро.

Share this post


Link to post
Share on other sites

uk2558

Я в курсе. tcp лучше UDP - кроме маршрутизации, интересно, чем лучше?

Гонять видео с трафиком? Без QOS?

Чуть выше человек писал, что не хочет делать multicast на абонентах.

Насчёт законности - дело десятое. Интересная позиция. Почему кто-то должен платить за каналы вещателям, а вы нет?

Share this post


Link to post
Share on other sites

Я в курсе. tcp лучше UDP - кроме маршрутизации, интересно, чем лучше?

Наверно в том, что TCP - это «гарантированный» транспортный механизм с предварительным установлением соединения, предоставляющий приложению надёжный поток данных, дающий уверенность в безошибочности получаемых данных, перезапрашивающий данные в случае потери и устраняющий дублирование данных. TCP позволяет регулировать нагрузку на сеть, а также уменьшать время ожидания данных при передаче на большие расстояния. Более того, TCP гарантирует, что полученные данные были отправлены точно в такой же последовательности. В этом его главное отличие от UDP.

Гонять видео с трафиком? Без QOS?

В эру "толстых" каналов и избыточной связности QOS для "гонять видео" не обязателен, хотя, при определенных случаях, желателен.

Чуть выше человек писал, что не хочет делать multicast на абонентах.

Его дело, и причем тут мультикаст? Кто и как раздаёт внутри себя - это мало кого волнующий фактор. Речь идет о использовании IP, в частности TCP unicast, в роли "некого транспорта" для передачи MPEG-TS между ГС операторов/пионеров. Насколько мне известно, федералы давно используют IP для передачи MPEG-TS по регионам от центральной ГС до местный ГС. На местных ГС снимается только местные каналы.

Насчёт законности - дело десятое. Интересная позиция. Почему кто-то должен платить за каналы вещателям, а вы нет?

Кому, как и сколько платить - каждый решает сам для себя. Вот я вполне легально беру пакет каналов. Но мне не жалко поделиться с кем то еще в благих целях.

Share this post


Link to post
Share on other sites

uk2558

Да, вы, вероятно, правы. Если количество ошибок небольшое - всё будет хорошо, просто на стороне получателя и отправителя будут чуть бОльшие задержки. Но какое количество ошибок этот протокол способен компенсировать своим механизмом повторных запросов?

Share this post


Link to post
Share on other sites

uk2558

Да, вы, вероятно, правы. Если количество ошибок небольшое - всё будет хорошо, просто на стороне получателя и отправителя будут чуть бОльшие задержки. Но какое количество ошибок этот протокол способен компенсировать своим механизмом повторных запросов?

Думаю немного, но если такая ситуация возникает на СПД, когда TCP "рассыпет" картинку, то нужно что то делать с самой СПД. TCP хоть как-то попытается "что нибудь" исправить, в отличии от UDP. Идеальная СПД - темные волокна, от источника до получателя.

Share this post


Link to post
Share on other sites

uk2558Не убедительно. Возможность восстановления (задержки на восстановление) определяется величиной буффера. Предположим, у вас битрейт (всё абстрактно) 1Мбит в секунду. Плеер играет 1Мбит в секунду (соответственно). У плеера есть некий буффер, размер которого 2 секунды. Предположим в сети возникла ситуация, когда задержки передачи (обычно непрерывной) составили 1 секунду. Данные задержки компенсировал буффер. Теперь у нас резерв в буфере составляет одну секунду. Если произошло еще одно подобное событие, то буффера не осталось. В данной ситуации плеер может поступить так: приостановить показ до наполнения буффера или не прекращать воспроизведение, но в случае следующей ситуации с задержкой ему придётся приостановить воспроизведение.

Вышеописанный пример показывает, почему задержки при передаче видео могут быть фатальными. При передаче по tcp компенсация ошибок (даже если она будет составлять по времени 3 мс), если она будет постоянной, израсходует мегабит буффера за 5 минут 30 секунд. Таким образом, передача видео по ненадёжным каналам связи в реальном времени (скажем, для IPQAM) недопустима. Допустима передача с возможностью задержки на приёмнике. С другой стороны, в то время, как плеер с UDP показал бы 33 раза артефакты, плеер с tcp их 33 раза не покажет. В этом плюс. Но через определённое время изображение застынет до наполнения буффера, а для воспроизведения по UDP буфферизация как таковая (в описанном выше смысле) не требуется (требуется для компенсации джиттера, но имеет те же недостатки).

Share this post


Link to post
Share on other sites
Но какое количество ошибок этот протокол способен компенсировать своим механизмом повторных запросов?

Сильно зависит от tcp.cc на отправителе и SACK=1 с обоих сторон.

Share this post


Link to post
Share on other sites

Ivan_83

Про первый параметр ничего не нашёл. Что это?

Share this post


Link to post
Share on other sites

zedsh

congestion control

 

А то можно после первого дропа поймать уполовинивание скорости передачи.

 

И по поводу UDP с потерями. Есть Pro-MPEG CoP3 FEC, как раз для таких случаев: спасает от потерь, порядок бдит RTP, а джиттер компенсируется буфером как обычно.

Edited by vitalyb

Share this post


Link to post
Share on other sites

vitalyb

Да, я в курсе про это. Просто тут описывают "магию" tcp по сравнению с udp при передаче видео. Это не совсем такая магия. И уж точно не избыточное кодирование.

Edited by zedsh

Share this post


Link to post
Share on other sites

Нет никакого избыточного кодирования ни в TCP, ни в MPEG-TS который на 188 байт.

 

В TCP есть ретрансмиты, которые могут начать тормозить вещающую сторону и если эта вещающая сторона писалась китайцами (которые паталогически не умеют писать софт), то после первого же провала скорости в TCP канале появляется мусор вместо видео.

 

Вокруг MPEG-TS есть навороты, позволяющие добавлять хотя бы контроль ошибок, но как правило люди думают, что исправление ошибок есть в том mpegts, который идет по 188 байт. Это не так.

Share this post


Link to post
Share on other sites

maxlapshin

Никто так и не думает.

Share this post


Link to post
Share on other sites

Что-то мне подсказывает что рассуждения ZEDSH про буфер все же несколько несправедливы в применении к HTTP unicast, про который говорил ТС.

Поток, определенный в 1 Мбит, так и продолжает течь вне зависимости от ошибки, просто буфер дает возможность "переспросить" битый пакет в этом потоке в пределах окна TCP или в пределах софта плеера и сервера HTTP.

При этом я не вижу причин отчего бы последующим пакетам не продолжать приходить, заполняя буфер. То есть в какой-то момент просто скорость потока составит "1Мбит+лишний пакет"... Ведь MPEG-TS поток, тот самый 1 Мбит весьма опосредовано связан со скоростью "потока" TCP, который в любом случае будет чуть больше.

Так что для заполнения буфера и появления артефактов при HTTP TCP передаче нужно на самом деле большое количество ошибок.

Share this post


Link to post
Share on other sites

Что-то мне подсказывает что рассуждения ZEDSH про буфер все же несколько несправедливы в применении к HTTP unicast, про который говорил ТС.

Поток, определенный в 1 Мбит, так и продолжает течь вне зависимости от ошибки, просто буфер дает возможность "переспросить" битый пакет в этом потоке в пределах окна TCP или в пределах софта плеера и сервера HTTP.

При этом я не вижу причин отчего бы последующим пакетам не продолжать приходить, заполняя буфер. То есть в какой-то момент просто скорость потока составит "1Мбит+лишний пакет"... Ведь MPEG-TS поток, тот самый 1 Мбит весьма опосредовано связан со скоростью "потока" TCP, который в любом случае будет чуть больше.

Так что для заполнения буфера и появления артефактов при HTTP TCP передаче нужно на самом деле большое количество ошибок.

После появления ошибки происходит следующее. Во-первых - ошибка заставляет отправить заново всё окно. Какой трафик в этом случае куда течёт, если по приёму окна в нём ошибка?

Но даже если всё происходит так, как вы описываете, и поток продолжает течь, плееру требуется последовательность видео пакетов для декодирования. Как он её получит, если у него на текущий момент нет необходимого пакета? Никак. И поэтому ему придётся показать артефакт. Иначе - ожидание и буффер, как я выше описывал.

Share this post


Link to post
Share on other sites
А то можно после первого дропа поймать уполовинивание скорости передачи.

Если поставить vegas то можно постареть раньше чем оно показывать начнёт :)

 

Так что для заполнения буфера и появления артефактов при HTTP TCP передаче нужно на самом деле большое количество ошибок.

Артефакты там будут только если их передадут.

 

После появления ошибки происходит следующее. Во-первых - ошибка заставляет отправить заново всё окно. Какой трафик в этом случае куда течёт, если по приёму окна в нём ошибка?

Ага, щаз.

Размер окна - указывает сколько получатель хочет получить от отправителя, оно может указывать сколько места осталось в буфере сокета.

Перепосылается не окно, которое состоит и пронумерованных сегментов а отдельные сегменты, которые и обладают нумерацией.

Если SACK согласовано для соединения то аск пакет прилетает реже и в нём указаны сразу регионы того что клиент получил, соответственно отправитель увидит какие пакеты потерялись и перепошлёт их и новые пакеты, которые ещё не были отправлены.

 

Как он её получит, если у него на текущий момент нет необходимого пакета? Никак. И поэтому ему придётся показать артефакт. Иначе - ожидание и буффер, как я выше описывал.

Откуда плеер возьмёт артефакт?)

Он просто переходит в режим ожидания.

 

Вообще, VLC ведёт себя несколько по разному в случае мпег2 и мпег4: в случае мпег2 картинка замирает, а в случае мпег4 могут появляться зелёные квадраты перед паузой. Но это именно поведение конкретной реализации декодера.

Share this post


Link to post
Share on other sites

люди думают, что исправление ошибок есть в том mpegts, который идет по 188 байт

даже если там по 208 байт будет - в UDP не поможет ни грамма

 

Просто тут описывают "магию" tcp по сравнению с udp при передаче видео. Это не совсем такая магия. И уж точно не избыточное кодирование.

HLS - вполне себе магия, бесконечная закачка - нет

Share this post


Link to post
Share on other sites

Ivan_83

Дайте ссылку, где можно прочитать про передачу по tcp в режиме "sack off".

Для декодирования плееру нужно скажем 7 пакетов (TS-пакетов). Он получил 1,2,3,битый_пакет,5,6,7. Если битый_пакет он не получил, а проиграть видео ему нужно, что ему делать?

Ожидать пакета? Не всегда это оптимальное решение, не всегда плеер в реальности будет это делать. Он будет воспроизводить, что сможет, полагаясь на "реализацию декодера". Т.е. он просто скормит декодеру последовательность пакетов либо без битого_пакета, либо с ним.

Share this post


Link to post
Share on other sites

sack off - это как раз основное рфк по тцп, саск появился не очень давно, когда скорости выросли.

В википедии и рфк.

 

Пакеты 5,6,7 плееру не доступны, они висят на дефрагментации в стёке ОС, она тупо никому ничего об них не говорит.

Если приложение спросит "а сколько у нас там байт в сокете доступно на чтение (FIONREAD)?" ОС ответит - "нет ничё".

Аналогичный ответ будет получен на recv(), read() и аналоги.

1,2,3 ОС без проблем должна отдать по первой же просьбе/сгенерировать эвент о наличии данных.

 

Вот в RTP есть seq, ts поля, и все пакеты доступны приложению моментально после получения ибо UDP и не фрагментированный. Но приложение само должно заниматься их пере упорядочиванием.

Share this post


Link to post
Share on other sites

Ivan_83

Сходу я даже не могу алгоритм подтверждения найти (что кто кому отправляет в случае ошибки без SACK). Не поделитесь ссылкой?

Да, в случае с tcp это так - я описывал работу плеера, или "откуда берутся артефакты". Так работают не только сетевые плееры, но и скажем dvb-c\s и т.п. приставки Чуть раньше я писал про буферизацию. Там описанный вами механизм как один из вариантов. Задержка с буфером при ошибке в пакете.

Share this post


Link to post
Share on other sites

Тут путаница в терминах судя по всему возникла, оттого и спор, которого нет:)

В IP пакет (TCP или UDP там выше по уровню - не суть важно) упаковывается несколько MPEG пакетов по 188 байт, обычно 7. Вот тут и спор про разные пакеты.

И про окна тоже недопонимание:)

zedsh имеет ввиду, похоже, кадр из потока, а мы с Иваном все говорим про TCP-окно: параметр, указывающий на время перепосылки ошибочного пакета (буфер сетевого драйвера, если простым словом).

 

Если пришел битый пакет, плееру не передадутся все 7 MPEG пакетов. Дропнется ВЕСЬ IP-пакет.

Только в случае TCP драйвер сетевой переспросит битый пакет у источника, и положит в буфер плеера и все станет отлично!

 

Может в тему кинуть ссылки на описание TCP и MPEG-TS чтоб терминологию срастить?:)

Edited by danilbal

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this