to post messages and comments.

cam

Еще немного, и я перестану на Axxon жаловаться. Выдали свежую сборку (правят косяки по видео декодеру), так нагрузка на СРУ упала с 70% обычных до 35%. Будем напоглядеть.

cam

Сердце инженера обливается кровью.
i01.i.aliimg.com
Вот скажите, как с помощью двух крутилок по 1/8 круга ТОЧНО настроить фокус!? Где, мать вашу, классическая червячная передача, которой можно точно и без проблем настроить фокус с любой задержкой, и ничего не собьётся после этого при фиксировании?!

cam

Уф. Сделал рывок, и таки заменил на 1м этаже внутренние хуськи на камеры от ipeye.
Не скажу, что всем доволен, но посмотрим как работать будут.
А, и еще надо повернуть завтра их будет, да фокус настроить... объективы варики :(

cam

А я-то думал, чего это этажная камера хоть и тоже на sofia, но так не дурит, как те что на 1м этаже.
А она на базе DM365 оказалась внезапно O_O
Слил новую прошивку (нашел по запаху). Надо будет залить.

if [ ${state} -eq 6 ];then
echo "Product Type is 5010L!";
insmod /usr/lib/modules/ov9712.ko
mknod /dev/ov9712 c 168 0
insmod /usr/lib/modules/mb88347.ko
mknod /dev/mb88347 c 134 0
/usr/sbin/fvideoencoder -i 2 -s 4 -d 0 -o 1 -h 2 -g 0 -l 0 -t 8 -j 1 -w 10 -f 1 -x 1 ${EncodeParam} &
elif [ ${state} -eq 17 ];then
echo "Product Type is K5010!";
insmod /usr/lib/modules/ov9712.ko
mknod /dev/ov9712 c 168 0
insmod /usr/lib/modules/mb88347.ko
mknod /dev/mb88347 c 134 0
/usr/sbin/fvideoencoder -i 2 -s 4 -d 0 -o 1 -h 2 -g 0 -l 0 -t 8 -j 1 -w 10 -f 1 ${EncodeParam} &
elif [ ${state} -eq 3 ];then
echo "Product Type is R5010L!";
insmod /usr/lib/modules/ov9712.ko
mknod /dev/ov9712 c 168 0
insmod /usr/lib/modules/mb88347.ko
mknod /dev/mb88347 c 134 0
/usr/sbin/fvideoencoder -i 2 -s 4 -d 0 -o 0 -h 2 -g 0 -l 0 -t 8 -j 1 -w 10 -f 1 ${EncodeParam} &

ыыыыы

cam

ipeye.ru прислали на пощупать 8 канальный DVR — прямо очень лёгкая коробочка. 2*USB, 1*SATA 2, 1*Ethernet (не знаю еще 100 или 1000), 1*VGA, 1*HDMI. Надо будет и правда пощупать — может в качестве медиасервера его запиликать?

Ура! Гавриков, которые утащили коляску, нашли. И коляску нашли у них дома.
Так что соседи получили свою коляску взад, полицейские получили успешно раскрытое дело.
Что получили гаврики не знаю, но у одного уже три судимости есть...

Ответ Axxon'а: "Нашим продукт-менеджером по IP принято решение пока не делать исправление на стороне нашего ПО, поэтому задачу закрываю."
Причем закрывают "Решено". Мухахашечка.

pelco.su
я в шоке. 360* на жалкие 4мп при 10к/с. представляю как там всё размывается как только чуть-чуть падает освещённость...
"люблю" когда в одном преждожении все максимальные характеристики выдают сразу, при том, что одновременно все максимумы недостижимы =)

Не, проблема не в освещённости. Или в ней, но непонятно что делать. Зарезал выдержку на 0.0395 (то есть гарантированно 25fps влезает); покрутил вообще всё что мог так и сяк — всё равно к вечеру упало до 8.33. Причем они еще две по разному каждая держит. Но почему?! С какого перепою?! Бред какой-то...

Не нуачо? Вы как хотите, а я зопатчил в бинарном виде DM368ю камеру — сбоя на TCP больше нет.
Всего-то обернул вызов sendRTPOverTCP в пару вызовов — makeSocketBlocking() перед, и makeSocketNonBlocking() после. Зопатчено 62 байта ^_^ (не считая тех, что зопатчены но не поменялись). Есть еще похер в похеровницах.

... Спасибо {deepweb2} за запаковку в прошивку. А то разбирать формат прошивки для обратной запаковки еще бы часа 3 сожрало. 2 @maxlapshin: 2 чая этому господину за мой счет ^____^

А вот с HiSilicon камерой у меня появилось подозрение, что FPS падает из-за включения режима LowLux, когда он начинает суммировать по три кадра для повышения освещенности. Так как днём на ярком свету — чистые 25 fps; а как вечереет — падает до 8.33.
Если будет не влом, завтра поиграюсь с настройками хусек.

if (send(socketNum, (char const*)data, dataSize, 0/*flags*/) != (int)dataSize) {
      makeSocketBlocking(socketNum);
      Boolean sendSuccess = send(socketNum, (char const*)data, dataSize, 0/*flags*/) == (int)dataSize;
      makeSocketNonBlocking(socketNum);
      return sendSuccess;
    }
    return False;
  }
а ничего, что они начало отсылают при этом дважды?
мать вашу за ногу! китайцы ни при чем!

