shafiev Опубликовано 19 февраля, 2014 · Жалоба Коллеги, к сожалению у меня имеется очень много ADSL линков в которых моментами бывает потери пакетов. Если со скайпом возражений на потерю до 2 % пакетов нет , то с IPTV эти потери вызывают бурю негодования. Соответственно ищу способы или технологии для компенсации этого эффекта. Стрим в H.264 Multicast(можно и unicast тоже давать) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
danilbal Опубликовано 19 февраля, 2014 · Жалоба HTTP стримминг тут наверное поможет... Максим с Иваном тут на форуме апологеты такого способа и подробненько опишут по конкретным вопросам:) А вообще, 2% даже для ADSL и даже "моментами" - это много, я бы начал с вылизывания линий... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
shafiev Опубликовано 19 февраля, 2014 · Жалоба HTTP стримминг тут наверное поможет... Максим с Иваном тут на форуме апологеты такого способа и подробненько опишут по конкретным вопросам:) А вообще, 2% даже для ADSL и даже "моментами" - это много, я бы начал с вылизывания линий... Ну вылизывание линий, это значит нужно АТС подключать - а это ресурсы денег, + сам АТС с нами за ADSL клиентов борються, так что приходиться опять идти своим путем ) Будем ждать джедаев Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
danilbal Опубликовано 19 февраля, 2014 · Жалоба Так это вы конкурируете с Ростелекомом, арендуя у него линии для ADSL? Тогда в первую очередь их пи бить! Раз дают в аренду - пусть обеспечат!:) А вообще, да - это путь джедая:) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
shafiev Опубликовано 19 февраля, 2014 · Жалоба Так это вы конкурируете с Ростелекомом, арендуя у него линии для ADSL? Тогда в первую очередь их пи бить! Раз дают в аренду - пусть обеспечат!:) А вообще, да - это путь джедая:) Нет, я сейчас "варяжу" в соседней с ней стране, где есть такой же аналог Ростелеком, а точнее их тут 3 . Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 19 февраля, 2014 · Жалоба Если источник не далеко (пинг/ртт не большие) то можно попробовать на tcp/http переползти. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
shafiev Опубликовано 20 февраля, 2014 · Жалоба Если источник не далеко (пинг/ртт не большие) то можно попробовать на tcp/http переползти. RTT до 50 мс будут ли являться в данном случае - небольшими ? RTP/UDP в http посредством udpxy я так понимаю не пойдет? Надо в hls или что нить другое перегонять ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 21 февраля, 2014 · Жалоба Многовато, но нужно пробовать. На попробовать то он пойдёт вполне. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
shafiev Опубликовано 22 февраля, 2014 · Жалоба Многовато, но нужно пробовать. На попробовать то он пойдёт вполне. Ок. Мне также предлагали увеличить количество I-framе в исходном потоке h.264. Насколько это будет оправданно? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 23 февраля, 2014 · Жалоба Квадраты это не уберёт а поток вырастет ощутимо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
srg555 Опубликовано 23 февраля, 2014 · Жалоба К сожаленью, кроме tcp, рабочих проверенных вариантов нет, так что запасайтесь серверами. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Neko-san Опубликовано 24 февраля, 2014 · Жалоба HLS прикольнее, чем обычный MPEG-TS over HTTP. Попутно бонус - гораздо шире список клиентских устройств куда его можно загнать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Kompik Опубликовано 24 февраля, 2014 · Жалоба Есть технологии восстановления потерянного UDP потока. Но тут несколько вопросов: - на чем пользователи смотрять мультикаст? - Есть ли возможность встроить "клиента" в средства просмотра? - Сколько пользователей надо "править"? Суть технологии проста. Устанавливается сервер, который принимает все multicast потоки и держит небольшой буффер этих потоков. На клиентском устройстве, в случае потери пакета/ов идет запрос на получение потерянного пакета. Сервер отправляет потерянные данные клиенту, и плеер клиента восстанавливает поток. В итоге пользователь имеет стабильную картинку и бонусом получает быстрое переключение каналов :) Сервер стоит 3-4К баксов. Точная стоимость определяется исходя из количества телеканалов. При желании можно использовать свой сервер. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
shafiev Опубликовано 24 февраля, 2014 · Жалоба HLS прикольнее, чем обычный MPEG-TS over HTTP. Попутно бонус - гораздо шире список клиентских устройств куда его можно загнать. Ок. это верно .думаю взять, HDS? Как более продвинутый. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
shafiev Опубликовано 24 февраля, 2014 · Жалоба Есть технологии восстановления потерянного UDP потока. Но тут несколько вопросов: - на чем пользователи смотрять мультикаст? - Есть ли возможность встроить "клиента" в средства просмотра? - Сколько пользователей надо "править"? Суть технологии проста. Устанавливается сервер, который принимает все multicast потоки и держит небольшой буффер этих потоков. На клиентском устройстве, в случае потери пакета/ов идет запрос на получение потерянного пакета. Сервер отправляет потерянные данные клиенту, и плеер клиента восстанавливает поток. В итоге пользователь имеет стабильную картинку и бонусом получает быстрое переключение каналов :) Сервер стоит 3-4К баксов. Точная стоимость определяется исходя из количества телеканалов. При желании можно использовать свой сервер. Клиенты сморят посредством vlc и set top box mag Насчет встроить клиента , теоритечески это можно Пользователь пока мало Подскажите что за софт будет юзаться на сервере? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Kompik Опубликовано 24 февраля, 2014 · Жалоба Если с помощью VLC, то в него что-то встроить проблематичнее. Проще в IPTV плеер или что-то аналогичное. Что касается MAG, то туда можно, но это называется или немного подправить прошивку своими силами и встроить необходимый модуль или попросить производителя. Софт делает фирма Qarva. Это платное, не фриварное решение. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Neko-san Опубликовано 26 февраля, 2014 · Жалоба Восстановление UDP есть фикция. Сам протокол не подразумевает проверки целостности при доставке и вообще ее подтверждение. Поэтому для решений проблем с потерями при передаче UDP используется избыточность. Грубо говоря с 1 полезным пакетом отправляется еще какое-то количество точно таких же. Глядишь, какой-нибудь один и дойдет. Если дойдут все - будет использован тот, который придет первым. Остальные будут отброшены. Бывают разные реализации, разные алгоритмы. Но смысл всегда один. Qarva же, судя по всему, просто комбинирует UDP+TCP. Либо вообще применяется только к TCP, на сайте много упоминаний OTT. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Kompik Опубликовано 26 февраля, 2014 · Жалоба А никто и не говорит что это все в рамках UDP протокола :) В данном случае речь идет о UDP+TCP, это верно. И данная технология позволяет восстанавливать любое количество потеряных UDP пакетов, которые доставляются уже конкретному пользователю по TCP соединению юникастом. Что касается карвы и OTT, то там это уже не используется, так как нет необходимости :) Данная технология только для Мультикаста. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 26 февраля, 2014 · Жалоба Порно какое то мультикастовое. 1. Для того чтобы пере запрашивать нужны серийники пакетов, в голом mpeg2-ts их практически нет, поэтому нужно заворачивать в RTP, а это оверхэд дополнительный. 2. После некоторого процента потерь всё это превращается в плохую реализацию по tcp: слишком дохрена будет в tcp исходящего для перезапроса. 3. Вроде что то подобное было отрытое в RTCP или подобных протоколах на rtp. 4. На серверах и клиентах нужно держать приличные кольцевые буфера чтобы иметь возможность компенсировать потери по времени. В случае голого tcp на клиенте можно держать меньшие буфера, потому что в случае отставания=потерь клиенту пакеты будут прилетать по порядку (возможны вариации в пределах окна отправки, которое на уровне 64кб и этим занимается стёк ос), в случае же мультикаста пакеты тупо будут лится и пофик что клиент не получил не достающие куски к фрагментам 30 секундной давности. Те это всё имеет какой то смысл (технический) только при мизерных потерях мультикаста, далее оно резко деградирует и становится корявой реализацией через tcp. И за это ещё платить и вкорячивать на сервера и клиентам. Проще сразу по tcp отдавать, хоть потоком хоть HLS - клиентам ничего впаривать не придётся. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
maxlapshin Опубликовано 26 февраля, 2014 · Жалоба Восстановление UDP работает следующим образом: 1) клиент подключается к стримеру по RTSP 2) просит проиграть канал 3) стример держит последний gop или больше в памяти и досылает его клиенту юникастом 4) как только историю плюнули клиенту, клиент переходит на приём мультикаста 5) данные передаются в mpegts завернутом в rtp, что бы были номера пакетов 6) клиент поддерживает у себя буфер. Если в этом буфере есть дырки, не хватает пакетов, он шлет RTCP NACK пакет 7) если пора проигрывать, а пакета всё нет, значит играем как есть с дырками и квадратами. Отличие от TCP в том, что сервер не будет затормаживаться на получение ACK от клиента, а клиент не шлет эти ACK. Т.е. получается эдакий полунадежный TCP. Вся эта штука работает на микрософтовском решении. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vladd Опубликовано 26 февраля, 2014 · Жалоба Отличие от TCP в том, что сервер не будет затормаживаться на получение ACK от клиента, а клиент не шлет эти ACK. Т.е. получается эдакий полунадежный TCP. Используем подобную технологию для передачи магистральных потоков через далекие расстояния по публичным сетям. По практике - 20% потерь компенсирует вообще без каких-либо проблем. То есть таких потерь, при которых tcp вообще перестает ворочаться, особенно с rtt более 100 мс. HD каналы с битрейтом 15-20 мбит/с идут идеально. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 27 февраля, 2014 · Жалоба С 20% потерь и tcp нормально на малых скоростях не будет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
shafiev Опубликовано 27 февраля, 2014 · Жалоба Восстановление UDP работает следующим образом: 1) клиент подключается к стримеру по RTSP 2) просит проиграть канал 3) стример держит последний gop или больше в памяти и досылает его клиенту юникастом 4) как только историю плюнули клиенту, клиент переходит на приём мультикаста 5) данные передаются в mpegts завернутом в rtp, что бы были номера пакетов 6) клиент поддерживает у себя буфер. Если в этом буфере есть дырки, не хватает пакетов, он шлет RTCP NACK пакет 7) если пора проигрывать, а пакета всё нет, значит играем как есть с дырками и квадратами. Отличие от TCP в том, что сервер не будет затормаживаться на получение ACK от клиента, а клиент не шлет эти ACK. Т.е. получается эдакий полунадежный TCP. Вся эта штука работает на микрософтовском решении. Ок , Макс пару вопросов, Этот RTCP нормально можно конвертнуть из моего исходного стрима посредством vlc или твоего ffmpeg? Как понять "Вся эта штука работает на микрософтовском решении." ? Понимать что все плееры от того же MAG и vlc не будут пахать? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
maxlapshin Опубликовано 27 февраля, 2014 · Жалоба 1,2 — для того, что бы заработала описанная конструкция, нужен специальный сервер и специальный клиент. Ни Mag, ни VLC, ни ffmpeg такого не умеют, увы =( Я видел такую систему работающую на микрософтовском сервере и с соответствующим клиентом на приставке. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
danilbal Опубликовано 28 февраля, 2014 · Жалоба А можно подробнее? Mediaroom или еще что? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...