LINUX.ORG.RU
Форум — Multimedia  

RTSP сервер своими руками

 , , , ,


1

5

Ковырял, ковырял задачу, поставленную для организации домашнего видеонаблюдения без задержек, не выковырял! Сутки убил на запуск ffserver+ffmpeg+ffplay или mplayer - ничего не вышло, сервер тупо не отдавал ничего. Тестовые примеры live555 разобрал - аналогично. Вроде и строки в выхлоп пишет, как что можно забрать, но нет результата ни с mplayer, ни с ffplay. VLC вообще отказался работать без поддержки, т.е. в связке «VLC wrapper пишет в файл, DSS отдает в сеть» все работает, ffplay даже показывает, но главная задача не выполняется: идет задержка, тормозящая воспроизведение на пять секунд, а сколько кадров теряется... Снизил битрейт, облегчил транскодировку - нуль эмоций, но тут уже возможен челофактор, я сплю на клаве уже и сеть не проверяю и выхлоп не читаю...

Так вот, из того, что не пробовал - gstreamer с кучей примеров в сети как поднять свой RTSP сервер и не мучаться. Есть ли у вас опыт его удачного расковыривания?

И напоследок: по UDP, как понял ТС, можно тупо кидать информацию, не заботясь о том, как ее принял клиент. Допустим, я кодирую поток с камеры в любой читаемый формат, и... <Тут длинная пауза> ... в теории, как-то, слушаю порт, отдавая подключившемуся этот файл? Вот тупо нужно слать видео, не заботясь о ресивере, а как сделать - представить не могу. Подскажите, ребяты? Спасибо за поддержку!

★★★★★

Телепатирую. Значит идёт внешний поток с 9000 камер, обрабатывается и отдаётся 9000 клиентам через вшивую 10/100Мбит сетевушку, расположенную через 9000 сетевых экранов?

ziemin ★★
()
Ответ на: комментарий от ziemin

Аргументирую: стоит плата захвата вселеннс 16 композитными входами, ну и одна вебка для проверки валяется. Камер у меня две, а хочется хотя бы одну в RTSP запихать. Ничего более не обрабатывается и не шлется - до запуска Дарвина RTSP сервера не работали, присылали ошибки, забывали порты открывать или валились без особых дебаг мэсаг. VLC, так нахваливаемый многими ну вот не завелся ни по какому мануалу, только в качестве прослойки для дарвина. Сетевушка говно, но свитч еще хуже - аппаратно перезагружаю после суток издевательств. Экранов нет, все прозрачно, но ноут-приемник за вафлей, исправлю, проверю

minakov ★★★★★
() автор топика

И напоследок: по UDP, как понял ТС, можно тупо кидать информацию, не заботясь о том, как ее принял клиент. Допустим, я кодирую поток с камеры в любой читаемый формат, и... <Тут длинная пауза> ... в теории, как-то, слушаю порт, отдавая подключившемуся этот файл? Вот тупо нужно слать видео, не заботясь о ресивере,

На сервере отправляешь поток с камеры: 

ffmpeg -f v4l -i /dev/video0 -f mpegts udp://client:1300
На клиенте воспроизводишь: 
mplayer udp://client:1300
где client - ип-адрес или имя хоста клиента. Можно использовать multicast адрес, тогда воспроизводить поток можно будет сразу на нескольких клиентах.

fopen ★★
()
Ответ на: комментарий от fopen

Задержка ~10 сек. Кэш в mplayer отключил - не показывает(как и с ним, смотрел в ffplay). Адрес 127.0.0.1, видео с UVC камеры ноута. Задержка, задержка везде...

minakov ★★★★★
() автор топика
Ответ на: комментарий от minakov

mplayer не воспроизводит? Не может быть! Что пишет?

ffplay я не пользуюсь, но видел... В начале он анализирует поток: определяет параметры, и даже длительность потока пытается узнать. Это вносит задержку. Нужно уменьшить время анализа, ищи опции analyzeduration или probesize.

Для справки. У ffplay качество картинки хуже mplayer. Наслаждаться картинкой рекомендуют в mplayer.

fopen ★★
()
Ответ на: комментарий от fopen 
[10:53][elemashine ~]$ time mplayer udp://127.0.0.1:1300
MPlayer SVN-r35014-4.7.1 (C) 2000-2012 MPlayer Team
195 audio & 404 video codecs
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.

