Перейти к содержимому
Калькуляторы

Посоветуйте OTT Выбираем поставщика

Здравствуйте. В настоящий момент предоставляем для абонентов IPTV мультикаст потоком, но возникли сложности с доставкой сигнала и думаем перейти на OTT.

Соответственно, прошу совета в выборе поставщика OTT, удовлетворяющего требованиям:

1. Вещает ТВ-каналы

2. Работает по агентской схеме с интернет-провайдерами

3. Смотреть можно и с приставок, и с мобильных устройств, и с компьютеров

4. Поддержка приставок MAG-245 и Eltex NV-501

 

Пожелания:

1. Видеоархив (возможность перемотки и прочего)

2. Видеотека

3. Хорошая подборка каналов

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Здравствуйте. В настоящий момент предоставляем для абонентов IPTV мультикаст потоком, но возникли сложности с доставкой сигнала и думаем перейти на OTT.

Соответственно, прошу совета в выборе поставщика OTT, удовлетворяющего требованиям:

1. Вещает ТВ-каналы

2. Работает по агентской схеме с интернет-провайдерами

3. Смотреть можно и с приставок, и с мобильных устройств, и с компьютеров

4. Поддержка приставок MAG-245 и Eltex NV-501

 

Пожелания:

1. Видеоархив (возможность перемотки и прочего)

2. Видеотека

3. Хорошая подборка каналов

 

Обращайтесь к NextTV

 

Kirill Sergeev

TV Development Division

Nauka-Svyaz, LLC

Tel.: +7(495)502-9092 ext. 297

Fax: +7(495)937-3412

Mobile:+7(917) 588-7667, +7(926)230-2989

e-mail: k.sergeev@naukanet.ru

 

 

1. Вещает ТВ-каналы - да

2. Работает по агентской схеме с интернет-провайдерами - да (нет минимальных гарантий)

3. Смотреть можно и с приставок, и с мобильных устройств, и с компьютеров - да

4. Поддержка приставок MAG-245 и Eltex NV-501 - MAG 245/250 поддерживаем (шифрование Verimatrix), Eltex NV-501 - пока нет

 

Пожелания:

1. Видеоархив (возможность перемотки и прочего)- в работе

2. Видеотека - в работе

3. Хорошая подборка каналов - имеется (118 каналов, около 26 HD каналов, наличие премиальных HD каналов в Стартовом пакете (10 HD))

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А по юникасту есть что предложить?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Коллега Saab95,

У Вас личка не работает.

 

Да. Есть что предложить получше, чем - ititv ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

смотрешка

+

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Пишите на рабочую: ipopov@moyo.tv

 

MOYO BOX едет из-за границы, поэтому время доставки составляет 4-7 календарных дней.

 

Очень странно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Цитата

MOYO BOX едет из-за границы, поэтому время доставки составляет 4-7 календарных дней.

 

Много приставок в наличии

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

1. невысокая стоимость - чтобы продавать с хорошей наценкой юзерам

2. форм-фактор наверно не свисток,желательно с антеннкой

3. штоб не перегревался

4. с пультом удобным, hdmi кабель в комплекте

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

 

сам я давно покупал на али приставку mk808, но она уже устарела, слабовата.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

https://market.yandex.ru/catalog/54775/list?hid=4165204&how=aprice&priceto=6000&gfilter=2137106637%3A-1482190659&gfilter=2140213741%3Aselect&gfilter=2142559632%3Aselect&page=2

Притом я смотрел вообще любой хлам лишь бы UPnP/DLNA умел (соответственно и сеть была) и был пульт.

 

Дешевле 3 тыщ руб ничего нет на яндекс маркете в москве. Приличное где то от 5 тыщ начинается.

Года 4 назад были приставки без андройда но приличные от 2,2 тыщ, но потом они кончились и ценник на то что осталось дорос до 3,5 тыщ. Сейчас примерно они же по 5,5 тыщ стоят.

А насчёт наценки - можно и не мечтать, те же комп магазы не сильно то наценяют.

 

В связи с кризисом предлагаю двигать тему UPnP/DLNA в массы: от юзера любой девайс который умеет сеть и UPnP/DLNA, дальше в зависимости от схемы подключения, если через роутер то в настройках привязываем IP-MAC чтобы всегда были постоянными и пробрасываем UDP порт на 1900 на указанную железку, у себя прописываем SSDPd демону адрес сбонента чтобы он на него персонально юникастил анонсы.

Если у абонента несколько устройств то процедуру нужно будет проводить для каждого.

Топик: http://forum.nag.ru/forum/index.php?showtopic=86065

Юникаст я в демона ещё не добавлял, только эксперименты провёл что оно вот так работает.

Да, муторно немного но ультимативно дёшего.

 