Что я делаю не так? Взял rtp пакет; отрезал заголовок (12+cc*4 байт=12)
взял
frag=data[0]&0x1F
nal=(data[0]&0xE0)|(data[1]&0x1F)
start=data[1]&0x80
затем если
frag==7||8: write("\000\000\001"+data[2:]
frag==28 && start: write("\000\000\001"+nal+data[2:])
frag==28 && !start: write(data[2:])

Итог не играется ни в какую:
[h264 @ 0x186d680] non-existing PPS referenced
[h264 @ 0x186d680] non-existing PPS 0 referenced
[h264 @ 0x186d680] decode_slice_header error
[h264 @ 0x186d680] no frame!
[h264 @ 0x186d680] non-existing PPS referenced
[h264 @ 0x186d680] non-existing PPS 0 referenced
[h264 @ 0x186d680] decode_slice_header error
[h264 @ 0x186d680] no frame!
[h264 @ 0x186d680] non-existing PPS referenced
[h264 @ 0x186d680] non-existing PPS 0 referenced
[h264 @ 0x186d680] decode_slice_header error
[h264 @ 0x186d680] no frame!

cam

Пипец у неё крыша... fps падает при наличии большого количества подключений.
На 1-2-3 — всё нормально, 25.
На 4х — падает до 20. На 5 падает до 15. На 6 падает до 12. На 7-8 — падает до 8.
Если поубивать лишние подключения — fps восстанавливается обратно.

Н-да. Запустил локальный прокси на той же машине, начал высасывать всё из TCP потока принудительно на высочайшем приоритете.
Дождался "тормоза". В этот момент поток от камеры шел, его вычитывал (без задержек), всё буферизовалось. Но AxxonNext порвал коннект и пересоеденился. Выходит, что рвёт он сам, видимо, поймав некий таймаут...

Так, начал усиленно гонять вторую камеру. И знаете таки шо? Никаких потерь по TCP с ней нет.
Но и поток какой-то ненормальный — 33.6 RTP пакета в секунду, и 44100 кбайт в секунду.
На камере, на которой всё помирает постоянно и быстро — 250 пакетов и 330кбайт в секунду...

Заодно стало понятно, почему иногда бьётся поток целиком, иногда теряется пакет, а иногда вроде всё ок — но пакет вообще левый.
все уши растут из-за того, что пакеты шлются в несколько send()'ов, какой и в каком месте насколько поломается — один большой вопрос..

Ковырнул паршивку второй камеры. Там вообще всё зашито в какой-то бинарь под именем "Sophia", зачем-то сжатый upx. внутри нечто безымянное с коекакерской поддержкой onvif только шоп было, но с поддержкой всего и вся, включая GPS, wifi, блюпуп и фрешки.
в общем, кроссафцы, со второй камерой такой фокус не проходит.. "live555" и не пахнет — видимо, выкосили строки, или используют еще более древние куски его.

// Ага, гляжу в сырцы LIVE555. Дифф между live.2013.10.09.tar.gz и live.2014.02.19.tar.gz:
diff --git a/liveMedia/RTPInterface.cpp b/liveMedia/RTPInterface.cpp
index d45e5a8..3d88d55 100644
--- a/liveMedia/RTPInterface.cpp
+++ b/liveMedia/RTPInterface.cpp
@@ -324,19 +325,23 @@ Boolean RTPInterface::sendRTPorRTCPPacketOverTCP(u_int8_t* packet, unsigned p
 }
 
 Boolean RTPInterface::sendDataOverTCP(int socketNum, u_int8_t const* data, unsigned dataSize, Bool
-  if (send(socketNum, (char const*)data, dataSize, 0/*flags*/) != (int)dataSize) {
-    // The TCP send() failed.
-
-    if (forceSendToSucceed && envir().getErrno() == EAGAIN) {
-      // The OS's TCP send buffer has filled up (because the stream's bitrate has exceeded the cap
+  int sendResult = send(socketNum, (char const*)data, dataSize, 0/*flags*/);
+  if (sendResult < (int)dataSize) {
+    // The TCP send() failed - at least partially.
+
+    unsigned numBytesSentSoFar = sendResult < 0 ? 0 : (unsigned)sendResult;
+    if (numBytesSentSoFar > 0 || (forceSendToSucceed && envir().getErrno() == EAGAIN)) {
+      // The OS's TCP send buffer has filled up (because the stream's bitrate has exceeded
+      // the capacity of the TCP connection!).
       // Force this data write to succeed, by blocking if necessary until it does:
+      unsigned numBytesRemainingToSend = dataSize - numBytesSentSoFar;
 #ifdef DEBUG_SEND
-      fprintf(stderr, "sendDataOverTCP: resending %d-byte send (blocking)\n", dataSize); fflush(st
+      fprintf(stderr, "sendDataOverTCP: resending %d-byte send (blocking)\n", numBytesRemainingToS
 #endif
       makeSocketBlocking(socketNum);
-      Boolean sendSuccess = send(socketNum, (char const*)data, dataSize, 0/*flags*/) == (int)dataS
+      sendResult = send(socketNum, (char const*)(&data[numBytesSentSoFar]), numBytesRemainingToSen
       makeSocketNonBlocking(socketNum);
-      return sendSuccess;
+      return sendResult == (int)numBytesRemainingToSend;
     }
     return False;
   }

// А вот вырезка из changelog.txt:
2013.12.04:
- Updated the "sendDataOverTCP()" function (in "RTPInterface.cpp") to allow for the possibility of
  one of the "send()" calls partially succeeding - i.e., writing some, but not all, of its data.
- Fixed a couple of minor bugs.  (Thanks to "maksqwe1@ukr.net".)

// Вывод? Матерный.