Playing udp://127.0.0.1:1300.
STREAM_UDP, URL: udp://127.0.0.1:1300
Stream not seekable!
libavformat version 54.15.100 (internal)
Stream not seekable!
Stream not seekable!
Stream not seekable!
Stream not seekable!
Stream not seekable!
Stream not seekable!
Stream not seekable!
Stream not seekable!
Stream not seekable!
Stream not seekable!
Stream not seekable!
Stream not seekable!
Stream not seekable!
Stream not seekable!
Stream not seekable!
Stream not seekable!
Stream not seekable!
Stream not seekable!
Stream not seekable!
Stream not seekable!
Stream not seekable!
TS file format detected.
Stream not seekable!


MPlayer interrupted by signal 2 in module: demux_open


MPlayer interrupted by signal 2 in module: demux_open

real    0m56.930s
user    0m0.107s
sys     0m0.080s

Убит ^C x 2...

С опцией -nocache аналогично - можно кофе попить, фильм скачать и радио послушать, все равно не дождешься окошка с видео. 

[10:50][elemashine ~]$ ffmpeg -f v4l2 -i /dev/video0 -f mpegts udp://127.0.0.1:1300
ffmpeg version 0.11.1 Copyright (c) 2000-2012 the FFmpeg developers
  built on Jun  9 2012 13:50:13 with gcc 4.7.0 20120505 (prerelease)
  configuration: --prefix=/usr --enable-libmp3lame --enable-libvorbis --enable-libxvid --enable-libx264 --enable-libvpx --enable-libtheora --enable-libgsm --enable-libspeex --enable-postproc --enable-shared --enable-x11grab --enable-libopencore_amrnb --enable-libopencore_amrwb --enable-libschroedinger --enable-libopenjpeg --enable-librtmp --enable-libpulse --enable-libv4l2 --enable-gpl --enable-version3 --enable-runtime-cpudetect --disable-debug --disable-static
  libavutil      51. 54.100 / 51. 54.100
  libavcodec     54. 23.100 / 54. 23.100
  libavformat    54.  6.100 / 54.  6.100
  libavdevice    54.  0.100 / 54.  0.100
  libavfilter     2. 77.100 /  2. 77.100
  libswscale      2.  1.100 /  2.  1.100
  libswresample   0. 15.100 /  0. 15.100
  libpostproc    52.  0.100 / 52.  0.100
[video4linux2,v4l2 @ 0xc06140] Estimating duration from bitrate, this may be inaccurate
Input #0, video4linux2,v4l2, from '/dev/video0':
  Duration: N/A, start: 216.675920, bitrate: 110592 kb/s
    Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 640x480, 110592 kb/s, 30 tbr, 1000k tbn, 30 tbc
[buffer @ 0xc0ba60] w:640 h:480 pixfmt:yuv420p tb:1/1000000 sar:0/1 sws_param:flags=2
[buffersink @ 0xc0bfa0] No opaque field provided
[mpegts @ 0xc06980] muxrate VBR, pcr every 3 pkts, sdt every 200, pat/pmt every 40 pkts
Output #0, mpegts, to 'udp://127.0.0.1:1300':
  Metadata:
    encoder         : Lavf54.6.100
    Stream #0:0: Video: mpeg2video, yuv420p, 640x480, q=2-31, 200 kb/s, 90k tbn, 30 tbc
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo -> mpeg2video)
Press [q] to stop, [?] for help
frame= 5204 fps= 30 q=31.0 Lsize=    6869kB time=00:02:53.43 bitrate= 324.5kbits/s dup=3912 drop=0    
video:5881kB audio:0kB global headers:0kB muxing overhead 16.797972%                                                                                           
Received signal 2: terminating.
Разные форматы тыкал, результат аналогичен

minakov ★★★★★
() автор топика
Ответ на: комментарий от minakov

Помоги плееру: 

mplayer -demuxer mpegts -tsprobe 50000 -nocache udp://127.0.0.1:1300
Так за пару секунд должен запуститься.

Картинка будет ужасна. Подними качество кодера. Например, VBR, 

ffmpeg -f v4l2 -i /dev/video0 -f mpegts -qscale 2 udp://127.0.0.1:1300
или CBR 
ffmpeg -f v4l2 -i /dev/video0 -f mpegts -b:v 5000000 udp://127.0.0.1:1300

fopen ★★
()
Ответ на: комментарий от fopen

Откуда ты все это знаешь? Спасибо, получил добрый пинок в сторону чтения документации, хотя раньше времени на нее терять не хотелось. Да, результат: приблизительно ~1/4 секунды задержки на локалхосте, что сравнимо с приемом без буфера от hts-tvheadend asf потока.

minakov ★★★★★
() автор топика
Ответ на: комментарий от minakov

Уже ходил по этим граблям. Задержка 1/4 сек. вполне адекватна. Если нужно ее уменьшить, то надо настраивать кодер. Убрать B-frames, выставить флаг «low latency». Но это все в ущерб bandwidth.

