Потоковое http видео на сайт из IP камерs через ffmpeg + ffserver 0.7.15 FreeBSD 9.1

23.07.2013 Сайт https://anteh.ru

I Frame Interval

Предлагаемое решение рабочее.
Нужно разместить видео потоки реального времени IP камер на сайте. ffserver 0.7.15 показался очень нестабильным и пригодным только для тестовых применений. Но основные проблемы разрешены, это зависание потоков при достижении границ размеров .ffm файлов и воспроизведение прерывающихся http потоков на web странице.

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

Red5 решено не использовать, слишком много нелестных отзывов.

Статья условно состоит из 2х частей. Сначала информация изложена кратко и по существу, далее описано, что откуда берётся. Про базовую настройку ffserver ничего нового, но есть решение, например с условной ротацией .ffm файла. Интерес могут представлять описание особенностей настроек IP камер.

FreeBSD 9.1
IP камера DS-2CD2012-I прошивка V4.0.9
Ffmpeg ffserver 0.7.15
Что-то вроде ротации .ffm файла
Восстановление работоспособности системы при сбоях в питании и канале связи.
Удалённые Internet клиенты
Суть параметра I Frame Interval настроек IP камеры rtsp поток
Относительность параметра MaxBandwidth в ffserver

Не обязательно использовать только IP камеры, могут быть и USB и аналоговые и в перемешку. К серверу FreeBSD 9.1 подключено несколько IP камер. Нужно из rtsp потоков, формируемых IP камерами получить надёжные не зависающие, без артефактов .swf .flv потоки и вывести их на web страницу. Использовалась камера DS-2CD2012-I.
При пере подключении питания и Ethernet шнура камеры поток должен восстанавливаться. Передача потоков происходит через Internet.
Ffserver1+ffmpeg1-1.2.2 не пошёл, с камеры поток забирался, через localhost в ffserver1 данные не передавались. Или ffserver1 их не принимал. Не стал разбираться, попробовал ffserver 0.7.15
При установке ffmpeg 0.7.15 автоматически будет установлен ffserver. Для воспроизведения потокового видео на странице рекомендуют использовать форматы FLV или MP4. Настраиваем /usr/local/etc/ffserver.conf. Настройки для .swf + .fvl потоков с одного фида:

Port 8090
BindAddress 0.0.0.0
MaxHTTPConnections 2000
MaxClients 1000
#bandwidth, in kbits/s
MaxBandwidth 20480
CustomLog /var/log/ffservser.log
#NoDaemon
<Feed feed_DS2CD2012I.ffm>
    File /dev2/shm/feed_DS2CD2012I.ffm
    FileMaxSize 100M
    Launch ffmpeg -r 15 -s 1280x960 -i rtsp://admin:12345@192.168.10.2/h264/ch1/main/av_st
</Feed>
<Stream DS2CD2012I_main.swf>
    Feed feed_DS2CD2012I.ffm
    Format swf
    VideoCodec flv
    VideoFrameRate 15
    VideoBitRate 2048
    VideoQMin 1
    VideoQMax 5
    VideoSize 1280x960
    PreRoll 0
    NoAudio
</Stream>
<Stream DS2CD2012I.flv>
    Feed feed_DS2CD2012I.ffm
    Format flv
    VideoCodec flv
    VideoFrameRate 15
    VideoBitRate 2048
    VideoQMin 1
    VideoQMax 5
    VideoSize 1280x960
    PreRoll 0
    NoAudio
</Stream>
<Stream index.html>
Format status
</Stream>

  

/dev2/shm -это когда в /etc/fstab такая запись:
none /dev2/shm tmpfs rw,size=2G 0 0
Или .ffm размещаем как обычно, в tmp.

Для авто запуска, в файле /etc/rc.conf прописываем ffserver_enable="YES". И устанавливаем режим демона в конфигурационном файле #NoDaemon.

Запуск:

# /usr/local/etc/rc.d/ffserver start

Usage: /usr/local/etc/rc.d/ffserver [fast|force|one](start|stop|restart|rcvar|status|poll)

Просмотр текущей нагрузки сетевых интерфейсов:

