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

Проблемы с вещанием мультикаста с ffmpeg Картинка сыпется по непонятны причинам

Ситуация такая: в сети работает 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 всё же.

Edited by wtyd

Share this post


Link to post
Share on other sites
-vcodec copy

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

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

Share this post


Link to post
Share on other sites
-vcodec copy

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

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

 

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

 

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

Edited by wtyd

Share this post


Link to post
Share on other sites
-vcodec copy

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

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

 

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

 

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

 

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

Share this post


Link to post
Share on other sites
-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 на тех же самых потоках.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

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

 

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

 

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

 

 

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

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

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

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

Edited by sky star

Share this post


Link to post
Share on other sites

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

 

Какой-то специальный снифер ? 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 не помог :-)

Edited by wtyd

Share this post


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

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

 

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

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

 

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

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

Share this post


Link to post
Share on other sites

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

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

TSreader Lite

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

 

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

Share this post


Link to post
Share on other sites

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

 

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

 

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

Edited by wtyd

Share this post


Link to post
Share on other sites

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

 

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

 

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

 

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

 

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

 

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

 

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

Edited by wtyd

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