Ладно вам по коммерцию, как бы вот меня сейчас не забанили ...
Разделась матрешка китайская, отдалась и снова оделась, это я образно, конечно

$ telnet 192.168.8.61
Trying 192.168.8.61...
Connected to 192.168.8.61.
Escape character is '^]'.

(none) login: admin
Password:


BusyBox v1.12.1 (2013-01-23 14:34:02 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

# cat /etc_ro/motd
Welcome to
_______ _______ ___ __ ____ _ _ ___
| ___ \| __ || | |__|| \ | || | / /
| |___| || |__| || |__ __ | \| || |/ /
| _ /| _ || || || |\ || \
|__| \__\|__| |__||______||__||_| \____||_|\___\

=System Architecture Department=

# ps axw
PID USER VSZ STAT COMMAND
1 admin 2084 S init
2 admin 0 SWN [ksoftirqd/0]
3 admin 0 SW< [events/0]
4 admin 0 SW< [khelper]
5 admin 0 SW< [kthread]
28 admin 0 SW< [kblockd/0]
31 admin 0 SW< [khubd]
45 admin 0 SW< [kswapd0]
46 admin 0 SW [pdflush]
47 admin 0 SW [pdflush]
48 admin 0 SW< [aio/0]
49 admin 0 SW< [cifsoplockd]
50 admin 0 SW< [cifsdnotifyd]
608 admin 0 SW [mtdblockd]
690 admin 1372 S nvram_daemon
693 admin 1440 S mydlinkevent
763 admin 0 SW [RtmpCmdQTask]
764 admin 0 SW [RtmpWscTask]
809 admin 1772 S alphapd
835 admin 1372 S ntpclient -s -c 0 -h ntp1.dlink.com -i 86400
842 admin 1472 S schedule
845 admin 1500 S lanconfig
846 admin 1372 S tftpupload
901 admin 1696 S pcmcmd -s -q 11025
908 admin 4472 S h264
915 admin 4556 S uvc_stream -b -m 0 -g 5 -e 5
917 admin 1168 S lld2d br0
924 admin 2084 S telnetd
926 admin 2088 S /bin/sh
956 admin 1464 S /mydlink/dcp -i br0 -m DCS-933L
957 admin 3204 S /mydlink/signalc
960 admin 2088 S /bin/sh /mydlink/mydlink-watch-dog.sh
997 admin 7236 S ftpputvideo
1764 admin 2092 S -sh
1797 admin 2080 S sleep 30
1804 admin 2084 R ps axw
# top
Mem: 39580K used, 17856K free, 0K shrd, 0K buff, 19136K cached
CPU: 23% usr 7% sys 0% nice 69% idle 0% io 0% irq 0% softirq
Load average: 0.33 0.19 0.11
PID PPID USER STAT VSZ %MEM %CPU COMMAND
1958 1764 admin R 2088 4% 15% top
915 1 admin R 4556 8% 8% uvc_stream -b -m 0 -g 5 -e 5
908 1 admin S 4472 8% 8% h264
997 1 admin R 7236 13% 0% ftpputvideo
957 1 admin S 3204 6% 0% /mydlink/signalc
1957 1 admin S 2108 4% 0% avirecord 4096 10 x x x /tmp/Kitchen-
1764 924 admin S 2096 4% 0% -sh
960 1 admin S 2088 4% 0% /bin/sh /mydlink/mydlink-watch-dog.sh
926 1 admin S 2088 4% 0% /bin/sh
1 0 admin S 2084 4% 0% init
924 1 admin S 2084 4% 0% telnetd
1953 960 admin S 2080 4% 0% sleep 30
809 1 admin S 1772 3% 0% alphapd
901 1 admin S 1696 3% 0% pcmcmd -s -q 11025
845 1 admin S 1500 3% 0% lanconfig
842 1 admin S 1472 3% 0% schedule
956 1 admin S 1464 3% 0% /mydlink/dcp -i br0 -m DCS-933L
693 1 admin S 1440 3% 0% mydlinkevent
690 1 admin S 1372 2% 0% nvram_daemon
835 1 admin S 1372 2% 0% ntpclient -s -c 0 -h ntp1.dlink.com -

Почему матрешка и как ее раздевать/одевать расскажу завтра, поздно уже, а с утра работу работать надо.

Ждём с нетерпением!

Всем доброго дня !

Как и обещал, подробно описываю процесс "раздевания/одевания" матрешки,
почему "матрешки", потому что структура фирмаря вложенная, на матрешку
похожа, пока все одежки снимешь/оденешь - употеешь.

Перед тем как начать, нам понадобятся GPL Source Codе (взять тут: http://tsd.dlink.com.tw/),
из него нам надо:
- dcs933l/bin/addchecksum
- lzma - придется собрать из исходников: cd dcs933l/toolchain/lzma-4.32.0beta5;make
почему штатный не подходит, который есть в большинстве дистрибутивов скажу в процессе
-gen_init_cpio - тоже собираем:
cd dcs933l/RT288x_SDK/source/linux-2.6.21.x/usr
gcc -o gen_init_cpio gen_init_cpio.c
-dcs933l/RT288x_SDK/source/linux-2.6.21.x/usr/scripts/gen_initramfs_list.sh
-mkimage либо штатный, из пакета uboot-tools, либо сами соберите из SDK:
cd dc933l/RT288x_SDK/source/user/mkimage
make

Создадим каталог bin в какой-либо папке, сложим туда все это добро, для удобства.
$ ls bin
addchecksum gen_init_cpio gen_initramfs_list.sh lzma mkimage

Раздевать будем первую прошивку - dcs933l_v100_b14.bin

Приступим, внешняя одежка нашей мартешки состоит из двух половинок,
верней и нижней:
Uboot - бутлоадер, фиксированный размер UBOOT_SIZE = 0x50000
Kernel Image - собственно ядро, фиксированный размер KERNEL_SIZE = 0x7B0000

Надеюсь понятно, что эти размеры от версии к версии прошивки не меняются.
Бутлоадер нас не интересует, его мы трогать не будем, самое интересное
находится "ниже пояса", вот оттуда и начнем


Внешний осмотр, на всякий случай:
$ binwalk dcs933l_v100_b14.bin

DECIMAL HEX DESCRIPTION
-------------------------------------------------------------------------------------------------------------------
0 0x0 uImage header, header size: 64 bytes, header CRC: 0x9DBEC62, created: Wed Jan 23 10:40:42 2013, image size: 128448 bytes, Data Address: 0x80200000, Entry Point: 0x80200000, data CRC: 0x334BA6BE, OS: Linux, CPU: MIPS, image type: Standalone Program, compression type: none, image name: "SPI Flash Image"
99312 0x183F0 U-Boot boot loader reference
125639 0x1EAC7 LZMA compressed data, properties: 0x40, dictionary size: 65536 bytes, uncompressed size: 64 bytes
125663 0x1EADF LZMA compressed data, properties: 0x40, dictionary size: 65536 bytes, uncompressed size: 128 bytes
125687 0x1EAF7 LZMA compressed data, properties: 0x41, dictionary size: 65536 bytes, uncompressed size: 128 bytes
327680 0x50000 uImage header, header size: 64 bytes, header CRC: 0xC4713770, created: Wed Jan 23 10:40:37 2013, image size: 6356808 bytes, Data Address: 0x80000000, Entry Point: 0x8037E000, data CRC: 0x4ED2D8B7, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "Linux Kernel Image"
327744 0x50040 LZMA compressed data, properties: 0x5D, dictionary size: 33554432 bytes, uncompressed size: 8927701 bytes

binwalk не ошибся, вторая половина 327680==0x50000
достанем ее
dd if=dcs933l_v100_b14.bin iflag=skip_bytes skip=327680 of=part2

Да, забыл сказать, обе половинки записаны в формате uImage

$ file part2
part2: u-boot legacy uImage, Linux Kernel Image, Linux/MIPS, OS Kernel Image (lzma), 6356808 bytes, Wed Jan 23 10:40:37 2013, Load Address: 0x80000000, Entry Point: 0x8037E000, Header CRC: 0xC4713770, Data CRC: 0x4ED2D8B7

или

$ binwalk part2

DECIMAL HEX DESCRIPTION
-------------------------------------------------------------------------------------------------------------------
0 0x0 uImage header, header size: 64 bytes, header CRC: 0xC4713770, created: Wed Jan 23 10:40:37 2013, image size: 6356808 bytes, Data Address: 0x80000000, Entry Point: 0x8037E000, data CRC: 0x4ED2D8B7, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "Linux Kernel Image"
64 0x40 LZMA compressed data, properties: 0x5D, dictionary size: 33554432 bytes, uncompressed size: 8927701 bytes


$ mkimage -l part2
mkimage: ERROR: "part2" has corrupted data!

Не волнуйтесь, все в порядке, дело в том, что после uImage вторая половинка добита паддингом 0xFF,
дабы добрать фиксированный размер 0x7B0000.
Как мы видим из binwalk (или file) выше, размер блока данных uImage 6356808 байт,
плюс заголовок 64 байта, получаем полный размер uImage 6356872
Достанем его:

$ dd if=part2 bs=6356872 count=1 of=uImage
1+0 записей считано
1+0 записей написано
скопировано 6356872 байта (6,4 MB), 0,0634447 c, 100 MB/c

А теперь посмотрим:

$ file uImage
uImage: u-boot legacy uImage, Linux Kernel Image, Linux/MIPS, OS Kernel Image (lzma), 6356808 bytes, Wed Jan 23 10:40:37 2013, Load Address: 0x80000000, Entry Point: 0x8037E000, Header CRC: 0xC4713770, Data CRC: 0x4ED2D8B7

$ binwalk uImage

DECIMAL HEX DESCRIPTION
-------------------------------------------------------------------------------------------------------------------
0 0x0 uImage header, header size: 64 bytes, header CRC: 0xC4713770, created: Wed Jan 23 10:40:37 2013, image size: 6356808 bytes, Data Address: 0x80000000, Entry Point: 0x8037E000, data CRC: 0x4ED2D8B7, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "Linux Kernel Image"
64 0x40 LZMA compressed data, properties: 0x5D, dictionary size: 33554432 bytes, uncompressed size: 8927701 bytes

$ bin/mkimage -l uImage
Image Name: Linux Kernel Image
Created: Wed Jan 23 10:40:37 2013
Image Type: MIPS Linux Kernel Image (lzma compressed)
Data Size: 6356808 Bytes = 6207.82 kB = 6.06 MB
Load Address: 0x80000000
Entry Point: 0x8037E000
Kernel Size: 0x00000000

Ну во, все в порядке, запомните Load Address и Entry Point, нужны при "одевании".
Внутри uImage ядро то и лежит, зажатое lzma.

Снимем еще одну одежку (срезаем заголовок uImage):

$ dd if=./uImage iflag=skip_bytes skip=64 of=zImage.lzma
12415+1 записей считано
12415+1 записей написано
скопировано 6356808 байт (6,4 MB), 0,0342254 c, 186 MB/c

$ lzma -t zImage.lzma - не ругнулся, значит все OK

Еще одну одежку снимаем:
$ lzcat zImage.lzma > zImage

Ну во, теперь имеем нормальное linux ядро, к которому в конце, совершенно штатно
приклеен ramfs (он то нас и интересует).

Поехали дальше:
$ binwalk zImage

DECIMAL HEX DESCRIPTION
-------------------------------------------------------------------------------------------------------------------
3211340 0x31004C Linux kernel version "2.6.21 (andy@ipcam-linux.alphanetworks.com) (gcc version 3.4.2)etworks.com) (gcc version 3.4.2) #1319 Wed Jan 23 14:40:30 CST "
3355636 0x3333F4 Copyright string: " (c) 2011 Alpha Networks Inc.***** free audio buffer error 1 "
3620355 0x373E03 LZMA compressed data, properties: 0x40, dictionary size: 65536 bytes, uncompressed size: 64 bytes
3620379 0x373E1B LZMA compressed data, properties: 0x40, dictionary size: 65536 bytes, uncompressed size: 128 bytes
3620403 0x373E33 LZMA compressed data, properties: 0x41, dictionary size: 65536 bytes, uncompressed size: 128 bytes
3796992 0x39F000 LZMA compressed data, properties: 0x5D, dictionary size: 1048576 bytes, uncompressed size: 16344576 bytes

в середине binwalk ошибся, конечно, а вот последняя строка правильная (по размеру понять можно).

3796992 - смещение ramfs, достанем его:

$ dd if=zImage iflag=skip_bytes skip=3796992 of=ramfs.cpio.lzma
10020+1 записей считано
10020+1 записей написано
скопировано 5130709 байт (5,1 MB), 0,0279981 c, 183 MB/c

Чуть-чуть осталось, уже нижнее белье пошло
Ramfs стандартно - это cpio архив, зажатый:

$ lzcat ramfs.cpio.lzma > ramfs.cpio


Последний шаг в раздевании придется рутом сделать, дабы сохранить UID у файлов, не знаю
насколько они важны, но на всякий случай:
$ mkdir ramfs;su root -c "cd ramfs;cpio -idmv --no-absolute-filenames < ../ramfs.cpio"

--no-absolute-filenames - без этого не запускайте, перетрет системные, т.к. в архиве все начинается с "/".

Ну вот, имеем раздетой нашу матрешку (каждый имеет в меру своей испорченности )

Поматросили маленько, не бросать же ее в таком виде, давайте "одевать" будем

В обратном порядке.
Cобираем cpio.В штатном cpio не на нашел как из относительного пути
сделать абсолютный при сборке архива, а в исходном архиве они все с "/" начинаются, не знаю насколько
это важно, по документации вроде как не возбраняется, но ломать это правило не стал, с chroot тоже возиться лень было,
поэтому взял тулзы из SDK.

сначала список архива:
$ su root -c "bin/gen_initramfs_list.sh ramfs > file.list"

теперь сам архив:
$ su root -c "bin/gen_init_cpio file.list > my_ramfs.cpio"
$ su root -c "chown XXX:XXX my_ramfs.cpio "
Заглядываем внутрь - все пути с "/" начинаются, UID и права на месте

Далее:
$ bin/lzma -z -k -f -9 my_ramfs.cpio
В начале я упоминал, почему не штатный lzma, потому, что штатный более свежей
версии, он пишет сигнатуру, которую binwalk потом распознать не может,
а вдруг нам снова раздевать захочется


$ file my_ramfs.cpio.lzma
my_ramfs.cpio.lzma: data
Это нормально, а вот если штатным зажать, то file скажет, что это архив.



Теперь давайте приклеем сей ramfs к ядру, как и было:

Смотрим в исходный:
$ binwalk zImage

DECIMAL HEX DESCRIPTION
-------------------------------------------------------------------------------------------------------------------
3211340 0x31004C Linux kernel version "2.6.21 (andy@ipcam-linux.alphanetworks.com) (gcc version 3.4.2)etworks.com) (gcc version 3.4.2) #1319 Wed Jan 23 14:40:30 CST "
3355636 0x3333F4 Copyright string: " (c) 2011 Alpha Networks Inc.***** free audio buffer error 1 "
3620355 0x373E03 LZMA compressed data, properties: 0x40, dictionary size: 65536 bytes, uncompressed size: 64 bytes
3620379 0x373E1B LZMA compressed data, properties: 0x40, dictionary size: 65536 bytes, uncompressed size: 128 bytes
3620403 0x373E33 LZMA compressed data, properties: 0x41, dictionary size: 65536 bytes, uncompressed size: 128 bytes
3796992 0x39F000 LZMA compressed data, properties: 0x5D, dictionary size: 1048576 bytes, uncompressed size: 16344576 bytes

3796992 - смещение куда его положить надо

Откусываем kernel образ:
$ dd if=zImage bs=3796992 count=1 of=my_zImage
1+0 записей считано
1+0 записей написано
скопировано 3796992 байта (3,8 MB), 0,00848172 c, 448 MB/c

Приклеиваем ramfs:
$ cat my_ramfs.cpio.lzma >> my_zImage

Проверочка:
$ binwalk my_zImage

DECIMAL HEX DESCRIPTION
-------------------------------------------------------------------------------------------------------------------
3211340 0x31004C Linux kernel version "2.6.21 (andy@ipcam-linux.alphanetworks.com) (gcc version 3.4.2)etworks.com) (gcc version 3.4.2) #1319 Wed Jan 23 14:40:30 CST "
3355636 0x3333F4 Copyright string: " (c) 2011 Alpha Networks Inc.***** free audio buffer error 1 "
3620355 0x373E03 LZMA compressed data, properties: 0x40, dictionary size: 65536 bytes, uncompressed size: 64 bytes
3620379 0x373E1B LZMA compressed data, properties: 0x40, dictionary size: 65536 bytes, uncompressed size: 128 bytes
3620403 0x373E33 LZMA compressed data, properties: 0x41, dictionary size: 65536 bytes, uncompressed size: 128 bytes
3796992 0x39F000 LZMA compressed data, properties: 0x5D, dictionary size: 33554432 bytes, uncompressed size: 16344576 bytes

16344576 - Это cpio image size

$ ls -ln my_ramfs.cpio
-rw-rw-r-- 1 1000 1000 16344576 янв. 14 22:18 my_ramfs.cpio
Все четко, совпадает.


Одеваем дальше:
$ bin/lzma -z -k -f -9 my_zImage

Теперь сей образ надо вложить в структуру uImage. Вспоминаем цифири Load Address и Entry Point, который запомнили
в начале, даем команду:

$ bin/mkimage -A mips -O linux -T kernel -C lzma -a 80000000 -e 8037E000 -n "Linux Kernel Image" -d my_zImage.lzma my_uImage
Image Name: Linux Kernel Image
Created: Tue Jan 14 22:35:29 2014
Image Type: MIPS Linux Kernel Image (lzma compressed)
Data Size: 6157708 Bytes = 6013.39 kB = 5.87 MB
Load Address: 0x80000000
Entry Point: 0x8037E000
Kernel Size: 0x00000000


Смотрим что получилось:
$ file my_uImage
my_uImage: u-boot legacy uImage, Linux Kernel Image, Linux/MIPS, OS Kernel Image (lzma), 6157708 bytes, Tue Jan 14 22:35:29 2014, Load Address: 0x80000000, Entry Point: 0x8037E000, Header CRC: 0xAFA99227, Data CRC: 0xFBE8FA4E

[dennis@htpc my-1.00b14]$ binwalk my_uImage

DECIMAL HEX DESCRIPTION
-------------------------------------------------------------------------------------------------------------------
0 0x0 uImage header, header size: 64 bytes, header CRC: 0xAFA99227, created: Tue Jan 14 22:35:29 2014, image size: 6157708 bytes, Data Address: 0x80000000, Entry Point: 0x8037E000, data CRC: 0xFBE8FA4E, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "Linux Kernel Image"
64 0x40 LZMA compressed data, properties: 0x5D, dictionary size: 33554432 bytes, uncompressed size: 8731174 bytes


Уххх ..., осталось только образ фирмваря склеить ...

Как я говорил, он из двух половинок состоит:
UBOOT_SIZE = 0x50000
KERNEL_SIZE = 0x7B0000

Верхнюю мы не трогаем, это бутлоадер (327680 == 0x50000)

$ dd if=dcs933l_v100_b14.bin bs=327680 count=1 of=my_firmware.bin
1+0 записей считано
1+0 записей написано
скопировано 327680 байт (328 kB), 0,000830688 c, 394 MB/c

А теперь добавляем наш uImage (0x7B0000 == 8060928)
$ cat my_uImage >> my_firmware.bin

Немного арифметики, фирмварь надо добить до размера 8388608 (327680+8060928)
паттерном 0xFF

$ ls -ln my_uImage
-rw-rw-r-- 1 1000 1000 6157772 янв. 14 22:35 my_uImage

$ echo "8060928-6157772"|bc
1903156 - это размер padding-а

$ dd if=/dev/zero count=1 bs=1903156 2>/dev/null |tr \\000 \\377 >> my_firmware.bin

И последний шаг - контрольная сумма:
$ bin/addchecksum my_firmware.bin


Смотрим что получилось:
$ ls -ln dcs933l_v100_b14.bin my_firmware.bin
-rw-r--r-- 1 1000 1000 8388608 янв. 23 2013 dcs933l_v100_b14.bin
-rw-rw-r-- 1 1000 1000 8388608 янв. 14 22:51 my_firmware.bin

$ binwalk my_firmware.bin

DECIMAL HEX DESCRIPTION
-------------------------------------------------------------------------------------------------------------------
0 0x0 uImage header, header size: 64 bytes, header CRC: 0x9DBEC62, created: Wed Jan 23 10:40:42 2013, image size: 128448 bytes, Data Address: 0x80200000, Entry Point: 0x80200000, data CRC: 0x334BA6BE, OS: Linux, CPU: MIPS, image type: Standalone Program, compression type: none, image name: "SPI Flash Image"
99312 0x183F0 U-Boot boot loader reference
125639 0x1EAC7 LZMA compressed data, properties: 0x40, dictionary size: 65536 bytes, uncompressed size: 64 bytes
125663 0x1EADF LZMA compressed data, properties: 0x40, dictionary size: 65536 bytes, uncompressed size: 128 bytes
125687 0x1EAF7 LZMA compressed data, properties: 0x41, dictionary size: 65536 bytes, uncompressed size: 128 bytes
327680 0x50000 uImage header, header size: 64 bytes, header CRC: 0xAFA99227, created: Tue Jan 14 22:35:29 2014, image size: 6157708 bytes, Data Address: 0x80000000, Entry Point: 0x8037E000, data CRC: 0xFBE8FA4E, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "Linux Kernel Image"
327744 0x50040 LZMA compressed data, properties: 0x5D, dictionary size: 33554432 bytes, uncompressed size: 8731174 bytes



Все.
А дальше - сами знаете что делать !

Ваааау, вот это круто!!! Апплодирую стоя и пост утаскиваю в избранное!
А поставленной цели добились? Прошивка прошла нормально? Как теперь камера работает не тестили?

Вчера не успел разобрать новую прошивку, и вставить туда busybox (ftpputvideo) от старой, сейчас займусь,
заодно mydlink выкину и cifs попробую включить, в смысле, монтируется cifs без проблем, успел попробовать,
а вот чтоб клипы сбрасывал, надо в nvram параметры прописать. Отпишу как закончу.

Ну что, все в порядке, в новой прошивке старый busybox, он же ftpputvideo,
прогнал через тесты из моего первого поста - все в порядке, не глючит.
Выкинул mydlink, включил telnet.
Сброс видео на cifs тоже работает.

Отличная работа! Опишите пожалуйста, как сделали CIFS и telnet и как всё это настраивать?

Телнет есть в прошивке штатно, но не стартует, впишите такую строчку в /etc_ro/inittab:
::respawn:/usr/sbin/telnetd

CIFS - процесс cifsrecord, есть штатно, но не стартует на загрузке,
по причине отсутствия конфигурации в nvram.
Как записать nvram - пока я это сделал ручками, телнет, надеюсь уже работает, тогда входим в девайс
и даем такие команды:

nvram_set 2860 CifsServerFolder //xxx.xxx.xxx.xxx/yyyy - это шара
nvram_set 2860 CifsUserName ваш_юзер
nvram_set 2860 CifsPassword ваш_пароль
nvram_set 2860 CifsScheduleMode 2 - по детектору движения (0 и 1 не смотрел, мне не надо было, кто-то из них постоянная запись, кто-то по расписанию)
nvram_set 2860 CifsMaxRecordTime 1 - время в минутах
nvram_set 2860 CifsFullAction 0 - что делать если место в шаре кончилось: 0 - ничего не делать, 1 - вытирать старые файлы
nvram_set 2860 CifsScheduleEnable 1 - Разрешить сброс на cifs

и ребутим камеру, после ребута в вашей шаре (и на камере в /mnt/VIDEO)
наблюдаем структуру каталогов соответственно дате/времени а в них авишники.

Вообще говоря, в alphapd (это http сервер длинковский, морда, грубо говоря) все есть для конфигурации
параметров CIFS, не хватает только самих форм в /etc_ro/web и нескольких cgi, при желании, сделать
форму и вставить ее в штатную морду - как два пальца об асфальт.
Кому хочется - смотрите сюда: /etc_ro/web

А у меня вопрос к знатокам. Префикс у файлов при сбросе на CIFS - "DV_", навело на мысль не для DviewCam ли оставили
скрытую возможность CIFS ? Никто не подключал камеру к dviewcam, каким образом она видео сбрасывает ?
По идее, dviewcam может CIFS через LANDAP включить, наверное.

Всем привет !

Неужели знатоков нет ? Что никто не подключал камеру к DviewCam ?

Программеров,наверное, нет здесь...
А в каком плане подключал?
У меня есть пока времени и камера в локалке 933 и т.д...что надо затестить? И как это сделать?

Вот ,например, занимался вчера такой штукой как запуск D-ViewCam не из под админа ОС ( W7 pro sp1),а из под юзера,пользователя (D-ViewCam 3/5, OC-Win7)
облазил весь реестр,доступы и т.п ..но пока не выходит каменный цветок.
Как,например, сделано в других системах, правда платных : даёшь юзеру полные доступы на некотырые ветки реестров, а также папок и вуаля..заводи юзера ос и ставь ему систему видеонаблюдения...и этот юзер и лазить не будет в виндах куда ему не надо...
Вещь нужная..кто в теме знает о чём собственно я.

Опять наверное придётся Вам самому это делать... Лично я помочь не могу, у меня малюсенький линуксовый сервер и всё пишется туда, ессесно никакого DViewCam'а и в помине нету.

Да, собственно, как я писал двумя постами выше, хотел понять, как DviewCam пишет видео
(сам то я его не использую, вот и решил спросить).
Иными словами, есть несколько вариантов:

1 - Использует поток MJPEG + поток аудио (все через через http), потом все это дело склеивает/кодирует (ооочень мало вероятно,
программеры тоже не дураки, имея камеру с аппаратным H264)
2 - открывает, опять таки по HTTP, H264 URL и пишет сей поток (тоже мало вероятно)
3 - использует настройки камеры для сброса на ftp, в данном случае DviewCam сам становится
ftp сервером, и, по идее, это должно быть видно в морде камеры.
4 - Использует выше описанную возможность сброса клипов на CIFS.

Проверить можно очень просто - надо запустить снифер, и посмотреть на какие порты хоста DviewCam
"льет" камера.

Сей час убегаю.Завтра вам поподробнее потестю.
Навскидку MainConsol( DViewCam) по http приходит 2 потока от камеры - 1 видео 1 звук.

Спасибо, будем ждать



Это скорее всего "Live View". А вот запись она должна вестись средствами камеры,
детектор движения, например, не будет же DviewCam сам jpeg-и парсить с каждой камеры.
В моем понимании он должен настроить Motion Detector в камере и сказать ей же,
сбрасывай туда-то так-то, вот теперь вопрос как - штатно по ftp (должен при этом изменить
параметры ftp в настройках (морде) камеры), либо, сброс на CIFS, в этом случае FTP параметры
камеры не меняются, т.е., камера сбрасывает и на ftp и на cifs. Я, к стати наблюдал за камерой
в такой ситуации, CPU почти не напрягается (h264 аппаратный), висят 2 процесса avirecord,
процентов по 5-8 от процессора откусывают, и все работает замечательно.