И если хочется ободрать абонента то можно настраивать каждый отдельный девайс платно. (всмысле сами то девайсы настраивать не нужно, только проброс портов до них и анонсы на демоне где то у себя на сервере)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Мы одно время на роутерах поднимали DLNA, чтобы отдавать ТВ на всякие не-смарт телевизоры.

Но был большой минус - hls не работал, и мы от такой схемы ушли.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну не всем же интересно tcp тюнить, некоторые хотят работать, и раздавать видео контент ))

 

я вот для тестов как то запускал, есть за океяном один сервер

на нём статический видео файл, и вещает с него в http и в hls, пробовал и vlc и ffmpeg, одинаково глючные но все же тест не о том

 

у себя запускаю локально два плеера на http и на hls соурсы с этого сервера

 

через час полтора, там где http стрим, плеер затыкается, сначала с какими то залипающими паузами, потом тупо молчит, надо жать стоп и плей опять

 

и рядом другой плеер, который играет с этого же сервера hls контент, на нём все ровно, никаких пауз все играется замечательно

))

 

проблема залипания tcp в первом случае понятна,

и от нее избавится на 100% все равно не удасться, хотя подтюнить сервер можно, но вопрос зачем? hls играет и без тюнинга

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Там тюнинга 5 строчек, которые по хорошему и для HLS делать надо:

1. увеличить буфера сокета

2. выставить cc=htcp

3. убедится что SACK, rfc1323 и некоторые другие включены.

 

FFMpeg не пробовал на прямую, но mpv его юзает и проблем нет (буфера настраиваются и дефолты не плохие), vlc - ужасен, других слов нет: он зажимает приёмный буфер на сокете в результате не имеет ни "подушки" при лагах сети ни возможности разгонятся.

Самсунг имеет неплохие дефолты, инженера постарались.

 

А для HLS, вероятно, плеера выкачивают кусок целиком, что аналогично тому как если бы они имели нормальный по размеру буфер.

 

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

 

По поводу 100% - вы так говорите будто HLS работает через астрал а не через TCP.

Подозреваю что весь профит сводит к тому что:

- уродские плееры вынуждены сразу скачивать чанк а не по мере надобности подгружать мелкими блоками в ничтожный буфер

- дефолтный CC алгоритм TCP не успевает уронить скорость на таких не больших фрагментах, а плеер не использует кип-алив

- при выпадании одно и более чанков плееру легче перезапускатся

 

 

Мне лично намного проще дебажить одно TCP соединение с данными, чем тот бардак который порождает HLS.

Например.

Клиент подключился, запросил плей лист, распарсил и забрал первый из списка чанк (он же самый конец потока), далее сервер через 50мс обновил плей лист и грохнул этот самый старый чанк. В следующий раз клиент сделал всё тоже самое за 49 мс до смерти последнего чанка....и так далее пока однажды клиент не обнаруживает что один чанк либо недоступен либо версия плей листа различается не на 1 а на 2.

Ну ладно, по логам ещё можно отловить 404 на несуществующем чанке, а вот отловить что клиент подавился разницей версий плей листа на 2 и на этом сдох уже очень сложно.

(на самсунгах (как минимум на одном) и mpv с этим похоже порядок, а вот маги и элтексы пока не проверил)

 

И что ты с этим будешь делать?

Городить пачку костылей вокруг отдачи плей листа чтобы версия всегда различалась только на 1 для любого клиента?

Хранить/перенумеровать чанки?

Мне вот проще те 5 строчек тюнинга TCP сделать и настройками msd поиграть в небольших пределах.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

зато плеер может сделать упреждающее чтение. плюс, hls удобен для дистрибьюции, когда у тебя десяток точек трансляции по миру.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У меня "упреждающее чтение" = прекеш давно реализовано, без всякого хлс.

 

Это его не основное преимущество, и собственно гнать мультикаст в туннелях проще.

ХЛС +:

1. Клиентам проще рестартится при больших потерях

2. Вся криптография для дрм открытая, стандартная и понятная, не то что в MPEG2-TS - те нахер всех производителей CAS систем за $$$$$ баксов, достаточно проца с AES-NI и обычного софта, хоть из костылей на скриптах и опенссл.

3. Есть доступные, бесплатные и понятные программы типа nginx для раздачи.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Знаешь чем айсстрим плох для телевидения? кроме того что его пытаются писать люди далекие от iptv

Тем что он берет mpeg и режит как попало(даже не уверен по тс фрагментам ли), пытается раздувать это как то по сети, а потом клеит как есть.

Против того же goalbit или live bittorent, или сопкаст, итд которые резали(жут) четко по "гопам"

а если еще и по udp как это делал live bt или делает sopcast то вообще красота получается, намного качественнее чем известно что.

 

Догадываешься теперь чем http стриминговый хуже чем hls ? Потеряв синхру, плееру нужно очень много телодвижений что бы все это восстановить.

И на экране само собой будет в это время какая нибудь цветная каша. Если не хуже и плеер просто отрубится.

 

