[paradox_]

стрельба из пушки по воробьям это не практика, это развлечение

[Sergey R.]

У парадокса боязнь протокола ртп. По выходным. Так боюсь оверхеда в несколько байт что ни качественная передача ни качетсвенный мониторинг и дебаг не интересен.

[Ivan_83]

12 часов назад, Sergey R. сказал:

Точнее не совсем софт а cisco dcm9902 и ресиверы гармоник.

Ну вот, это скорее внутренности оператора.

 

12 часов назад, Sergey R. сказал:

И вот эта штучка думаю тебе знакомая умеет разбивать на две копии и склеивать наверняка с реодером. https://code.videolan.org/videolan/multicat Но её не юзал.

Нет, у меня не было задач с транспортом этого куда то.

Разве что я одно время к себе домой мультикаст забирал телек пялить, и он шёл петлёй через москву, я тогда в сибири жил :)

 

12 часов назад, Sergey R. сказал:

TCP там тоже не поплодишь, потоков тысяча. 

Ну как бы для TCP количество не важно.

 

11 часов назад, Sergey R. сказал:

Во вложении наглядно расписано насколько ущербный голый mpegts в плане диагностики.

Да, я понял к чему ты ведёшь.

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

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

 

10 часов назад, LostSoul сказал:

Для mpeg-ts для linux есть эффективный модуль ядра, позволяющий подписываться и мониторить  multicast mpegts потоки , собирая статистику cc reorder , drop и прочего.

причем работает он так шустро, что не грузит cpu даже на слабеньких stb ,  а средний сервер легко мониторит гигабиты.

Можно легко портировать во фрю :)

Там нынче вроде чего то наворотили с зерокопи и в юзерспейсе оно не сильно больше будет жрать. Хотя даже и без зерокопи копирование памяти не сильно напряжная операция.

 

9 часов назад, Sergey R. сказал:

У парадокса боязнь протокола ртп. По выходным. Так боюсь оверхеда в несколько байт что ни качественная передача ни качетсвенный мониторинг и дебаг не интересен.

fun fact: у астры ртп был коряво сделан и когда какой то московский пров стал вещать в ртп и там было опциональное поле/атрибут то астра не понимала такой траф. А udpxy понимал и msd тоже понимало. :)

Это уже давно пофиксили.

[paradox_]

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

 

ну то не беда, может лет через 10 активной стрельбы из пушки, научитесь прицеливаться и метко стрелять из рогатки

 

Изменено 27 апреля, 2019 пользователем paradox_

[Sergey R.]

я думаю что не понимаешь как работают сети именно ты.

реально не выяснив тонкости, выносишь какие-то заключения

ничего не привел в примеры. лозунги "я знаю как работает iptv", "не тебе меня учить" и прочее.

сценариев использования голого mpeg ts и оверхеда в виде ртп не привел

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

но нет только лозунги

 

примеры опиши. что ты делал на голом мпег. что ты делал на ртп(если делал) и почему делал

и для кого делал. кто тебя оценивал. сам сделал сам себе сказал молодец? или проект какой пили для общественности

 

непонятно заведомо негативное отношения) описывается практика использования.

Иван вот сверху в посте понимает к чему я веду) он с этим делом работал. а тут прям иди отсюда всё не правильно

 

я тебе тоже могу сказать 

 

как ты только сети то диагностируешь всех сетевиков измучил поди. по cc errors считаешь потери? добавь оверхед и будут все на нормальном языке тебя понимать

 

 

36 минут назад, Ivan_83 сказал:

 

fun fact: у астры ртп был коряво сделан и когда какой то московский пров стал вещать в ртп и там было опциональное поле/атрибут то астра не понимала такой траф. А udpxy понимал и msd тоже понимало. :)

Это уже давно пофиксили.

не только) у ffmpeg тоже с ртп глюк не хилый был. На примем. Если несколько потоков брать то он в буфере перемешивал всё и каша получалась.

и оно да отпугивает. думаешь что это проблема с ртп а на деле в софте ошибка.

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

а ртп делался для облегчения жизни. даёт много плюшек которые не дает обычный мпег

сейчас я за его использование

 

 

Изменено 27 апреля, 2019 пользователем Sergey R.

[Sergey R.]

43 минуты назад, Ivan_83 сказал:

Ну вот, это скорее внутренности оператора.

 

 

Не совсем оператора. Тут уже фактор известных вендоров. У меня куча вещателей контента, это тв студии. Они перед тем как ко мне обратиться рынок шарят и железки выбирают. А там знай они лезут к циско, гармоникам, эриксонам и прочим. 

И там все стандартно - хочешь надежной передачи - выбирай rtp + fec.

От использования этих фишек люди в восторге были не нужно вылизывать канал связи.

И это правильно - вылизывание канала связи в некоторых случаях было не возможным.

 

52 минуты назад, Ivan_83 сказал:

 

Ну как бы для TCP количество не важно.

 

 

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

zixi брали для некоторых, но очень дорого выходили. лицензия на меся на один канал за 100тыс рублей если не ошибаюсь

 

сейчас вот когда раздаю тв для хомячков да. проблем никаких. hls через nginx, только в бой

 

 

 

