[wtyd]

Ситуация такая: в сети работает iptv, вроде бы нормально. Недавно поставили задачу вещать в ту же MVR сеть потоки с камер. Сделали всё на ffmpeg -i <rtmp ссылка> -vcodec copy ... -f mpegts udp://<адрес группы> . Вещается. Так получилось, что мы сами рядом находимся и у нас всё вполне себе нормально показывается, но у абонентов, расположенных в другом L3 сегмента (мультикаст роутится туда, там свой mvr влан) есть проблемы. Проблема выражается в том ,что верхняя часть картинки показывается нормально, остальное смазано вниз. Когда картинка меняется, то в смазанной части появляются нормальные объекты движения, потом приходит очередной ключевой кадр и всё заново. Т.е. это не просто картинка сыпется, а каким-то определённым образом она сыпется :-).

 

Ради теста зарезал с помощью tc себе полосу на сетевой карте десктопа и стал смотреть -- искажения очень похожи. Не хватает полосы и от этого видно верхнюю четверть кадра.

 

Но при всём при этом телевидение, которое берётся у поставщиков, показывает нормально. Я сегодня вспотел сравнивать вывод ffprobe с разных источников, ничем они не отличаются, разве только полосой потока. Других различий я не нашёл. Есть потоки от ffmpeg - они сыпятся, есть потоки от поставщиков с похожими параметрами - они не сыпятся.

 

Подскажите, куда копать ? Может у ffmpeg какой-то не такой mpegts ? Может параметры есть какие волшебные ?

 

Задача с несколькими неизвестными.

 

В планах промерить полосу на мультикасте с помощью iperf, но пока нет возможности -- там у всех видна (на винде iperf с мультикастом просто так не заработал :-)) и помогать мне никто не собирается. Сеть на длинках, трафик контрол смотрели - отключено везде по дороге, бандвидс контрол - тоже. Уже не знаю, что делать. iperf скорее всего покажет, что всё нормально. Ещё там линк агрегейшн на длинках собран в нескольких местах (по 2 гигабита). Каких-то других отличий от нашего сегмента больше нет.

 

P.S. Ещё давно заметили, что поток с камеры через несколько дней на STB перестаёт показывать, но при этом vlc, mplayer и все остальные плееры на PC его показывают. Если рестартануть ffmpeg, то приставка опять начинает показывать -- забили задачу в крон :-). Подозреваю, что что-то не совсем так с самим потоком от ffmpeg всё же.

Изменено 4 мая, 2016 пользователем wtyd

[kosorezik]

-vcodec copy

кодеры на IP камерах зачастую "спецефические"

попробуйте перекодировать, и -или буферизировать видео

[wtyd]

-vcodec copy

кодеры на IP камерах зачастую "спецефические"

попробуйте перекодировать, и -или буферизировать видео

 

перекодировать -- нет аппаратных мощностей это делать, а буфферизировать надо на стороне клиента или можно это в параметрах потока указать ?

 

UPDATE: Попробовали на стороне клиента увеличить кеш до 10 секунд -- не помогло.

Изменено 4 мая, 2016 пользователем wtyd

[tartila]

-vcodec copy

кодеры на IP камерах зачастую "спецефические"

попробуйте перекодировать, и -или буферизировать видео

 

перекодировать -- нет аппаратных мощностей это делать, а буфферизировать надо на стороне клиента или можно это в параметрах потока указать ?

 

UPDATE: Попробовали на стороне клиента увеличить кеш до 10 секунд -- не помогло.

 

Вы прямо таки уверены, что на камерах mpeg2? Я думаю, что там h264, отсюда и проблема половинчатого кадра после key-frame. Перекодировка спасет вас и я бы еще взял vlc, а не ffmpeg.

[wtyd]

-vcodec copy

кодеры на IP камерах зачастую "спецефические"

попробуйте перекодировать, и -или буферизировать видео

 

перекодировать -- нет аппаратных мощностей это делать, а буфферизировать надо на стороне клиента или можно это в параметрах потока указать ?

 

UPDATE: Попробовали на стороне клиента увеличить кеш до 10 секунд -- не помогло.

 

Вы прямо таки уверены, что на камерах mpeg2? Я думаю, что там h264, отсюда и проблема половинчатого кадра после key-frame. Перекодировка спасет вас и я бы еще взял vlc, а не ffmpeg.

 

Половинчатый кадр только в другом L3 сегменте получается, тут рядом кадр нормальный. Перекодировать 1280х720х3шт свободного тазика нет :-). Про mpeg2 я нигде вроде бы не писал, я писал про mpegts. А кодек там h264 с камер летит.

 

Проблема, по-моему, не в кодеке. Есть несколько камер с разными разрешениями, которые в ближнем к ним L3 сегменте нормально показывают, а в другом L3 примерно по пол кадра (чем меньше разрешение тем бОльшая часть кадра нормально показывается). Так же есть туча тв-каналов, которые везде нормально показывают (хотя я уже не уверен :-)). В других L3 сегментах мы ещё не проверяли.

 

Вот я сижу и думаю уже несколько дней, в чём проблема-то ? :-).

 