# systat -ifstat 1

# ffserver -h описание настроек

В файл /usr/local/etc/rc.d/ffserver добавляем команду удаления .ffm файлов, расположенных в /dev2/shm/ директории. Если файлы не удалять, то при параметре FileMaxSize меньшем размера ранее созданного .ffm файла, поток у клиента будет зависать через несколько секунд после запуска/перезапуска. Зависание будет наблюдаться и при переполнении .ffm файла. /usr/local/etc/rc.d/ffserver выглядит так:

#!/bin/sh
#
# $FreeBSD: multimedia/ffmpeg/files/ffserver.in 300896 2012-07-14 13:54:48Z beat $
#
# PROVIDE: ffserver
# REQUIRE: NETWORKING
# KEYWORD: shutdown
#
# Add the following lines to /etc/rc.conf to enable ffserver:
#
#ffserver_enable="YES"
#
  ffserver_enable="${ffserver_enable-NO}"
  . /etc/rc.subr
  name=ffserver
    rcvar=ffserver_enable
  command="/usr/local/bin/${name} &"
    required_files=/usr/local/etc/ffserver.conf
#stop ffserver
    run_rc_command "onestop"
#remove .ffm files
    echo "remove .ffm"
    rm /dev2/shm/*.ffm
#start ffserver
    load_rc_config ${name}
    run_rc_command "$1"

Если ffserver запустился, но обмена с IP камерой нет, нужно проверить, удалён ли .ffm файл. Если в /dev2/shm/ будут в ручную созданы какие-либо папки, то они после перезапуска будут удалены, их нужно создавать либо скриптом при запуске, либо сделать соответствующую запись в fstab. Если директории, прописанной в параметре File секции <Feed feedxxx.ffm> не существует, то ничего работать не будет.

Наблюдалось следующее: видео, транслируемое с IP камеры на страницу нормально воспроизводится, пока не заполнялся до граничного значения размера .ffm файл. Далее может наблюдаться разное, но заканчивается всё зависанием изображения с артефактами. Если закомментировать File … и FileMaxSize …, то также всё работает, но зависает сразу-же через пару секунд.
Решить вопрос удалось так: выставляем параметр FileMaxSize большим, например 100M и периодически перезапускаем ffserver через crontab. Настройки скрипта запуска /usr/local/etc/rc.d/ffserver, показаны выше. При запуске, ffserver сначала останавливается, потом удаляются все *.ffm файлы, затем запуск. Через cron реализуем запуск ffserver раз в 5 минут /etc/crontab:

*/5     *       *       *       *       root    /usr/local/etc/rc.d/ffserver start

Конечно раз в какое количество минут производить пере запуск, решайте сами, чем больше интервал, тем больше должен быть размер параметра FileMaxSize в секции <Feed feedxxx.ffm>.
Это хорошо работает, но при перезапуске ffserver/ffmpeg происходит обрыв соединения. При удалённом просмотре через вин VLC особых проблем не возникает, VLC восстанавливает соединение самостоятельно. Обязательно должен быть включён РЕЖИМ ПОВТОРА. При этом заметно, что изображение подвисает на 2-5 секунд и потом воспроизводится дальше. При воспроизведении в браузере, после прерывания потока изображение проигрывается ещё в течении секунд 10, затем замирает. Поток не восстанавливается.
Поток не восстанавливается, если на странице он определён как:

устаревший вариант:

<embed src="http://ext.ern.al.ip:8090/DS2CD2012I_main.swf" width="1280" height="960" loop="true"></embed>

Или:

<object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000"     codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,40,0" 
    width=1280 height=960 id="intro"> 
 <param name="movie" value="DS2CD2012I_main.swf" /> 
     <param name="quality" value="high" /> 
  <param name="bgcolor" value="#1C140D" />
        <param name="loop" value="true" /> 
  <embed src="http://ext.ern.al.ip:8090/DS2CD2012I_main.swf"
      width=1280 
      type="application/x-shockwave-flash" height=960 quality="high" bgcolor="#1C140D" name="intro" align="" 
      pluginspage="http://www.macromedia.com/go/getflashplayer" loop="true"> 
  </embed> 