[Sergey R.]

13 часов назад, paradox_ сказал:

 

 

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

сценарий использования давай описывай

мту он накрутил

тебе про конкретные кейсы

я у себя тоже накручу и скажу я молодец

а ТС может собрался по миру ТВ передавать, да такие проекты есть сейчас, IX ы за них взялись, дошло 10 лет спустя. Да у них всё выглядит жалко, они как ты по голому мпег передают но поумнеют.

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

сервис уже будет испорчен

 

про qos не забудь да крути так чтобы у тебя метки проставлялись и другие железки их ловили

сам не сделаешь потом у соседей рассыпаться всё начнет, тут надо тебе мозг выносить

 

у меня сложилось мнение что ты делаешь всё сам и оцениваешь себя сам

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

 

Изменено 27 апреля, 2019 пользователем Sergey R.

[Sergey R.]

2 часа назад, Ivan_83 сказал:

 

Да, я понял к чему ты ведёшь.

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

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

 

 

Иван если ты говоришь к тебе пристают не ходи к ним) 

Странные ебени и MSK-IX.

Всё так. По  ртп чекаются стримы c заворотом в Москву во всех городах N. 

Вроде как тех представление о состоянии есть. Но не понятно есть ли проблема) Точка фиксации потерь RTP в Москве, может оно потерялось и назад и в городе N всё ок.

Все стандартные их службы в разносе от таких новостей.  Они 20 лет изучали сети а тут такое)

Нагрузка ложиться на инженера что ищут по неадекватному ценнику.

 

 

 

[maxlapshin]

Коллеги, вы как-то странно спорите о mpegts vs rtp.


В mpegts счетчик есть и это  СС. Он идет на каждый пид, а не на сетевой пакет и он такой маленький (4 бита), что фактически им пользоваться для перестановки пакетов не имеет смысла, потому что его оборот очень быстро наступает.

В rtp счетчик двухбайтный, поэтому его оборот не является проблемой для целей перестановки пакетов.

 

 

[Sergey R.]

Максим. Все верно. Я это использую весьма успешно.

Для чего спор разводят не понятно.

Протокол который успешно позволяет проблемы решать называют мусорои и лишним оверхедом.

 

Максим, а вот вопрос. Я несколько лет назад ещё флусоник смотрел,  мне там ртп понадобился.

Ты отвечал по-моему, что ртп не тестировался, т к операторы его не используют.

 

Сейчас ситуация не изменилась? Операторы не в курсе что использование этого сервис им поможет улучшить?

Я думаю что юзать его не то что желательно а ОБЯЗАТЕЛЬНО всегда.

Зачем мой сервис будет страдать из-за возникшей перестановки пакетов.

Единственное ограничение - какой-то капризный девайс, который не поддерживает ртп.

 

Изменено 28 апреля, 2019 пользователем Sergey R.

[maxlapshin]

К нам очень мало кто обращается по поводу мультикаст в rtp обертке.

 

Транзит, особенно межоператорский, по нашему опыту — это HLS или на крайний случай http mpegts. Ну или без каких-либо mpls прямой стык с udp, т.е. реордеринг то редкий.

 

[paradox_]

можно ли из пушки убить воробья ? да, можно

в теме пытаются  доказывать что это можно, кеп этого никто не отрицает

 

что бы убить воробья, достаточно рогатки и умения из нее стрелять

 

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

и замочит всю живность вокруг

чем возьмет книгу по сетям и изучит матчасть и бережно относясь к экологии и окружающим настроит ее

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

 

 

[maxlapshin]

Поэтичные аллегории — это так красиво. Но к сожалению, совершенно непонятно, как они помогают обсудить инженерный вопрос.

[vurd]

3 часа назад, paradox_ сказал:

можно ли из пушки убить воробья ? да, можно

в теме пытаются  доказывать что это можно, кеп этого никто не отрицает

 

что бы убить воробья, достаточно рогатки и умения из нее стрелять

 

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

и замочит всю живность вокруг

чем возьмет книгу по сетям и изучит матчасть и бережно относясь к экологии и окружающим настроит ее

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

 

 

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

[LostSoul]

3 часа назад, maxlapshin сказал:

Транзит, особенно межоператорский, по нашему опыту — это HLS или на крайний случай http mpegts. 

  

смешно да.

это какой-то такой "межоператорский транзит" а-ля смотрешка?

 

 

10 минут назад, vurd сказал:

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

это задача решаема только с оговоркой, что оно будет "как-нибудь показывать".    по другому никак.

 

[paradox_]

поэтические аллегории нужны что бы не переходить а мат

 

по ссылкам выше не вижу смысла звонить потому как 1) не имею отношение в РФ, 2) ценник надо минимум на 4 умножать

[Sergey R.]

Напрасно негатив идет.

Бизнес запущен и вполне функционирует.

 

Известные компании типа Виасата платят денежки. Сигнал идет из Лондона в Прибалтику.

Из Прибалтики двумя цепочками, с заголовками RTP. Да через операторские стыки.

Склеиваются в Москве. Далее рекламные врезки, все дела, в Орин Экспресс в Долгопрудный, который поднимает это на 85.2E.

