[shafiev]

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

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

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

[danilbal]

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

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

[shafiev]

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

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

 

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

 

 

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

[danilbal]

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

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

 

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

[shafiev]

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

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

 

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

 

 

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

[Ivan_83]

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

[shafiev]

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

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

[Ivan_83]

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

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

[shafiev]

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

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

 

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

[Ivan_83]

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

[srg555]

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

[Neko-san]

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

[Kompik]

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

 

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

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

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

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

 

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

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

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

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

 

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

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

[shafiev]

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

 

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

[shafiev]

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

 

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

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

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

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

 

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

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

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

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

 

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

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

 

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

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

 

 

 

[Kompik]

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

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

 

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

 

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

[Neko-san]

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

 

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

[Kompik]

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

 

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

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

 

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

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

[Ivan_83]

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

 

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

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

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

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

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

 

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

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

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

[maxlapshin]

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

 

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

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

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

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

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

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

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

 

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

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

 

 

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

[vladd]

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

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

 

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

[Ivan_83]

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

[shafiev]

Восстановление 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 не будут пахать?

 

 

 

[maxlapshin]

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

 

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

[danilbal]

А можно подробнее? Mediaroom или еще что?