</object>

Пробовал и через автогенератор Dreamweaver cs5.5 Вставка->мультимедиа->SWF

<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" width="1280" height="960" id="FlashID" accesskey="aw34" tabindex="gd54" title="testtswf">
  <param name="movie" value="http://ext.ern.al.ip:8090/DS2CD2012I_main.swf" />
  <param name="quality" value="autolow" />
  <param name="wmode" value="opaque" />
  <param name="swfversion" value="6.0.65.0" />  
  <!-- Этот тег param предлагает пользователям Flash Player 6.0 r65 и более поздних версий загрузить последнюю версию Flash Player. Удалите его, если не хотите, чтобы пользователи видели запрос. -->
  <param name="expressinstall" value="../../Scripts/expressInstall.swf" />
  <!-- Следующий тег object не поддерживается браузером Internet Explorer. Поэтому скройте его от Internet Explorer при помощи IECC. -->
  <!--[if !IE]>-->
  <object type="application/x-shockwave-flash" data="http://ext.ern.al.ip:8090/DS2CD2012I_main.swf" width="1280" height="960">
    <!--<![endif]-->
    <param name="quality" value="autolow" />
    <param name="wmode" value="opaque" />
    <param name="swfversion" value="6.0.65.0" />
    <param name="expressinstall" value="../../Scripts/expressInstall.swf" />
    <!-- Браузер отображает следующее альтернативное содержимое для пользователей Flash Player 6.0 и более старых версий. -->
    <div>
      <h4>Для содержимого этой страницы требуется более новая версия Adobe Flash Player.</h4>
      <p><a href="http://www.adobe.com/go/getflashplayer"><img src="http://www.adobe.com/images/shared/download_buttons/get_flash_player.gif" alt="Получить проигрыватель Adobe Flash Player" /></a></p>
    </div>
    <!--[if !IE]>-->
  </object>
  <!--<![endif]-->
</object>

Не получилось, видео есть, но замирает loop не помогает, требует размещения expressInstall.swf и swfobject_modified.js файлов в Scripts папке корня сайта. Разбираться не стал.

Пробовал автогенератор Dreamweaver CS5.5 Вставка->мультимедиа->FLV нигде ничего не работало. Не стал разбирался.

Пробовал через автогенератор Dreamweaver CS5.5 Вставка->мультимедиа->Shockwave

Получилось, обязательно нужно выставить параметр: <param name="loop" value="true" />

Код от автогенератора Dreamweaver:

<object classid="clsid:166B1BCA-3F9C-11CF-8075-444553540000" 
        codebase="http://download.macromedia.com/pub/shockwave/cabs/director/sw.cab#version=10,1,1,0" 
  width="1280" height="960" accesskey="ax32" tabindex="asx" title="testt">
  <param name="src" value="http://ext.ern.al.ip:8090/DS2CD2012I.flv" />
  <param name="loop" value="true" />
  <embed src="http://ext.ern.al.ip:8090/DS2CD2012I.flv" width="1280" height="960" 
  pluginspage="http://www.adobe.com/shockwave/download/" loop="true"></embed>
</object>

Картинка замирает примерно на 5-8 секунд, далее восстанавливается. Работает в Firefox, Yandex, в IE в таком виде не работает.

Попробовал бесплатную версию uppod. Если воспроизводить flv поток через сайт uppod, при обрыве поток не восстанавливается. Если смотреть через плеер, размещённый на своём сайте, то для IE поток проигрывается в течении 7-9секунд и замирает. Для Firefox поток замирает через ожидаемый интервал -при обрыве поток не восстанавливается. Пробовал циклическое воспроизведение, не помогло.

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

Пробовал использовать Video.js, не получилось, картинка замирает. И нагрузка на процессор очень существенная, практически ядро интел коре два 2.4GHz загружает полностью. В Shockwave загрузка раз в несколько секунд доходит до 12 процентов. Параметры изображения: 1280x960 15fps Quality=High.
Установка Video.js:
С официального сайта качаем архив video-js-4.1.0.zip, размещаем в на сайте video-js директорию архива.
В заголовке страницы:

<link rel="stylesheet" type="text/css" href="../../players/video-js/video-js.css"/>
<script type="text/javascript" src="../../players/video-js/video.js"></script>
<script>
  videojs.options.flash.swf = "http://some_site.ru/players/video-js/video-js.swf"
</script>

На странице:

<video id="example_video_1" class="video-js vjs-default-skin"  
  autoplay="autoplay" controls="controls"  preload="none" loop="loop" 
  poster="http://some_site.ru/impic/hr.jpg" width="1280" height="960"
  data-setup='{}'>
  <source src="http://ext.ern.al.ip:8090/DS2CD2012I_main.swf" type='video/swf' />
  <source src="http://ext.ern.al.ip:8090/DS2CD2012I.flv" type='video/flv' />
</video>

С воспроизведением реальных файлов всё в порядке.
Посмотрел демки некоторых javascript проигрывателей -слишком сильно нагружают процессор, не подходят.
Пока нашёлся один рабочий и пригодный вариант для подобного случая это воспроизведение через shockwave. Или использование rtmp, там возможно не будет проблем с пере подключением потока.

Общий смысл понятен. Чтобы наблюдать замирание реже нужно выставить размер FileMaxSize побольше, с учётом максимального объёма файла фида, который может накопиться в течении заданного интервала перезагрузки ffserver. Восстанавливается поток минимум с использованием проигрывателя shockwave, при указании параметра loop=true.

В целом решение оказалось удачным. Помимо условной ротации .ffm файла получилось автоматическое восстановление связи с камерой, после пере подключения питания. И своеобразная защита от несанкционированного размещения вашего потока. Проигрыватель потока ещё должен уметь работать с прерывающимся видео, хоть это и слабый аргумент. Дополнить можно размещением в потоке watermark. Про шифрование ссылки на поток говорить не буду.

При передёргивании сетевого RJ45 хвоста камеры, поток восстанавливается -питание заводится не по сетевому кабелю(PoE), а через стандартный питающий разъём. RJ45 отсоединялся и через 5 секунд присоединялся. При отключении и включении питания поток не восстанавливается -описание решения выше.

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

Для проверки наличия видеопотока, формируемого ffserver, в винде запускаем VLC Медиа->открыть url вводим сетевой адрес http://ext.ern.al.ip:8090/DS2CD2012I_main.swf и наблюдаем видеопоток. Во многих статьях, на эту тему, рекомендуют при этом улыбаться, и действительно не удержаться.

Про относительность MaxBandwidth
Попробуем запустить столько экземпляров VLC с видео потоком, сколько сможем. Удалось запустить 5 потоков. Ниже описано почему. Судя по всему MaxBandwidth не связан с реальным ограничением пропускной способности и влияет только на максимальное значение количества запускаемых потоков, с учётом VideoBitRate. Максимальное количество потоков ffserver = MaxBandwidth/VideoBitRate. Проверено экспериментально. Если количество подключений превысить, то VLC например будет сообщать, что поток не открывается.

В текущем случае реальная скорость потока была в 2 и более раз больше MaxBandwidth. Ниже приведено изображение с иллюстрацией сказанного. Запускаем 5 VLC и MaxBandwidth был превышен в 2.2 раза.

На всякий вспомню, что MB это мегабайт/секунда. MaxBandwidth = 10240 kbit/s = 10 Mbit/s = 1.25 MB/s. Т.е. 2.712/1.25=2.2 раза. На изображении 5 потоков VLC и текущие скорости обмена на соответствующих интерфейсах. re0 -rtsp поток от IP DS-2CD2012-I 12fps 1280x960 принимаемый ffmpeg, lo0 -перекодированный поток передаваемый от ffmpeg к ffserver и nfe0 -сюда подключаются удалённые клиенты, сейчас это 5 VLC.
Если не дышать, то VLC воспроизводил 5 потоков стабильно, без каких либо проблем, ждал 1.5 часа, потом надоело. В следующий какой-то раз поток на VLC прервался через 40минут. Передача потоков происходит через Internet, не через локальную сеть. Зависания скорее всего были связаны с использованием UDP вместо TCP для обмена скамерой. Для всех типов прошивок DS-2CD2012наблюдалась проблема нестабильной передачи по UDP. Это недопустимо, приводило к множеству проблем. Использование tcp немного поправляет ситуацию.
Возникает вопрос, превышение заданного MaxBandwidth может ли как-то отразиться на стабильности работы ffserver? Пока никак не отражалось.