VLC раньше был на этих же задачах, на счёт рассыпания/нерассыпания в другом L3 сегменте сети данных нет, но предыдущие админы по какой-то причине в кроне сделали рестарт ВЛЦ каждый час :-). Ещё он жрал память как слон и проц в 2 раза больше, чем ffmpeg/avconv на тех же самых потоках.

[Butch3r]

Ну а снифером битый мультикаст смотрели? Или анализатором?

[tartila]

Половинчатый кадр только в другом L3 сегменте получается, тут рядом кадр нормальный. Перекодировать 1280х720х3шт свободного тазика нет :-). Про mpeg2 я нигде вроде бы не писал, я писал про mpegts. А кодек там h264 с камер летит.

 

Проблема, по-моему, не в кодеке. Есть несколько камер с разными разрешениями, которые в ближнем к ним L3 сегменте нормально показывают, а в другом L3 примерно по пол кадра (чем меньше разрешение тем бОльшая часть кадра нормально показывается). Так же есть туча тв-каналов, которые везде нормально показывают (хотя я уже не уверен :-)). В других L3 сегментах мы ещё не проверяли.

 

Вот я сижу и думаю уже несколько дней, в чём проблема-то ? :-).

 

VLC раньше был на этих же задачах, на счёт рассыпания/нерассыпания в другом L3 сегменте сети данных нет, но предыдущие админы по какой-то причине в кроне сделали рестарт ВЛЦ каждый час :-). Ещё он жрал память как слон и проц в 2 раза больше, чем ffmpeg/avconv на тех же самых потоках.

 

Ну очевидно ж, что проблема в том, что в дальних частях сети режется мультикаст. h264 страдает сильнее, чем mpeg2 в iptv. Погоняйте iperf, как хотели сделать и все сразу встанет на свои места. Кстати, у VLC (плейра) есть консолька, где можно глянуть статистику по транспорту и кодеку.

[wtyd]

Ну а снифером битый мультикаст смотрели? Или анализатором?

 

Пока не было возможности -- с проблемной стороны пользователи, они ничего не хотят знать/уметь, сами пока туда не ездили. Топик и был создан с целью узнать, как диагностировать такие вещи. Что за анализатор мультикаста ? Я только ffprobe знаю и iperf. Чем ещё можно посмотреть ? Под винду под линукс

[sky star]

http://www.bridgetech.tv/product_microanalytics.php

 

можно ознакомится анализатором

[kosorezik]

Начните с триал https://www.streamguru.de/

[Ivan_83]

Поди размер пакета UDP получается большой.

А вообще, раздавайте юникастом и проблем не будет.

[wtyd]

Поди размер пакета UDP получается большой.

А вообще, раздавайте юникастом и проблем не будет.

 

Пакет стандартный 1316 байт (188x7). Менять пробовал, приставки перестают показывать, а разные плееры показывают. Читал, что размер пакета много где захардкоден в 1316.

 

На счёт мультикаста и юникаста: ну можно конечно, но должно же в мультике показывать :-). Тем более руководство сказало -- мультикаст и всё. Продолжаем разбираться, пока нет результатов.

[Butch3r]

Снифер всё должен рассказать

[wtyd]

Снифер всё должен рассказать

 

Какой-то специальный снифер ? tcpdump ничё не расскажет, покажет кучу пакетов и всё. Есть мнение, что пакеты не по порядку прилетают почему-то, но пока это тоже только гипотеза.

[sky star]

Снифер всё должен рассказать

 

Какой-то специальный снифер ? tcpdump ничё не расскажет, покажет кучу пакетов и всё. Есть мнение, что пакеты не по порядку прилетают почему-то, но пока это тоже только гипотеза.

 

 

Вы бы хоть по ссылкам походили, да изучили, стало бы понятнее что можно увидеть , а то как в 1 классе

http://www.bridgetech.tv/solutions.php

вот и даже мультики есть

http://www.bridgetech.tv/academy_fsm.php

Изменено 6 мая, 2016 пользователем sky star

[wtyd]

Снифер всё должен рассказать

 

Какой-то специальный снифер ? tcpdump ничё не расскажет, покажет кучу пакетов и всё. Есть мнение, что пакеты не по порядку прилетают почему-то, но пока это тоже только гипотеза.

 

 

Вы бы хоть по ссылкам походили, да изучили, стало бы понятнее что можно увидеть , а то как в 1 классе

http://www.bridgetech.tv/solutions.php

вот и даже мультики есть

http://www.bridgetech.tv/academy_fsm.php

 

По-моему, это всё платный софт. Затрат на платный софт у нас не предусмотрено :-), поэтому и не рассматриваю.

 

Тут ещё мысль появилась, у нас QoS совершенно точно настроен для iptv только в ближнем сегменте, на счёт проблемного дальнего сегмента есть сомнения :-). Подскажите аналог цыскиной команды для интерфейса "mls qos trust cos/dscp" для длинков ? dscp и cos выставляются, но как реагируют на это длинки я пока не знаю. С ходу аналоги цыскиных команд найти не удалось.

 

UPDATE: QoS не помог :-)

Изменено 6 мая, 2016 пользователем wtyd