Я думаю что у того что принимает потоки в 85.2 вопросов никаких.

Т.е. RTP и ethernet всё это позволяет сделать.

 

Боевой проект так скажем, не вижу проблем.

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

 

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

  

[fox_m]

В 26.04.2019 в 17:39, Sergey R. сказал:

Не согласен, в mpegts есть счётчик который обнуляется.

Ну вижу я сс еррор, это значит счётчик сбился.

А почему? Пакеты местами поменялись? Потерялись? А сколько их потерялось?

Какая железка имея на входе два потока в голом udp/mpegts сможет бесшовно прыгнуть с потока на поток? У кого есть DCM попробуйте)

У нас как раз DCM9902. У нас для большинства каналов (mpeg-ts) есть резервные потоки. Абсолютно бесшовно конечно не получится сделать. В любом случае будет небольшое кол-во CC ошибок, при падении основного потока. Кстати, DCM умеет RTP инкапсуляцию.

 

В 26.04.2019 в 22:26, Sergey R. сказал:

Так. Еще дополню важный момент. С помощью RTP делается реодеринг. Например, пакеты перепутались местами, в сетях MPLS это не редкость. Так вот если клиентская STB умеет реодеринг, то она соберет пакеты и картинка не рассыпится.

Короче я бы рекомендовал использовать RTP как у магистралов, без RTP им как следует транспорт не организовать: гоню поток из Парижа во Владивосток - по пути куча транзита который лагает. Пускаю потоки одинаковые через несколько транзитов и во Владике склеиваю и получаю идеал.

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

 

 

 

Подскажите, вот у нас между площадками гонится около 1Гб мультика. Сейчас это udp\mpeg-ts. Железо которое генерирует и принимает мультик умеет udp и rtp. Имеет смысл переходить на RTP? Каналы между площадками арендуем. 

Изменено 30 апреля, 2019 пользователем fox_m

[fox_m]

Кстати, мы сейчас гоним часть потоков в Intelsat. Так вот, одно из их требований - использование именно RTP. Наверно это не просто так.

[Sergey R.]

Ну так. Все хотят выжить из инфрастуктуры максимум. Мне газкомы мозг полоскали за один утеренный пакет в сутки, пока им ртп+fec не включили. Цель у них была также на спутник поднять.

[fox_m]

8 минут назад, Sergey R. сказал:

Ну так. Все хотят выжить из инфрастуктуры максимум. Мне газкомы мозг полоскали за один утеренный пакет в сутки, пока им ртп+fec не включили. Цель у них была также на спутник поднять.

Мы тоже подаем, правда не в таких масштабах) Кстати, вы не в Медиалогистике работаете?

[Sergey R.]

Работал. Мне за три года мозг вынесли так что уже всё. Но если что спрашивайте опыт то остался.

 

У интелсата я бы прямо спросил зачем им. У меня прямо ртп не спршивали а был вынос мозга. От всех кто на спутник поднимает 0 потерь хотели. Приходилось давить на вещателя чтобы rtp с фек врубали.

 

Синтера вот мне говорили внутри себя двумя цепочками гнала и склеивала потом. Но нам уже без ртп сливали. Наверное что похуже то конкурентам давали)

[fox_m]

Кстати, а вот есть такой стандарт smpte 2022. Он как-то связан с RTP. Вы с таким не сталкивались?

[Sergey R.]

Так я подозреваю это всё из раздела:

• ST 2022-1:2007 - Forward Error Correction for Real-Time Video/Audio Transport Over IP Networks
• ST 2022-5:2013 - Forward Error Correction for Transport of High Bit Rate Media Signals over IP Networks (HBRMT)
• ST 2022-7:2013 - Seamless Protection Switching of SMPTE ST 2022 IP Datagrams

т е что я озвучивал нужно для надежного транспорта.

Это FEC, без RTP его не бывает.

Seamless Protection Switching - бесшовное переключение/склеивание

Без RTP все это не реализовать.

 

Медиалогистика на процентов 5ть эти механизмы поддерживает. Самое самое так скажем при транспорте из США либо с Кипра.

 

 

 

[fox_m]

1 минуту назад, Sergey R. сказал:

Так я подозреваю это всё из раздела:

• ST 2022-1:2007 - Forward Error Correction for Real-Time Video/Audio Transport Over IP Networks
• ST 2022-5:2013 - Forward Error Correction for Transport of High Bit Rate Media Signals over IP Networks (HBRMT)
• ST 2022-7:2013 - Seamless Protection Switching of SMPTE ST 2022 IP Datagrams

т е что я озвучивал нужно для надежного транспорта.

Это FEC, без RTP его не бывает.

Seamless Protection Switching - бесшовное переключение/склеивание

Без RTP все это не реализовать.

 

Медиалогистика на процентов 5ть эти механизмы поддерживает. Самое самое так скажем при транспорте из США либо с Кипра.

 

 

 

Да, походу из этой серии. Да еще хотел спросить. Если он умеет FEC, то по получается, что добавляет некую избыточную информацию в поток (отсюда и оверхед). Получается, при потерях он позволяет восстановить данные что ли?