Скорость потока передачи видео потока с IP камеры напрямую зависит от сложности воспринимаемого камерой изображения. Затемним помещение и переведём камеру в ночной режим, чтобы снизить трафик. При смене яркости освещения, погода пасмурная, иногда прояснения на пол минуты, отваливаются 1-2 потока, приходится перезапускать. Здесь ещё не удалял .ffm файлы и не использовал tcp. Запущено 5 VLC клиентов 12fps 1280x960, общий поток максимум 3.2MB/s дневной режим, камера смотрит на колышущиеся занавески.
Закрываем окно, занавески почти не колышутся, дневной режим, изображение почти статичное -максимум 1.5MB/s.
Перемещаем камеру в полу тёмный угол, включился ночной режим, тут же отвалилось 4ре из 5 камер, перезапускаем. Изображение простое и полностью статичное. Трафик стал максимум 400KB/s и потоки стали постоянно отваливаться, поэтому трафик и стал маленьким. Работал только один, максимум два недолго потока, как только перезапускал какой либо из 5 потоков VLC, другой отваливался. Перезапустил ffserver. Всё стало как прежде 5 VLC клиентов, трафик максимум 1.4MB/s.
Мысль такая, когда камера передаёт простое изображение с низкой скоростью передачи, подключается много клиентов, затем картинка меняется, скорость передачи возрастает и превышает MaxBandwidth даже более чем в два раза. Приводит ли это к нестабильности работы ffserver? Или MaxBandwidth всего лишь условный параметр задающий максимальное количество подключений?

До этого не упоминал, но клиенты запускались на весьма посредственном ноутбуке, интел коре два, 2.4GHz, в общем загрузка для 5 VLC, с максимальными настройками камеры, всегда была полная. Попробовал запустить потоки на другой машине винда7, там вообще всё отваливалось через насколько секунд, как в браузере, так и в VLC, разбираться не стал. Уменьшил fps IP камеры с 12 до 6, разрешение до 640x480 и увеличил MaxBandwidth -проверим дело в пропускной способности, или в аппаратных ограничениях ноутбука.
Потоки стали сравнительно небольшими, запустилось 9 экземпляров VLC, затем все разом зависли.
На изображении ниже скриншот потока в Firefox, после нескольких секунд работы поток зависает с артефактами. Сравнил 2 потока, один запущен в Firefox, дрогой в VLC

Слева Firefox, справа VLC один и тот же поток. Видно, что Firefox воспроизводит поток в плохом качестве. Есть свои причины, скорее всего, на прямую, по умолчанию воспроизводится с низким качеством.

Установил в настройках камеры bandwidth = 1024 Kbp/s и fps снизил до 2 разрешение оставил 640x480. Получил следующую картину:

Запустил 5 потоков, не зависали. Редко становились нормальными. В Firefox картинка также смазанная/подтёкшая.
Оказалось, причина смазывания/подтекания изображения была в настройках DS-2CD2012-I параметр "Bitrate Type = Constant". При смене его на "Variable" и задание параметра "Quality = Highest" смазывание/подтекание исчезло/уменьшилось. Это предположение оказалось не верным, про смазывание, подтекание можно посмотреть здесь + обязательно правильно произвести настройки IP камеры. Правда вскоре опять появилось но в виде маленькой полоски внизу изображения. Причём подтёки наблюдалось только на цветном изображении дневная съёмка. На чётно белом, ночная съёмка, подтёков не наблюдалась, по началу. При fps=2 подтёки были не на всех кадрах, они то были, то нет. Выглядело так:

