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

Борьба с квадратиками в IPTV Ищу помехоустойчивой IPTV стрим

Коллеги, к сожалению у меня имеется очень много ADSL линков в которых моментами бывает потери пакетов.

Если со скайпом возражений на потерю до 2 % пакетов нет , то с IPTV эти потери вызывают бурю негодования. Соответственно ищу способы или технологии для компенсации этого эффекта.

Стрим в H.264 Multicast(можно и unicast тоже давать)

Share this post


Link to post
Share on other sites

HTTP стримминг тут наверное поможет... Максим с Иваном тут на форуме апологеты такого способа и подробненько опишут по конкретным вопросам:)

А вообще, 2% даже для ADSL и даже "моментами" - это много, я бы начал с вылизывания линий...

Share this post


Link to post
Share on other sites

HTTP стримминг тут наверное поможет... Максим с Иваном тут на форуме апологеты такого способа и подробненько опишут по конкретным вопросам:)

А вообще, 2% даже для ADSL и даже "моментами" - это много, я бы начал с вылизывания линий...

 

Ну вылизывание линий, это значит нужно АТС подключать - а это ресурсы денег, + сам АТС с нами за ADSL клиентов борються, так что приходиться опять идти своим путем )

 

 

Будем ждать джедаев

Share this post


Link to post
Share on other sites

Так это вы конкурируете с Ростелекомом, арендуя у него линии для ADSL?

Тогда в первую очередь их пи бить! Раз дают в аренду - пусть обеспечат!:)

 

А вообще, да - это путь джедая:)

Share this post


Link to post
Share on other sites

Так это вы конкурируете с Ростелекомом, арендуя у него линии для ADSL?

Тогда в первую очередь их пи бить! Раз дают в аренду - пусть обеспечат!:)

 

А вообще, да - это путь джедая:)

 

 

Нет, я сейчас "варяжу" в соседней с ней стране, где есть такой же аналог Ростелеком, а точнее их тут 3 .

Share this post


Link to post
Share on other sites

Если источник не далеко (пинг/ртт не большие) то можно попробовать на tcp/http переползти.

Share this post


Link to post
Share on other sites

Если источник не далеко (пинг/ртт не большие) то можно попробовать на tcp/http переползти.

  1. RTT до 50 мс будут ли являться в данном случае - небольшими ?
  2. RTP/UDP в http посредством udpxy я так понимаю не пойдет? Надо в hls или что нить другое перегонять ?

Share this post


Link to post
Share on other sites

Многовато, но нужно пробовать.

На попробовать то он пойдёт вполне.

Share this post


Link to post
Share on other sites

Многовато, но нужно пробовать.

На попробовать то он пойдёт вполне.

 

Ок. Мне также предлагали увеличить количество I-framе в исходном потоке h.264. Насколько это будет оправданно?

Share this post


Link to post
Share on other sites

Квадраты это не уберёт а поток вырастет ощутимо.

Share this post


Link to post
Share on other sites

К сожаленью, кроме tcp, рабочих проверенных вариантов нет, так что запасайтесь серверами.

Share this post


Link to post
Share on other sites

HLS прикольнее, чем обычный MPEG-TS over HTTP. Попутно бонус - гораздо шире список клиентских устройств куда его можно загнать.

Share this post


Link to post
Share on other sites

Есть технологии восстановления потерянного UDP потока.

 

Но тут несколько вопросов:

- на чем пользователи смотрять мультикаст?

- Есть ли возможность встроить "клиента" в средства просмотра?

- Сколько пользователей надо "править"?

 

Суть технологии проста.

Устанавливается сервер, который принимает все multicast потоки и держит небольшой буффер этих потоков.

На клиентском устройстве, в случае потери пакета/ов идет запрос на получение потерянного пакета. Сервер отправляет потерянные данные клиенту, и плеер клиента восстанавливает поток.

В итоге пользователь имеет стабильную картинку и бонусом получает быстрое переключение каналов :)

 

Сервер стоит 3-4К баксов. Точная стоимость определяется исходя из количества телеканалов.

При желании можно использовать свой сервер.

Share this post


Link to post
Share on other sites

HLS прикольнее, чем обычный MPEG-TS over HTTP. Попутно бонус - гораздо шире список клиентских устройств куда его можно загнать.

 

Ок. это верно .думаю взять, HDS? Как более продвинутый.

Share this post


Link to post
Share on other sites

Есть технологии восстановления потерянного UDP потока.

 

Но тут несколько вопросов:

- на чем пользователи смотрять мультикаст?

- Есть ли возможность встроить "клиента" в средства просмотра?

- Сколько пользователей надо "править"?

 

Суть технологии проста.

Устанавливается сервер, который принимает все multicast потоки и держит небольшой буффер этих потоков.

На клиентском устройстве, в случае потери пакета/ов идет запрос на получение потерянного пакета. Сервер отправляет потерянные данные клиенту, и плеер клиента восстанавливает поток.

В итоге пользователь имеет стабильную картинку и бонусом получает быстрое переключение каналов :)

 

Сервер стоит 3-4К баксов. Точная стоимость определяется исходя из количества телеканалов.

При желании можно использовать свой сервер.

 

  1. Клиенты сморят посредством vlc и set top box mag
  2. Насчет встроить клиента , теоритечески это можно
  3. Пользователь пока мало

Подскажите что за софт будет юзаться на сервере?

 

 

 

Share this post


Link to post
Share on other sites

Если с помощью VLC, то в него что-то встроить проблематичнее.

Проще в IPTV плеер или что-то аналогичное.

 

