[lllsergeyv]

Помогите решить следующую задачу: Есть мультикастовый поток порядка 100 тв каналов. Хочу преобразовать это все в юникаст для дальнейшей раздачи через http. Посоветуйте софт или железное решение для преобразования мультикаста в юникаст.

[Гость jamaica]

udpxy, последний билд даже не падает

[jjonjon]

Помогите решить следующую задачу: Есть мультикастовый поток порядка 100 тв каналов. Хочу преобразовать это все в юникаст для дальнейшей раздачи через http. Посоветуйте софт или железное решение для преобразования мультикаста в юникаст.

Не могли бы вы подробнее описать задачу ?? Какой источник по какому протоколу ?? и куда вещать по HTTP ?? Ширина канала ? Почему именно HTTP а не RTSP к примеру ??

Изменено 22 декабря, 2011 пользователем jjonjon

[server801]

udpxy не катит. relaying на FreeBSD рулит отлично! сто каналов - даже мало для него.

[zdima]

а вот как наоборот, unicast загнать в multicast на подобие udpxy?

есть STB Dlink Dib-120, хочется туда залить нечто вроде udpxy, только наоборот.

Ведь приставка понимает только multicast, поэтому есть задумка - приставка пытается получить поток, а демон преобразует http в udp, но только не все каналы, а один, который запрашивается.

Есть подобное решение?

[hip]

udpxy не катит. relaying на FreeBSD рулит отлично! сто каналов - даже мало для него.

а где можно качнуть relaying для linux проверить как она работает. и есть ли он вообще??

Изменено 18 февраля, 2012 пользователем hip

[alexmern]

а где можно качнуть relaying для linux проверить как она работает. и есть ли он вообще??

ftp://ftp.itl.ua/pub/iptv/iptvrelay/

[maxlapshin]

С преобразованием UDP -> HTTP есть проблема, связанная с джиттером и буферизацией.

 

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

Т.е. если в потоке между ними должно быть 40 мс, то и сами UDP пакеты доберутся до приставки ровно через 40 мс.

 

Как только поток превращается в HTTP, то потери кадров заканчиваются, но возникает TCP jitter, который легко может колебаться до 300 мс. Характерное проявление этой проблемы — дергающийся звук, он в отличие от видео, гораздо больше подвержен колебаниям скорости поступления данных.

 

Для компенсации джиттера внедряют буфер. Если при этом поток идет с той же скоростью, с какой он и шел раньше, то клиент должен ждать лишние 2 секунды, пока не заполнится буфер.

 

Эта проблема решается при использовании HLS. Клиент скачивает на максимальной скорости сегмент, сразу наполняя буфер.

[Снежкин]

Эта проблема решается при использовании HLS.

если поток VBR - каков на ваш взгляд оптимальный размер буфера под сегмент?

[maxlapshin]

На мой взгляд, есть два варианта выбирать размер буфера: либо резать четко по GOP-ам: маленькие сегменты с плавающим размером, но удобно доставать из архива, либо резать штатно по 10 секунд, как предлагает эппл.

 

Учитывая, что плеер работает в keepalive режиме, то при отдаче через nginx разница невелика.

 

Сейчас в эрливидео схема такая: 10 секунд для эфира и по GOP-у для архива.

[danilbal]

Как только поток превращается в HTTP, то потери кадров заканчиваются, но возникает TCP jitter, который легко может колебаться до 300 мс. Характерное проявление этой проблемы — дергающийся звук, он в отличие от видео, гораздо больше подвержен колебаниям скорости поступления данных.

Насколько я понимаю, при переходе к TCP от UDP джиттер возникает в случае если были потери кадров, или, по-русски, если хреновая сеть.

То есть выходом как в варианте с TCP, так и в варианте с UDP вещанием может быть только приведение сети в порядок, буферы и прочее - это уже костыли.

 

А Вы большей частью занимаетесь рекламой конкретного решения:)

[maxlapshin]

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

 

При этом что творится у пользователей их мало интересует, зато очень интересно писать в форумы о том, как надо наводить порядок в сети. Лично я пока что не видел сети в которой большие объёмы UDP видео ходят без потерь.

[danilbal]

Сие утверждение на форуме провайдеров практически оскорбительно:)

 

Как тогда предоставлять услугу если она не качественна изначально?

 

Потери, как таковые, конечно есть... но по моим счетчикам целостности потока DVB они незначительны - за неделю порядка 100 cc ошибок несущественны.

 

Да и вообще, в нормально посчитанной и построенной сети кадрам теряться незачем: CRC ошибки на оптических линиях вполне решаются мотивацией монтажников, на меди абонентской - аналогично... Вопросы с нагрузкой в пиковые часы решаются приоритезацией. Но про сеть - это на самом деле в другой ветке форума - там много:)

[maxlapshin]

Я буду очень рад увидеть доказательство моей неправоты =)

 

Но пока что я не видел. Слышал про волшебные сети, в которых ничего не теряется и нет джиттера много. Но на поверку выяснялось, что вполне обычные условия: и потери, и перестановка пакетов.

Но это действительно вопрос отдельный.

 

Если же отвечать на вопрос топикстартера, то факт остается фактом: UDP _может_ терять пакеты, TCP _может_ добавлять джиттер и на это тоже надо рассчитывать.

[lllsergeyv]

Для преобразования в http пока остановились на relaying.

 

Возник другой вопрос: Какой программой можно под Linux в режиме онлайн сжать видеопоток (igmp или http) до 400кбит? Видел во flash некоторые запихивают... а чем? Сжать нужно 2-3 тв-канала.

Изменено 17 апреля, 2012 пользователем lllsergeyv

[s.lobanov]

lllsergeyv

vlc умеет(правда в бинарных сборках иногда не собирают с нужными кодеками)

[maxlapshin]

VLC действительно самый предпочтительный вариант из легкодоступных.

 

Он отличается от ffmpeg своим декодером mpeg2. В VLC более стабильный код, который показывет лучше результат, чем в ffmpeg.