Обновил прошивку IP камеры с V4.0.9 до V5.0.0. В настройках камеры стало невозможно установить разрешение 640x480. Выбрал 704x576. С 2fps наблюдаются проблемы, изображение сразу же виснет и внизу изображения иногда видно размытую полосу. Прошивка DS-2CD2012-I, судя по большому количеству косяков, очень сырая. В общем 2fps для этой камеры использовать нельзя. 1fps и ниже та же беда. Работает всё от 4fps и выше. После перезапуска и перехода на English стало возможно установить 640x480. Прошивка этой камеры распознаёт родной язык браузера пользователя и по умолчанию устанавливается в Русский. Проблема была в камере. Вернулся на 4.0.9 прошивку.

Про MaxBandwidth:
При VideoBitRate=10240 kbit/s и MaxBandwidth 2048 kbit/s запускается максимум 5 VLC потоков .
При VideoBitRate=1024 kbit/s и MaxBandwidth=20480 kbit/s запускается максимум 20 VLC потоков, до сообщения "этот поток не открывается".
При VideoBitRate=4096 и MaxBandwidth 20480 запускается максимум 5 VLC потоков.
При VideoBitRate=2048 и MaxBandwidth 20480 запускается максимум 10 VLC потоков.
Потоки хоть и смазанные, но не виснут.
Отсюда, вроде очевидный вывод, максимальное количество потоков ffserver = MaxBandwidth/VideoBitRate -это если одна камера, если несколько с разным VideoBitRate, то считать сложнее, но смысл понятен.
Возможно, отваливаются/зависают потоки, в текущем случае, из-за аппаратных ограничений компьютера, на котором запускаются экземпляры VLC.

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

FileMaxSize -вроде содержит последние кадры фида. Предположим, что Preroll=15 секунд и с камеры сыпется 25fps 1280x960 -это 720000 kbit/s = 90000KB/s * 15 / 1024 = 1319 Мегабайт для 15 секунд. Многовато, да ещё если размещать в tmpfs и для нескольких камер…, но так получается. Здесь не учитывается сжатие, поэтому это максимальное значение для самого сложного случая который можно воссоздать только искусственно. Сколько нужно на самом деле, чтобы сильно не переборщить? Можно попробовать указать FileMaxSize=1024M, запустить ffserver и снимая камерой цветастое динамичное изображение в течении например 15секунд(Preroll) смотреть на размер .ffm файла. Чтобы получить динамичное изображение камеру двигать нельзя, нужно перед ней отплясывать. Запомнить его размер через 15 секунд, для надёжности увеличиваем цифру в 1.5раза, переводим в Mегабайты и задаём FileMaxSize=xxM. Для DS-2CD2012-I максимально выставляемое значение bitrate =16384kbit/s это для 25fps 1280x960 Highest Quality не знаю для какого I Frame Interval. Для 15сек FileMaxSize = 16384*15/8=30Мегабайт.

VideoIntraOnly -параметр предписывающий передавать клиентам только ключевые кадры. Это кадры, которые содержат только независимо сжатые микроблоки. Т.е. если параметр IP камеры I Frame Interval установлен в 50 и fps=15, то клиенту будет передаваться кадр раз в 3.3(3) секунды. Кадры с меж кадровым сжатием не передаются. Например, в MJPEG отсутствует меж кадровое сжатие, каждый кадр сжат индивидуально и несёт абсолютно достоверную информацию. Поэтому MJPEG и используется в системах видеонаблюдения и видео в этом формате может использоваться при правовых разбирательствах. Ниже будет подробно, с картинками, написано про I Frame Interval и его влияние на трафик. Zoneminder хранит всё принятое видео в виде .jpeg картинок и по запросу собирает из них видеофайл.

Получается, чтобы получить mjpeg из rtsp нужно I Frame Interval установить в 1, тогда каждый кадр будет ключевым и будет отсутствовать меж кадровое сжатие. Или задавать опцию VideoIntraOnly -для mjpeg или картинок должна быть задана всегда.

