[undro]

Приветствую.

 

Есть сабж-хотелка - пустить в iptv потоки с камер, с цикличным переключением. Камер штук 20-30-50.

 

Забираю с камер по rtsp, отдаю в udpxy, клиент смотрит по http.

Если взлетит в iptv, хочется гнать на ГСку (EMR 3.0) этот мультик и отдать в dvb-c.

 

Пробовал через сvlc+vlm, каждый поток вида:

new cam1 broadcast enabled
setup cam1 input rtsp://xxxx:yyyy@1.2.3.4:554/Streaming/Channels/101 
setup cam1 output #transcode{vcodec=h264,vb=5000,width=720,height=576,sfilter=logo{file=/home/vlc/1.png,position=9}}:std{access=udp,dst=224.224.224.224:1234}

Все вроде бы ничего, даже не упал за выходные.

Но тот же vlc плеер регулярно переключается на следующий в плейлисте канал в моменты смены источника.

Запустил две виртуалки cvlc с одинаковым vlm. Накидал скрипт, стартует потоки поочередно с каждой и последующий поток на Nсек раньше, чем дропает текущий - аля буферизация.

Визуально-эмпирически буфер в потоке на переключении уменьшился. Но соскоки плейлиста остались.

 

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

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

 

Кто как это делает? Тема вроде тривиальная.

Спец.софт за $ тоже можно рассмотреть.

[sky star]

это не VLC переключается, а у Вас PAT падает :)

 

Вы бы анализатором поток то что "наваяли " посмотрели , в ужас бы пришли от самоделия

[undro]

Я понимаю, что реализация на коленке из говна и палок. От того и вопрос, как это правильно делается :)

[sky star]

мы два года точили IP - QAM камер видео наблюдения,

два года ! с десяток аппаратных ревизий , ревизий софта не счесть !

сейчас на столе вторая ревизия КОРПУСА !

с уже встроенной системой сложения , и то китайцы напортачить сумели !

и это привал ,

а Вы пишите как правильно

 

пы сы TS поток с ip-qam , один хрен говенный , с PCR труба

пы сы 2 характеристика спектра на QAM 64 вот такая получилась "/\" у них, а должна быть такая "П"

 

а ты сам часом не Vlink ?

[undro]

Грустно как-то.

 

а ты сам часом не Vlink ?

Не

[sky star]

забавно , а кого я тогда в Владике не знаю :)

если не с подряда и не с владлинка , кто там ишо есть о_0

[myth]

astra?

[kosorezik]

в dvb-c будет критично, как целостность и непрерывность таблиц, так и целостность GOP на уровне mpeg....

[Ivan_83]

Для переключения между потоками - потоки должны быть одинаковые.

Одинаковые:

- кодеки

- инденты потоков в mpeg2-ts

- битрейты

- разрешения

 

Пойми, когда клиент первые раз открывает поток он детектит какие там кодеки и пр, этим он инитит декодеры/кодеки и дальше он только льёт то что получает из сети, если у тебя был мпег2+мпег3 в 720х480 а стало х264+ац3 в 1920х1080 то кодеки подавятся и выдадут ошибку, плеер не будет ничё смотреть (обычно) он посчитает что канал сдох и переключится/выключит просмотр.

[undro]

sky star

список не полный :)

 

Ivan_83

Параметры транскодирования едины для потоков со всех камер (настройки камер тоже), но с выходным битрейтом у vlc какие то грабли, cbr он видимо не умеет в отличии от астры.

 

В текущем варианте соскоки плейлиста проявляются +/- раз в час, камеры перещелкиваются раз в 30с.

[klyushkov]

>Спец.софт за $ тоже можно рассмотреть.

 

Попробуйте Flussonic, вроде там была фишка в сохранении PAT при переключении на другой источник. Или нет.

[alibek]

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

[undro]

Попробуйте Flussonic, вроде там была фишка в сохранении PAT при переключении на другой источник. Или нет.

Пробовал. Автор подсказал пару вариантов реализации логики через api, но еще руки не дошли посмотреть. Тестируем решение от СофтЛаб-НСК - довольны всем, кроме цены :).

[stas_k]

Забираю с камер по rtsp, отдаю в udpxy, клиент смотрит по http.