Что касается MAG, то туда можно, но это называется или немного подправить прошивку своими силами и встроить необходимый модуль или попросить производителя.

 

Софт делает фирма Qarva. Это платное, не фриварное решение.

Share this post


Link to post
Share on other sites

Восстановление UDP есть фикция. Сам протокол не подразумевает проверки целостности при доставке и вообще ее подтверждение. Поэтому для решений проблем с потерями при передаче UDP используется избыточность. Грубо говоря с 1 полезным пакетом отправляется еще какое-то количество точно таких же. Глядишь, какой-нибудь один и дойдет. Если дойдут все - будет использован тот, который придет первым. Остальные будут отброшены. Бывают разные реализации, разные алгоритмы. Но смысл всегда один.

 

Qarva же, судя по всему, просто комбинирует UDP+TCP. Либо вообще применяется только к TCP, на сайте много упоминаний OTT.

Share this post


Link to post
Share on other sites

А никто и не говорит что это все в рамках UDP протокола :)

 

В данном случае речь идет о UDP+TCP, это верно.

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

 

Что касается карвы и OTT, то там это уже не используется, так как нет необходимости :)

Данная технология только для Мультикаста.

Share this post


Link to post
Share on other sites

Порно какое то мультикастовое.

 

1. Для того чтобы пере запрашивать нужны серийники пакетов, в голом mpeg2-ts их практически нет, поэтому нужно заворачивать в RTP, а это оверхэд дополнительный.

2. После некоторого процента потерь всё это превращается в плохую реализацию по tcp: слишком дохрена будет в tcp исходящего для перезапроса.

3. Вроде что то подобное было отрытое в RTCP или подобных протоколах на rtp.

4. На серверах и клиентах нужно держать приличные кольцевые буфера чтобы иметь возможность компенсировать потери по времени.

В случае голого tcp на клиенте можно держать меньшие буфера, потому что в случае отставания=потерь клиенту пакеты будут прилетать по порядку (возможны вариации в пределах окна отправки, которое на уровне 64кб и этим занимается стёк ос), в случае же мультикаста пакеты тупо будут лится и пофик что клиент не получил не достающие куски к фрагментам 30 секундной давности.

 

Те это всё имеет какой то смысл (технический) только при мизерных потерях мультикаста, далее оно резко деградирует и становится корявой реализацией через tcp.

И за это ещё платить и вкорячивать на сервера и клиентам.

Проще сразу по tcp отдавать, хоть потоком хоть HLS - клиентам ничего впаривать не придётся.

Share this post


Link to post
Share on other sites

Восстановление UDP работает следующим образом:

 

1) клиент подключается к стримеру по RTSP

2) просит проиграть канал

3) стример держит последний gop или больше в памяти и досылает его клиенту юникастом

4) как только историю плюнули клиенту, клиент переходит на приём мультикаста

5) данные передаются в mpegts завернутом в rtp, что бы были номера пакетов

6) клиент поддерживает у себя буфер. Если в этом буфере есть дырки, не хватает пакетов, он шлет RTCP NACK пакет

7) если пора проигрывать, а пакета всё нет, значит играем как есть с дырками и квадратами.

 

Отличие от TCP в том, что сервер не будет затормаживаться на получение ACK от клиента, а клиент не шлет эти ACK.

Т.е. получается эдакий полунадежный TCP.

 

 

Вся эта штука работает на микрософтовском решении.

Share this post


Link to post
Share on other sites

Отличие от TCP в том, что сервер не будет затормаживаться на получение ACK от клиента, а клиент не шлет эти ACK.

Т.е. получается эдакий полунадежный TCP.

 

Используем подобную технологию для передачи магистральных потоков через далекие расстояния по публичным сетям. По практике - 20% потерь компенсирует вообще без каких-либо проблем. То есть таких потерь, при которых tcp вообще перестает ворочаться, особенно с rtt более 100 мс. HD каналы с битрейтом 15-20 мбит/с идут идеально.

Share this post


Link to post
Share on other sites

С 20% потерь и tcp нормально на малых скоростях не будет.

Share this post


Link to post
Share on other sites

Восстановление UDP работает следующим образом:

 

1) клиент подключается к стримеру по RTSP

2) просит проиграть канал

3) стример держит последний gop или больше в памяти и досылает его клиенту юникастом

4) как только историю плюнули клиенту, клиент переходит на приём мультикаста

5) данные передаются в mpegts завернутом в rtp, что бы были номера пакетов

6) клиент поддерживает у себя буфер. Если в этом буфере есть дырки, не хватает пакетов, он шлет RTCP NACK пакет

7) если пора проигрывать, а пакета всё нет, значит играем как есть с дырками и квадратами.

 

Отличие от TCP в том, что сервер не будет затормаживаться на получение ACK от клиента, а клиент не шлет эти ACK.

Т.е. получается эдакий полунадежный TCP.

 

 

Вся эта штука работает на микрософтовском решении.

 

Ок , Макс пару вопросов,

  1. Этот RTCP нормально можно конвертнуть из моего исходного стрима посредством vlc или твоего ffmpeg?
  2. Как понять "Вся эта штука работает на микрософтовском решении." ? Понимать что все плееры от того же MAG и vlc не будут пахать?

 

 

 

Share this post


Link to post
Share on other sites

1,2 — для того, что бы заработала описанная конструкция, нужен специальный сервер и специальный клиент. Ни Mag, ни VLC, ни ffmpeg такого не умеют, увы =(

 

Я видел такую систему работающую на микрософтовском сервере и с соответствующим клиентом на приставке.

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