Убедился, что нужно обязательно удалять файл фида /dev2/shm/ffserver/feed_DS2CD2012I.ffm при запуске ffserver, иначе будет наблюдаться зависание потока через 3-5 секунд как в VLC, так и в Firefox, и в остальных клиентах. Такое наблюдалось, когда после параметра FileMaxSize=1024M, указывался, например FileMaxSize=50M. Т.е. если текущий размер /dev2/shm/feed_DS2CD2012I.ffm файла больше указанного в параметре FileMaxSize=50M. Для решения проблемы в /usr/local/etc/rc.d/ffserver прописываем, в начале файла, команду удаления .ffm файлов, расположенных в /dev2/shm/ директории: "rm /dev2/shm/*.ffm"

VideoSize -должно быть одинаково везде

Noaudio -исключить аудио поток из трансляции клиентам

Preroll 15 -полагаю это количество секунд которое должно находиться в .ffm буфере, после которого поток начнёт отдаваться клиенту. Многие клиенты буферизуют 5-10 секунд видео, нужно также, чтобы в буфере появился ключевой кадр.
VideoQMin VideoQMax -диапвзон качества картинки, не знаю при каих условиях меняется. 1 -лучшее качество, 31 -худшее. Например VideoQMin = 1 VideoQMax = 5. Только вроде логично наоборот прописывать. Но так записывали во всех встреченных конфигах.

VideoBufferSize -не разобрался на 100% что значит, предположу, что это количество kbit нужных для хранения 1секунды изображения. Для разрешения 640x480 получаем: 640*480=307200 пикселя * 24 bit = 7372800 bit * 2 fps = 14745600 бита в секунду /1024 = 14400 kbit. Для 1280x960 25fps нужно будет 720000 kbit. 89 мегабайт получается. Правда задавал 100000 при таких параметрах и что-то работало. Надеюсь прав на счёт kbit на кадры поступившие за секунду. На всякий накидываем сверху 10% от рассчитанной цифры. Встречалась такая цифра VideoBufferSize 1048576.

VideoBitRate -определял экспериментально, смотрел через '# systat -ifstat 1' сколько максимально займёт канал обмен на сетевом интерфейсе, с одной подключённой камерой. Так для DS-2CD2012-I c максимальными настройками предельное значение 16Mbit/s = 2MB/s мегабайт/секунда. Жирновато. VideoBitRate=16384 kbit/s. Учитывая, что максимальное количество потоков ffserver = MaxBandwidth/VideoBitRate, прикидываем, какая полоса потребуется для нужного количества клиентов. Разумеется это для примера, реально цифра будет гораздо меньше, т.к. 25fps и 1280x960 это особые случаи.
Попробую хоть примерно предположить, какой VideoBitRate нужно устанавливать для тех, или иных параметров камеры. Исходить буду из того, что для DS-2CD2012-I на main канале значение может быть в пределах 32-16384 Kbp/s. Т.е. 16384 Kbp/s для 25fps 1280x960 24bit color и Video Quality =Highest, правда как привязать Video Quality не знаю и I Frame Interval =1 как будет влиять тоже представляю не чётко. Video Quality и I Frame Interval пускай всегда будут одними и теми же. Ниже приведены всего лишь домыслы. Имеем 25fps 1280x960 24bit color = 720000 килопикселей в секунду при 16384 Kbp/s. Для 12fps 1280x960 24bit color = 345600 килопикселей в секунду. 720000/345600 =2.1раза. 16384 Kbp/s / 2раза = 32768 Kbp/s пускай будет 33000 Kbp/s.
Исходя из вышеописанных предположений попробуем прикинуть Max. Baudrate устанавливаемый в настройках камеры: 2fps 640x480 24bit = 14400 килопикселей в секунду. 720000/14400 = 50 раз. 16384/50=328 Kbp/s. Нестыковочка получается. При наблюдении за нагрузкой, сетевого интерфейса камеры, максимальное значение скорости доходило до 430KB/s = 3440 kbp/s. Выбираем VideoBitRate=4096. Камера должна снимать максимально динамичное, сложное и цветастое. Повторюсь, нельзя камеру вертеть в руках, нужно перед камерой плясать. Камера должна быть неподвижна. Смотрим на пиковое значение скорости обмена.