[Ivan_83]

На счёт мультикаста и юникаста: ну можно конечно, но должно же в мультике показывать :-). Тем более руководство сказало -- мультикаст и всё. Продолжаем разбираться, пока нет результатов.

Поставьте просто на узлах msd_lite, до узлов мультикастом дальше юникастом.

 

Какой-то специальный снифер ?

TSreader Lite - бесплатный, хоть и не очень удобный для постоянного пользования.

 

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

Как совсем странный вариант - может мультикаст как то дублируется и клиенту валит х2 или более пакетов - сравните сколько на входе адатера проблемного клиента и сколько безпроблемного.

[Butch3r]

Какой-то специальный снифер ? tcpdump ничё не расскажет, покажет кучу пакетов и всё. Есть мнение, что пакеты не по порядку прилетают почему-то, но пока это тоже только гипотеза.

вайресшарк это показывает.

TSreader Lite

тоже подойдет, он именно анализирует картинку.

[TretUliy2]

попробуйте ffmpeg -re

попробуйте рестримить выход ffmpeg астрой

[wtyd]

iperf показал такие же результаты, как и тут локально показывал. Штук 7 датаграм пришло не в том порядке за 30 секунд, но видео с камеры всёравно сыпется. Гон какой-то ...

[wtyd]

попробуйте ffmpeg -re

попробуйте рестримить выход ffmpeg астрой

 

ffmpeg -re попробовал, но ни на что вообще не повлияло. В мане написано, что эта опция хороша для файлов, но для live источников она как бы бесполезна, но я всёравно попробовал - различий нет.

[wtyd]

В общем, последние тесты показали значительный успех после того, как порт стримера с ffmpeg перевели с гигабита в 100 мегабит :-))).

 

Хотелось бы услышать ваши версии ответов на вопрос, т.е. почему потоки сыпались, а после перевода интерфейса в 100 мегабит рассыпания прекратились ?

 

Ответ я знаю, уверен в нём на 99%, просто я с такой ситуацией однажды сталкивался, скажу его позже. Хочу услышать ваши версии :-). Ну вдруг моя версия ответа неправильная ?

Изменено 19 мая, 2016 пользователем wtyd

[tartila]

В общем, последние тесты показали значительный успех после того, как порт стримера с ffmpeg перевели с гигабита в 100 мегабит :-))).

 

Хотелось бы услышать ваши версии ответов на вопрос, т.е. почему потоки сыпались, а после перевода интерфейса в 100 мегабит рассыпания прекратились ?

 

Ответ я знаю, уверен в нём на 99%, просто я с такой ситуацией однажды сталкивался, скажу его позже. Хочу услышать ваши версии :-). Ну вдруг моя версия ответа неправильная ?

 

Дерьмовый патч, который крошил гигабит? :)

[wtyd]

В общем, последние тесты показали значительный успех после того, как порт стримера с ffmpeg перевели с гигабита в 100 мегабит :-))).

 

Хотелось бы услышать ваши версии ответов на вопрос, т.е. почему потоки сыпались, а после перевода интерфейса в 100 мегабит рассыпания прекратились ?

 

Ответ я знаю, уверен в нём на 99%, просто я с такой ситуацией однажды сталкивался, скажу его позже. Хочу услышать ваши версии :-). Ну вдруг моя версия ответа неправильная ?

 

Дерьмовый патч, который крошил гигабит? :)

 

Nice try :-), но картинка по L2 не сыпалась никогда :-). Если бы крашился гигабит, то мы бы везде видели крашную картинку.

[wtyd]

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

 

Так вот, переключение стримера с гигабита на сотку тупо затормозило процесс заполнения буфера у какого-то коммутатора в цепочке. Т.е. на гигабите вылетала пачка пакетов за N времени, а после переключения на сотку -- за 10*N. Пакеты со стримера вылетают не равномерно, а пачками. Все эти вещи трудно диагностируемы обычными инструментами.

 

Первый раз я с этим столкнулся на юникастовом вещании камер. Сервер был включен в cisco 2960 (модель со всеми гигабитными портами, название точно не помню, у с2960 с 24х100 и 2х1Gb такой проблемы не было (!), там буферов хватало). В тот раз решили проблему переключением сервера вещания в шеститонник. В этот раз проблема возникла на мультиках, причём до шеститонника картинка шла номральная, а после шеститонника есть cisco 3560E, вот сразу после неё картинка крашилась. Нигде не было перегруженных линков, всё было чОтко, но вот так ... как мы это вылавливали -- отдельная история :-). Интеллектуальный штурм корреляции экзбиционизма и пацанства стримеров и различий в софте и в подключениях. Седых волос на моей голове наверное прибавилось.

 

Кстати, там по дороге после 3560Е есть ещё и длинк ДГС-какой-то, в него подключали смотрелку и оценивали качество, так что точно не известно, у кого из мутаторов буферы мелкие. Но я думаю, что у цыски, т.к. есть сведения, что у всей серии 35ХХ есть такая проблема, а 2960 это урезанная версия 35ХХ, деталей к сожалению не знаю, но такая информация была :-).

Изменено 20 мая, 2016 пользователем wtyd