Если взлетит в iptv, хочется гнать на ГСку (EMR 3.0) этот мультик и отдать в dvb-c.

 

Пробовал через сvlc+vlm, каждый поток вида:

 

Все вроде бы ничего, даже не упал за выходные.

Но тот же vlc плеер регулярно переключается на следующий в плейлисте канал в моменты смены источника.

 

Когда то давным давно, я решал аналогичную задачу. "Очень хочется, но в общем не особо и нужно (денег нет)."

 

формулировалось задача так:

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

 

По глубокому размышлению задача была разделена на три под задачи.

 

Нужно переключаться между источниками,

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

транслировать без сбоев/перерывов.

 

Попытки как то совместить эти три задачи в один или два экземпляра cvlc были обречены на провал. То он не мог перекодировать сразу из того потока что приходил от источника. и в 90% случаев плеер переключался.

 

Решено было на каждую из задач выделить cvlc.

 

Первый принимал сигнал от выбранного источника, буферизировал, и отдавал "как есть" по интерфейсу 127.0.0.0:8001.

Второй слушал сигнал с 127.0.0.0:8001, по умолчанию буферизировал, перекодировал звук в стерео, размер кадра от 176x140 до 1920x1080 и отдавал по интерфейсу 127.0.0.0:8002. Ядро Core i5 отжирало.

Третий слушал сигнал с 127.0.0.0:8002, по умолчанию буферизировал, ничего не делал, отдавал по интерфейсу http://0.0.0.0:8000.

 

Переключение источников - вебморда, дергала bash скрипт, убивающий первый cvlc, и запускающий новый. в командной строке параметры "откуда".

Переключение перекодирующего, та же вебморда. дергает другой bash скрипт, убивает второй cvlc и запускает новый, с новым размером кадра.

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

 

То, что каждый из экзмпеляров cvlc по умолчанию буферизировал, приводило к тому. что переключение источников часто происходило "бесшовно", и только при переключении масштабирования картинка "гасла" на пол секунды. При этом клиентский проигрыватель (любой, не только vlc) на следующий канал в плейлисте не переключался.

 

уж не знаю, как там этот поток по научному выглядел.

 

Я понимаю, что реализация на коленке из говна и палок. От того и вопрос, как это правильно делается :)

Ну не знаю, выделить целый системник Core i5 с 2Gb ... можно ли назвать из "говна"? :)

[alibek]

Первый принимал сигнал от выбранного источника, буферизировал, и отдавал "как есть" по интерфейсу 127.0.0.0:8001

Интересная идея.

Нужно будет попробовать такое с наложением звука (зацикленный mp3 на трансляцию с камеры), у меня с этим были сложности.

А почему 127.0.0.0? Не лучше какой-нибудь 127.0.0.10?

[stas_k]

А почему 127.0.0.0? Не лучше какой-нибудь 127.0.0.10?

Это абсолютно без разницы. Можно использовать любой красивый адрес 127/8, хоть "золотой" IP 127.127.127.127.

 

На самом деле оно в процессе отладки на 0.0.0.0:хххх висело на всех интерфейсах, а я со своего компа диагностически цеплялся смотреть что там с потоком на каждом этапе. Потом поленился изменить на 127.0.0.1

Работает - не трожь!

[undro]

stas_k

Спасибо за инфо, попробуем.

[sky star]

позволю себе вмешаться в диалог,

сама затея с показом картинок не нова и мы ее прошли еще 12 лет назад :)

так вот , просто смена камер это хорошо , гут !

но слишком утомительно что ли ,

в итоге рани или поздно, сразу или не позже, но так или иначе , Вы притопайте к мысли

что это не то что надо :)

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

и вот мы 11 лет назад купили софт , поставили железо,

и на основании таких же вот картинок сделали себе еще один тв канал,

на котором есть оформление , и который сам ходит по ссылкам на

урлы камер :)

 

как то так

 

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

к рекламе "по старинке" , народ активно платит за ролики в 5 сек с стоящей картинкой (вообще без анимации)

и статичным текстом :) и еще больше вспомнили про бегучку ! в два ряда , в верхнем медленно платное ,

в нижнем быстро бесплатно (быстро что хрен успеешь почитать , но бесплатно)