В системах видеонаблюдения к камере подключается, как правило, только один клиент -сервер. Но если к камера сама будт выступать в роли сервера и к ней будет подключаться много клиентов, то тут нужно ещё подумать, какой bitrate разрешение fps I Frame Interval задать. Не проста эта золотая середина.

Если камера сама будет выступать в роли сервера, то для себя решил определять параметр так: завожу rtsp поток с камеры в ffmpeg1 и произвожу запись в файл. Запускаю скрипт:

#!/bin/sh
/usr/local/bin/ffmpeg1 -y -r 8 -i rtsp://admin:12345@192.168.6.3/h264/ch1/main/av_stream
-b:v 4096k /1/output_file.flv

В строке запуска ffmpeg1 задаём параметр videibitrate побольше -b:v 4096k или лучше 16384k и наблюдаю за параметрами в последней строке вывода ffmpeg. При параметрах настройки камеры:

Input #0, rtsp, from 'rtsp://admin:12345@192.168.6.3/h264/ch1/main/av_stream':
  Metadata:
    title           : Media Presentation
  Duration: N/A, start: 0.753644, bitrate: N/A
    Stream #0:0: Video: h264 (Main), yuv420p, 1280x720, 8 fps, 25 tbr, 90k tbn, 16 tbc
Output #0, flv, to '/1/output_file.flv':
  Metadata:
    title           : Media Presentation
    encoder         : Lavf54.63.104
    Stream #0:0: Video: flv1 ([2][0][0][0] / 0x0002), yuv420p, 1280x720, q=2-31, 4096 kb/s, 1k tbn, 8 tbc
Stream mapping:
  Stream #0:0 -> #0:0 (h264 -> flv)

будет выводиться такая ffmpeg строка:

frame=17090 fps=8.0 q=2.0 size= 862220kB time=00:35:36.25 bitrate=3306.4kbits/s

Здесь смотрим на 2 параметра 'q' это quality меняется от 2 до 31 (2 лучшее качество 31 худшее) и 'bitrate' записываемого в файл видео. Теперь отплясываем перед камерой, для получения максимально динамичной и сложной картинки(камера должна быть неподвижна) и смотрим, чтобы q был равен 2 и значение bitrate будет максимальным для текущего разрешения, fps и других параметров. Если q не равен 2, а прыгает, то увеличиваем -b:v параметр в скрипте запуска ffmpeg1.

Полагаю, что максимально допустимый битрэйт между IP камера <-> ffmpeg1 задаётся в настройках камеры, максимальный битрэйт между ffmpeg1 <-> записываемый файл задаётся через -b:v перед именем файла.

Для одних и тех же настроек камеры:

-b:v = 8196k

frame= 154 fps=9.7 q=2.0 size= 10384kB time=00:00:19.25 bitrate=4419.2kbits/s

-b:v = 1024k

frame= 214 fps=9.1 q=21.4 size= 2089kB time=00:00:26.75 bitrate= 639.7kbits/s

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

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

I Frame Interval
В настройках, по крайней мере DS-2CD2012-I для H.264 есть параметр I Frame Interval который задаёт, через сколько кадров выдавать ключевой кадр. По умолчанию параметр был равен 100 для V4 прошивки и 50 для V5. Снизил этот параметр пока до 1 теперь каждый кадр будет ключевым. Это существенно увеличит трафик. Если сравнивать, для fps=12 640x480 VideoQuality=Highest, картинка полностью статичная, подключён один локальный VLC клиент напрямую к IP камере.
Верхнее изображение для I Frame Interval =400, среднее показывает разницу между =400, =50, =1. Нижнее то же самое но для 1280x960 и 25fps. Пики соответствуют передаче ключевого кадра:

На верхнем изображении расстояние между пиками примерно 22сек. Вывод такой, I Frame Interval к применению обязателен, в подтверждение следующий сравнительный тест:

При просмотре трафика через # systat -ifstat 1, для DS-2CD2012-I наблюдал пиковое значение скорости обмена в 1.6MB/s, когда заданные 16384 kbit/s = 2MB/s. Это для максимальных настроек первичного канала 25fps 1280x960 + наилучшее качество изображения + I Frame Interval=1.

Как бы вот