А ts в hls сегмент просто перетянется. Он уже порезан по кей фреймам если енкодер корректно бьет по 10сек. Поэтому hls на порядок качественнее для передачи контента.

 

И что ты с этим будешь делать?

Городить пачку костылей вокруг отдачи плей листа чтобы версия всегда различалась только на 1 для любого клиента?

Хранить/перенумеровать чанки?

)) что, зачем, почему... AvProxy с форума астры это все делает, ничего переименовывать не надо, все в памят, а что не делает подправлю ;)

Изменено пользователем paradox_

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

а как может потеряться синхронизация в tcp, если конечно сервер не выбрасывает данные?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У меня "упреждающее чтение" = прекеш давно реализовано, без всякого хлс.

смотри. бывают просто плохие каналы, где rtt может взлетать до 200-300ms и ещё есть пакетлосс. tcp такие штуки очень плохо отрабатывает, да и тюнить стек на всех клиентских приставках - это умереть можно. а у hls сегментики можно в несколько потоков тягать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

tcp пакет лост, mpegts потеря синхры, дальше ищем 0x47, потом ждем кейфрем, и хорошо если плеер помнит pat/pmt, а то еще дольше ждем

 

а есть еще мерзке провайдеры со всякими интрудерами или заумными шейперами, там вообще http стриминг который пытается отставивать Иван, умрет.

но их можно обходить, мелкие кратковременные коннекты для стягиваня ts hls сегментов очень себя хорошо чувствуют.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

если в tcp потеряется пакет, то приставка будет стоять и ждать, пока не получит следующий пакет.

 

Это же tcp: либо получаем целые данные по порядку, либо не получаем ничего.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Догадываешься теперь чем http стриминговый хуже чем hls ? Потеряв синхру, плееру нужно очень много телодвижений что бы все это восстановить. И на экране само собой будет в это время какая нибудь цветная каша. Если не хуже и плеер просто отрубится.

Не лучше он.

Постоянное дрочево запросами, выше оверхэд.

Плеер должен сам переподключаться (в моём случае он получит точно также как и в HLS всё что нужно), по хорошему, но мало кто пишет сетевые плееры, обычно они играют файлы с диска и между делом ещё как то с сетью работают.

 

А ts в hls сегмент просто перетянется. Он уже порезан по кей фреймам если енкодер корректно бьет по 10сек. Поэтому hls на порядок качественнее для передачи контента.

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

 

)) что, зачем, почему... AvProxy с форума астры это все делает, ничего переименовывать не надо, все в памят, а что не делает подправлю ;)

Опять рекламируешь?

 

а есть еще мерзке провайдеры со всякими интрудерами или заумными шейперами, там вообще http стриминг который пытается отставивать Иван, умрет. но их можно обходить, мелкие кратковременные коннекты для стягиваня ts hls сегментов очень себя хорошо чувствуют.

Гнать там юдп по л2тп или ещё что думать, да хоть хлс.

Я и не говорил что это универсальное решение, но у меня достаточно хорошо работает.

 

смотри. бывают просто плохие каналы, где rtt может взлетать до 200-300ms и ещё есть пакетлосс. tcp такие штуки очень плохо отрабатывает, да и тюнить стек на всех клиентских приставках - это умереть можно. а у hls сегментики можно в несколько потоков тягать.

Можно, но клиенты этого никогда не делают.

Кроме того, основной тюнинг делается на сервере, и для hls он тоже весьма полезен.

Те я к тому, что hls при таких херовых условиях не сильно лучше будет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Догадываешься теперь чем http стриминговый хуже чем hls ? Потеряв синхру, плееру нужно очень много телодвижений что бы все это восстановить. И на экране само собой будет в это время какая нибудь цветная каша. Если не хуже и плеер просто отрубится.

Не лучше он.

Постоянное дрочево запросами, выше оверхэд.

это всё - копейки на фоне веса одного сегмента. особенно, если пожать gzip'ом.

 

 

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

пару минут хранить не проблема. при размере чанка в 5с у клиента неплохой бюджет по времени.

 

 

Я и не говорил что это универсальное решение, но у меня достаточно хорошо работает.

works for me - это плохой аргумент. можно ведь вспомнить болезных авторов протокола utp :)

 

смотри. бывают просто плохие каналы, где rtt может взлетать до 200-300ms и ещё есть пакетлосс. tcp такие штуки очень плохо отрабатывает, да и тюнить стек на всех клиентских приставках - это умереть можно. а у hls сегментики можно в несколько потоков тягать.

Можно, но клиенты этого никогда не делают.

Кроме того, основной тюнинг делается на сервере, и для hls он тоже весьма полезен.

Те я к тому, что hls при таких херовых условиях не сильно лучше будет.

это вполне реализуется что на дюне, что на маге и упирается в умение клиента запускать несколько закачек и проставлять http-заголовки :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.