fopen ★★
()
Ответ на: комментарий от fopen

fopen, не в курсе, как взять в качестве источника определенный input устройства? Вот в плате, к примеру, 4 чипа, создаются 4 девайса в системе, mplayer'ом забираю, указывая имя и инпут(device=/dev/video3:input=2), а вот в ffmpeg не могу найти их. Спасибо!

minakov ★★★★★
() автор топика
Ответ на: комментарий от fopen

Ну практически - да. В системе 4 устройства, мне хоть пять бы вытянуть инпутами, коих 16 в общем. Пока в раздумьях, как вообще это делается. mplayer'ом-то вытянуть не проблема, но вот связать с ffmpeg... Наверное поковыряю v4l2, вдруг там есть такая возможность, а за подсказку, кстати, спасибо. Ну или разбить как-то девайсы на четыре инпута, что-то типа /dev/video0-15, пока не знаю

minakov ★★★★★
() автор топика
Ответ на: комментарий от minakov

Ты правильно сказал - у тебя 4 устройства захвата (ADC). К каждому устройству захвата подключен мультиплексор на 4 (mux). К мультиплекторам подключают видеокамеры. Итого 4*4 = 16 видеокамер можно подключить, но в один и тот же момент времени только 4 камеры, подключенные к разным мультиплексорам, можно захватить. Мультиплексор - это переключатель. Один вход подключает к выходу. Ты выбираешь какой вход сейчас подключить к устройству захвата.

У тебя 5 камер. 4 из них (cam1 - cam4) надо распределить по разным мультиплексорам, а пятую (cam5) к любому другому. Например, так: 

        |------mux------|    |--ADC---|    |-BUS-|
cam1 -> |input0         |    |        |    |     |
     -> |input1   output| -> | video0 | -> | PCI |
     -> |input2         |    |        |    |     |
     -> |input3         |    |        |    |     |
        |------mux------|    |--ADC---|    |-BUS-|
cam2 -> |input0         |    |        |    |     |
     -> |input1   output| -> | video1 | -> | PCI |
     -> |input2         |    |        |    |     |
     -> |input3         |    |        |    |     |
        |------mux------|    |--ADC---|    |-BUS-|
cam3 -> |input0         |    |        |    |     |
     -> |input1   output| -> | video2 | -> | PCI |
     -> |input2         |    |        |    |     |
     -> |input3         |    |        |    |     |
        |------mux------|    |--ADC---|    |-BUS-|
cam4 -> |input0         |    |        |    |     |
     -> |input1   output| -> | video3 | -> | PCI |
     -> |input2         |    |        |    |     |
cam5 -> |input3         |    |        |    |     |
Чтобы захватить первые три камеры, действуем как обычно: ffmpeg -i /dev/videoN

Чтобы захватить камеры 4 и 5 нужно их мультиплексировать: 

while true ; do
    v4l2-ctl -d /dev/video3 -i 0
    sleep 5
    v4l2-ctl -d /dev/video3 -i 3
    sleep 5
done
и захватить: mplayer /dev/video3. Так мы увидим мультиплексированный поток.

Если камера 4 снимает котлеты, а камера 5 - мух, то мы, конечно, захотим разделить это на два потока, т.е. демультиплексировать.

Т.о. программа захвата должна уметь управлять аппаратным мультиплексором и программно демультиплексировать поток. Я знаю только одну такую - motion. А ffmpeg нужно допиливать, но это легко вписывается в его архитектуру.

И еще замечу о частоте кадров, захваченных с 4 и 5 камер. Она будет в идеальном случае = 25 / 2 = 12.5 Гц (PAL). Но идеального ничего нет. Камеры не синхронизированы между собой и могут иметь разные параметры. От случая и от схемотехники зависит как быстро устройство поймает синхронизацию. Это еще минимум в 2 раза снижается частота кадров. Итого, если ты выжмешь с четвертой камеры или пятой камеры хотя бы шесть кадров в секунду, то тебе повезло. На деле я это не проверял, чисто теоретически.

fopen ★★
()
Ответ на: комментарий от fopen

Чисто субъективно, частота кадров не менялась, когда я mplayer'ом забирал три потока с одного девайса одновременно, но точно проверю чуть позже, спасибо! Ты здорово подогрел мой интерес к видео

minakov ★★★★★
() автор топика

Вот оно-то «Тестовые примеры live555» как раз отлично транслирует сырые Annex B byte-stream format потоки из файла без контейнера. Вместо файла может быть «живой источник».

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

Я пробовал - при условии ограниченных времени и знаний запустить его не получилось.

minakov ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Multimedia