Всё оказалось проще. Брак сборки моей конкретной камеры. Лицевая накладка была установлена "вверх ногами" (развернута на 180 градусов), поэтому светодиоды подсветки были закрыты черным пластиком. Переставил накладку - теперь всё нормально. Кстати, если кто соберётся разбирать камеру, то вначале нужно снять эту самую тонкую накладку (отделить ее от черной лицевой части корпуса). Она держится на пластиковых шпеньках - ни защелок, ни клея там нет. Под ней будут болты, скрепляющие черную и белую части корпуса.
Во время файловых операций, связанных с большими объемами (например, запуск упоминавшегося скрипта copy_files.sh для отправки на ПК записей за заданную дату), камера внезапно перезагружается, не доведя до конца операцию копирования. Это так у всех, или только у меня? P.S. Иногда камера перезагружается даже при попытке скачать видеозапись на смартфон через приложение Smart Life.
Ночью в темноте камера ничего "не видит" - записывает практически черные кадры, на которых можно рассмотреть только отдельные светлые объекты (например, часы на Яндекс-колонке). Такое ощущение что ИК-подсветка не включается. Пробовал и через приложение, и через веб-интерфейс "крутить" всевозможные параметры - ничего не помогает. И попутный вопрос - у этой камеры вообще есть подсветка, и какая (видимая или ИК)?
Кажется, удалось понять принцип именования файлов и папок с видеозаписями.
Итак, имя папки означает время начала записи в секундах с полуночи 1 января 1970 года по UTC (ну, т.е. стандартное Unix Time), затем знак подчеркивания и далее 4 цифры - это суммарное количество секунд записи в файлах под папкой.
Имена файлов означают время начала записи в секундах, отсчитывая от времени, обозначаемого папкой.
Преобразуем "1756500353" из Unix Time в "человеческое время" - получаем 29.08.2025, 23:45:53. Это -0 время начала записи. Первый файл (0000.media) содержит запись с этого самого момента - т.е., с 23:45:53. Второй файл (0014.media) содержит запись с 23:45:53 + 14 секунд - т.е., с 23:46:07. ...... Последний файл (0592.media) содержит запись с 23:45:53 + 592 секунды- т.е., с 23:54:59. Ну и, соответственно, конец записи (он же - конец последнего файла) - 23:45:53 + 605 секунд, т.е. 23:55:12.
busybox в камере урезан (нет даже редактора vi и кучи команд "первой необходимости"), но тем не менее там есть апплеты ftpget и ftpput, позволяющие осуществлять файлообмен в обе стороны с бо́льшим удобством, чем tftp.
Кстати, этот урезанный busybox вполне можно заменить на более полноценный, взяв таковой из пакета Debian под архитектуру armhf (я скопировал с работающего OrangePi). Если кто опасается удалять старый busybox и заменять его на новый, то можно просто переименовать новый (например, в busybox1), положить его в папку /bin, дать права 755 и пользоваться так: busybox1 <команда> Благодаря этому мы получаем редактор vi и кучу полезных команд.
Можно попробовать модернизировать скрипт, чтобы задавать диапазон скачиваемых файлов по дате/времени "от и до" - типа такого: copy_files.sh <TFTP_Server_IP> 20250829150310-202508301005
Тут я тоже уже разобрался. Кстати, была еще проблема с доступом из Smart Life, но тоже разрулилась. Оказалось, что провайдер блокирует IP-адреса, к которым обращаются камера и приложение для установления связи и получения видеопотока.
Неплохой вариант. Работает. Однако пока не научимся расшифровывать файлы, толку от его будет мало.
Тут еще странные непонятки вылезли. По порядку:
Не устанавливаются дата/время в камере. Камера показывает 01.01.1970 и время от момента включения (при этом как учитывается заданный часовой пояс UTC+3, поэтому отсчет времени начинается с 03:00:00). Пробовал синхронизировать время и в приложении Smart Life, и через web-интерфейс само́й камеры, выставлял опцию синхронизации с NTP, менял адреса NTP-серверов - ничего не помогает, на экране по-прежнему 1970-й год. Делал сброс настроек и через web, и через Smart Life (c обнулением и полным удалением камеры) - всё безрезультатно.
Непонятки с картой памяти. Поскольку опыты с камерой были начаты 26.08.2025 (тогда еще время на камере устанавливалось нормально), то на карте памяти образовались папки "2025/08/26", "2025/08/27" и другие, соответствующие датам. После выполнения форматирования (опять же - что через Smart Life, что через web-интерфейс) вылезает сообщение, что все прошло нормально. Однако карта не очищается - приложение и веб-морда показывают, что из 14 ГБ занято 8 с небольшим, а через telnet видно, что все папки и файлы на месте. Удаление папок и файлов через telnet (командой "rm -rf ...") вроде бы как происходит, но через некоторое время все папки и файлы возвращаются. Прикол еще в том, что я вынимал карточку из камеры, удалял все папки на ПК, возвращал карточку на место и убеждался, что ничего не удалилось, всё на своих местах. И даже сброс камеры к заводским настройкам эту проблему не решает. Разобрался: сдохла карточка - вошла в режим "только чтение". Заменил карточку на новую - проблема вроде бы ушла.
Исследования продолжаются. Вот, что обнаружено из новенького: По команде форматирования карточки на ней создаются два раздела:
второй раздел (FAT32) размером 251 МБ занимает "хвост" карточки. В этот раздел помещается файл WS03T_recovery.rom, который байт в байт совпадает со скачанной с сайта производителя прошивкой. Другими словами, это готовая к употреблению прошивка текущей версии. Судя по всему, она "срабатывает" при выборе команды "сброс к заводскому состоянию"
первый раздел (ExtFAT) начинается с самого начала и занимает всё свободное место до начала второго раздела. Здесь располагаются файлы видеозаписей и фотоснимков. Принцип иерархии такой - в корне раздела единственная папка с именем "DCIM", а под ней подпапки, обозначающие годы (например, "2025"), в них подпапки с месяцами ("01" ... "12"), а в них подпапки с числами месяца ("01" ... "31"). А в тех подпапках еще подпапки. Каждая такая папка имеет имя по формату HHMMSSXXXX_YYYY, где HH, MM и SS - соответственно, часы, минуты и секунды (видимо так обозначено время начала записи). Что обозначают "XXXX" и "YYYY", пока неизвестно. Внутри этих папок размещены уже сами файлы видеозаписей. Они имеют имена, состоящие из 4 цифр и расширение ".media". Первый файл в папке имеет имя 0000.media, второй 0012.media, третий 0024.media и т.д. То есть, "число имени" каждого следующего файла на 12 больше предыдущего. Впрочем, изредка случаются исключения - например, мне попался файл 0013.media в одной из папок. В разных подпапках количество файлов разное. Размер каждого такого файла составляет чуть больше 2,8 ГБ, причем точные размеры у всех файлов разные. Также в каждой подпапке присутствует файл с расширением .jpg и именем, совпадающим с именем подпапки (без "_YYYY"). Например, в подпапке "1756239250_0020" находится файл "1756239250.jpg". Еще в каждой подпапке имеется файл ".info" со следующим JSON-содержимым: { "version": 3, "eventType": 0, "codec": 4 } Забыл еще упомянуть, что в подпапках, соответствующих числу месяца, имеется по одному файлу с именем "day_idx.bin" содержащему бинарные данные, которые явно структурированы. А теперь - печалька: все файлы видеозаписей закриптованы!
Возвращаемся на верхний уровень первого раздела карточки. Здесь, кроме папок "года" (например, "2025") еще имеются папки с именами типа "YYYYMMDD", где YYYY - год, MM - месяц и DD - число месяца. В этих папках лежит по одному файлу с именем "event.dat". Эти файлы тоже бинарные и содержат явно структурированные данные, а их имя говорит о том, что там хранятся записи о событиях.
На сегодня новостей больше нет, к сожалению. Могу только констатировать следующее: Затея с выкачиванием файлов записей с карточки через веб-интерфейс становится бессмысленной, потому что файлы закриптованы, и прочесть их на внешнем устройстве не получится.
Да, есть такое дело. Кстати, там же еще есть утилита IPCTestTool, а также софтина HVS (функциональный аналог известного софта для XM-камер CMS/VMS). Но прикол в том, что в отличие от упомянутых XM-софтин, эта не вытягивает из камеры видеозаписи.
Это не проблема. Ключ есть, получен с помощью утилиты "tuya-cli". Способ широкоизвестный, используется при интеграции в умные дома (Home Assistant, в частности).
Ну а толку-то от того, что мы его пересоберём? Мы же не сможем заменить оригинал пересобранной копией, т.к. он находится на сквоше. Пересобрать сквош можно, конечно, попытаться, но всё же перезаписывать весь раздел - это большой риск. Да и не факт, что "busybox dd" сможет переписать раздел с используемыми файлами прямо на работающем девайсе - процесс может оборваться, не дойдя до конца - камера перегрузится, а раздел-то повреждён. И что тогда?
Прошивка есть, ссылка была в статье. Но во-первых, мы пока не знаем, как ее разобрать и пересобрать. А во-вторых, не знаем, как ее устанавливать. Конечно, можно положить рядом с камерой носитель с файлом прошивки, а потом ходить вокруг камеры, бить в бубен и повторять "прошивка, установись" :-)
P.S. Да, и если можно, в следующий раз никогда не выкладывайте файлы на какие-то левые файлообменники с переадресацией на какую-то рекламу, игры и прочее.
Продолжаю копать. Ситуация такая - если верить стартовому скрипту /etc/init.d/rcS, то "вся система" запускается скриптом /usr/app/run.sh Этот скрипт (как и подавляющая часть всего того, чем он оперирует) расположена на разделе mtdblock2, который смонтирован в папку /usr/app в режиме RO. Собственно, даже если бы и не RO, то всё равно там файловая система squashfs, которая сама по себе только на чтение. Дальше - интересней. Скрипт run.sh не запускает веб-сервер (thttpd) прямой командой. Он копирует бинарник /usr/app/bin/ipcam в папку /tmp и уже оттуда его запускает. А вот внутри этого бинарника (ipcam) имеется вызов thttpd с параметром, определяющим корневую папку веб-сайта: /usr/app/bin/thttpd -d /usr/app/www/ В принципе, пользуясь имеющейся возможностью внесения изменений в корневую файловую систему (в частности, в стартовый скрипт /etc/init.d/rcS), а также наличием там порядка 14-15 МБ свободного места, можно было бы параллельно (на другом порту, естественно) запускать другой движок веб-сайта (типа lighttpd и т.п.) с нужными нами параметрами - например задать там карточку памяти в качестве корневой папки. Надо только найти софт под эту архитектуру. А какая там архитектура, я не знаю, ибо не специалист.
Рассказываю. При исследовании файловой системы с помощью Telnet'а было обнаружено, что в корне веб-сервера камеры имеются две символические ссылки, указывающие на несуществующие папки (или файлы - неважно, главное, что они не существуют).
Вот эти ссылки и объекты, на которые они указывают: /usr/app/www/img2 -> /tmp/etc/custom/www/img /usr/app/www/js2 -> /tmp/etc/custom/www/js В реале существует только путь /tmp/etc/custom. Папки www в нём нет, и соответственно нет ничего дальше. Но эту папку можно создать командой: mkdir /tmp/etc/custom/www И более того - она сохраняется даже после перезагрузки (не буду вдаваться в тонкости - просто там нормальная ФС, и раздел смонтирован в RW. Теперь мы как бы можем создать в этой папке симлинк с именем "img" или "js", указывающий на раздел карты памяти, где хранятся видеозаписи (/var/run/sdcard/1), а затем зайдя в браузере по адресу http://<IP-address>/img (или .../js - дело вкуса) увидеть содержимое карточки, а затем скачать оттуда нужные нам файлы (видеозаписи, фото и др.). Но... есть одно большое "но"! Увидеть-то эти файлы мы увидим, но скачать не сможем. Дело в том, что веб-движок камеры работает с использованием cgi-bin, а cgi-bin не позволяет скачивать исполняемые файлы. Здрассьте, скажете вы, а с каких это пор файлы видеозаписей стали исполняемыми? А всё очень просто - дело в том, что файловая система на карте памяти - ExFAT, и линуксовые атрибуты файлов на ней не поддерживаются, и поэтому все файлы как бы имеют атрибуты 777 - то есть, являются для системы исполняемыми. Что делать в этом случае? Я пока решаю эту проблему так: Символическую ссылку в папке /tmp/etc/custom/www создаю не на раздел карты памяти, а на какую-нибудь папку в корневом разделе, доступную для записи (там свободно порядка 15 МБ) - например, на папку /dev (выбор именно этой папки обусловлен тем, что она пересоздается при перезагрузке, поэтому "лишние файлы" оттуда удалятся автоматически). Затем тупо копирую с карты памяти нужные файлы видеозаписей в папку /dev (осторожно! не переборщите с количеством и объемом - если превысите свободный объем, то камера перезагрузится, и придется начинать все сначала). После этого захожу в браузере на http://<IP-address>/img, вижу все файлы в папке /dev, нахожу нужные и скачиваю их на ПК. Затем желательно эти файлы из /dev удалить (в телнетной сессии), либо перезагрузить камеру любым удобным способом. P.S. Как я и предупреждал, способ дико неудобный, да еще и камера норовит все время перезагрузиться (не нравится ей, когда кто-то в телнете долго сидит). Но другого способа я пока не нашел. P.P.S. Хочу попробовать на ПК форматнуть карточку в Ext4. Вдруг сработает? Кстати, на самой камере есть команда mkfs.vfat, а вот mkfs.ext4 нет (такая вот там реализация Бизибокса).
Кто знает, в каком формате сохраняет камера видеозаписи? И сразу же второй вопрос - есть ли относительно простой способ сохранить на ПК или смартфон файлы видеозаписей? Вариант с вытаскиванием из камеры карточки и ее чтения на компе не предлагать. Я пока нашел только сложный и предельно неудобный способ. Если кому интересно - расскажу.
Качество видео можно установить в настройках. По умолчанию там выставлено среднее качество. Плюс еще рекомендуется включить антимерцание (для Европы - 50 Гц, для Америки 60 Гц).
Это в каких единицах измерения "2.8"? Неужели, в миллионах рублей?
Да - и я имел в виду только стоимость "умного" оборудования - без котла, без механической части лифта и т.д.
Интересно, сколько денег ушло на всё это оборудование
Всё оказалось проще. Брак сборки моей конкретной камеры. Лицевая накладка была установлена "вверх ногами" (развернута на 180 градусов), поэтому светодиоды подсветки были закрыты черным пластиком. Переставил накладку - теперь всё нормально. Кстати, если кто соберётся разбирать камеру, то вначале нужно снять эту самую тонкую накладку (отделить ее от черной лицевой части корпуса). Она держится на пластиковых шпеньках - ни защелок, ни клея там нет. Под ней будут болты, скрепляющие черную и белую части корпуса.
2) Проверил. Нет свечения - ни ИК, ни видимого.
Пара вопросов по камере:
Во время файловых операций, связанных с большими объемами (например, запуск упоминавшегося скрипта copy_files.sh для отправки на ПК записей за заданную дату), камера внезапно перезагружается, не доведя до конца операцию копирования. Это так у всех, или только у меня?
P.S. Иногда камера перезагружается даже при попытке скачать видеозапись на смартфон через приложение Smart Life.
Ночью в темноте камера ничего "не видит" - записывает практически черные кадры, на которых можно рассмотреть только отдельные светлые объекты (например, часы на Яндекс-колонке). Такое ощущение что ИК-подсветка не включается. Пробовал и через приложение, и через веб-интерфейс "крутить" всевозможные параметры - ничего не помогает. И попутный вопрос - у этой камеры вообще есть подсветка, и какая (видимая или ИК)?
Кажется, удалось понять принцип именования файлов и папок с видеозаписями.
Итак, имя папки означает время начала записи в секундах с полуночи 1 января 1970 года по UTC (ну, т.е. стандартное Unix Time), затем знак подчеркивания и далее 4 цифры - это суммарное количество секунд записи в файлах под папкой.
Имена файлов означают время начала записи в секундах, отсчитывая от времени, обозначаемого папкой.
Например, имеем папку 1756500353_0605, содержащую файлы:
0000.media 0136.media 0268.media 0401.media 0536.media
0014.media 0150.media 0281.media 0414.media 0549.media
0028.media 0163.media 0294.media 0428.media 0563.media
0041.media 0176.media 0308.media 0441.media 0578.media
0054.media 0190.media 0321.media 0454.media 0592.media
0068.media 0203.media 0334.media 0468.media
0081.media 0216.media 0348.media 0481.media
0094.media 0230.media 0361.media 0494.media
0108.media 0243.media 0374.media 0509.media
0123.media 0254.media 0388.media 0523.media
Преобразуем "1756500353" из Unix Time в "человеческое время" - получаем 29.08.2025, 23:45:53. Это -0 время начала записи.
Первый файл (0000.media) содержит запись с этого самого момента - т.е., с 23:45:53.
Второй файл (0014.media) содержит запись с 23:45:53 + 14 секунд - т.е., с 23:46:07.
......
Последний файл (0592.media) содержит запись с 23:45:53 + 592 секунды- т.е., с 23:54:59.
Ну и, соответственно, конец записи (он же - конец последнего файла) - 23:45:53 + 605 секунд, т.е. 23:55:12.
busybox в камере урезан (нет даже редактора vi и кучи команд "первой необходимости"), но тем не менее там есть апплеты ftpget и ftpput, позволяющие осуществлять файлообмен в обе стороны с бо́льшим удобством, чем tftp.
Кстати, этот урезанный busybox вполне можно заменить на более полноценный, взяв таковой из пакета Debian под архитектуру armhf (я скопировал с работающего OrangePi). Если кто опасается удалять старый busybox и заменять его на новый, то можно просто переименовать новый (например, в busybox1), положить его в папку /bin, дать права 755 и пользоваться так:
busybox1 <команда>Благодаря этому мы получаем редактор vi и кучу полезных команд.
!
Ух ты! Я в восторге!
Можно попробовать модернизировать скрипт, чтобы задавать диапазон скачиваемых файлов по дате/времени "от и до" - типа такого:
copy_files.sh <TFTP_Server_IP> 20250829150310-202508301005Тут я тоже уже разобрался. Кстати, была еще проблема с доступом из Smart Life, но тоже разрулилась.
Оказалось, что провайдер блокирует IP-адреса, к которым обращаются камера и приложение для установления связи и получения видеопотока.
Неплохой вариант. Работает. Однако пока не научимся расшифровывать файлы, толку от его будет мало.
Тут еще странные непонятки вылезли. По порядку:
Не устанавливаются дата/время в камере. Камера показывает 01.01.1970 и время от момента включения (при этом как учитывается заданный часовой пояс UTC+3, поэтому отсчет времени начинается с 03:00:00). Пробовал синхронизировать время и в приложении Smart Life, и через web-интерфейс само́й камеры, выставлял опцию синхронизации с NTP, менял адреса NTP-серверов - ничего не помогает, на экране по-прежнему 1970-й год. Делал сброс настроек и через web, и через Smart Life (c обнулением и полным удалением камеры) - всё безрезультатно.
Непонятки с картой памяти. Поскольку опыты с камерой были начаты 26.08.2025 (тогда еще время на камере устанавливалось нормально), то на карте памяти образовались папки "2025/08/26", "2025/08/27" и другие, соответствующие датам. После выполнения форматирования (опять же - что через Smart Life, что через web-интерфейс) вылезает сообщение, что все прошло нормально. Однако карта не очищается - приложение и веб-морда показывают, что из 14 ГБ занято 8 с небольшим, а через telnet видно, что все папки и файлы на месте. Удаление папок и файлов через telnet (командой "rm -rf ...") вроде бы как происходит, но через некоторое время все папки и файлы возвращаются. Прикол еще в том, что я вынимал карточку из камеры, удалял все папки на ПК, возвращал карточку на место и убеждался, что ничего не удалилось, всё на своих местах. И даже сброс камеры к заводским настройкам эту проблему не решает.Разобрался: сдохла карточка - вошла в режим "только чтение". Заменил карточку на новую - проблема вроде бы ушла.
Исследования продолжаются. Вот, что обнаружено из новенького:
По команде форматирования карточки на ней создаются два раздела:
второй раздел (FAT32) размером 251 МБ занимает "хвост" карточки. В этот раздел помещается файл WS03T_recovery.rom, который байт в байт совпадает со скачанной с сайта производителя прошивкой. Другими словами, это готовая к употреблению прошивка текущей версии. Судя по всему, она "срабатывает" при выборе команды "сброс к заводскому состоянию"
первый раздел (ExtFAT) начинается с самого начала и занимает всё свободное место до начала второго раздела. Здесь располагаются файлы видеозаписей и фотоснимков. Принцип иерархии такой - в корне раздела единственная папка с именем "DCIM", а под ней подпапки, обозначающие годы (например, "2025"), в них подпапки с месяцами ("01" ... "12"), а в них подпапки с числами месяца ("01" ... "31"). А в тех подпапках еще подпапки. Каждая такая папка имеет имя по формату HHMMSSXXXX_YYYY, где HH, MM и SS - соответственно, часы, минуты и секунды (видимо так обозначено время начала записи). Что обозначают "XXXX" и "YYYY", пока неизвестно. Внутри этих папок размещены уже сами файлы видеозаписей. Они имеют имена, состоящие из 4 цифр и расширение ".media". Первый файл в папке имеет имя 0000.media, второй 0012.media, третий 0024.media и т.д. То есть, "число имени" каждого следующего файла на 12 больше предыдущего. Впрочем, изредка случаются исключения - например, мне попался файл 0013.media в одной из папок. В разных подпапках количество файлов разное. Размер каждого такого файла составляет чуть больше 2,8 ГБ, причем точные размеры у всех файлов разные. Также в каждой подпапке присутствует файл с расширением .jpg и именем, совпадающим с именем подпапки (без "_YYYY"). Например, в подпапке "1756239250_0020" находится файл "1756239250.jpg". Еще в каждой подпапке имеется файл ".info" со следующим JSON-содержимым:
{
Забыл еще упомянуть, что в подпапках, соответствующих числу месяца, имеется по одному файлу с именем "day_idx.bin" содержащему бинарные данные, которые явно структурированы."version": 3,
"eventType": 0,
"codec": 4
}
А теперь - печалька: все файлы видеозаписей закриптованы!
Возвращаемся на верхний уровень первого раздела карточки. Здесь, кроме папок "года" (например, "2025") еще имеются папки с именами типа "YYYYMMDD", где YYYY - год, MM - месяц и DD - число месяца. В этих папках лежит по одному файлу с именем "event.dat". Эти файлы тоже бинарные и содержат явно структурированные данные, а их имя говорит о том, что там хранятся записи о событиях.
На сегодня новостей больше нет, к сожалению. Могу только констатировать следующее:
Затея с выкачиванием файлов записей с карточки через веб-интерфейс становится бессмысленной, потому что файлы закриптованы, и прочесть их на внешнем устройстве не получится.
Да, есть такое дело. Кстати, там же еще есть утилита IPCTestTool, а также софтина HVS (функциональный аналог известного софта для XM-камер CMS/VMS). Но прикол в том, что в отличие от упомянутых XM-софтин, эта не вытягивает из камеры видеозаписи.
Это не проблема. Ключ есть, получен с помощью утилиты "tuya-cli". Способ широкоизвестный, используется при интеграции в умные дома (Home Assistant, в частности).
Ну а толку-то от того, что мы его пересоберём? Мы же не сможем заменить оригинал пересобранной копией, т.к. он находится на сквоше. Пересобрать сквош можно, конечно, попытаться, но всё же перезаписывать весь раздел - это большой риск. Да и не факт, что "busybox dd" сможет переписать раздел с используемыми файлами прямо на работающем девайсе - процесс может оборваться, не дойдя до конца - камера перегрузится, а раздел-то повреждён. И что тогда?
Прошивка есть, ссылка была в статье. Но во-первых, мы пока не знаем, как ее разобрать и пересобрать. А во-вторых, не знаем, как ее устанавливать. Конечно, можно положить рядом с камерой носитель с файлом прошивки, а потом ходить вокруг камеры, бить в бубен и повторять "прошивка, установись" :-)
P.S. Да, и если можно, в следующий раз никогда не выкладывайте файлы на какие-то левые файлообменники с переадресацией на какую-то рекламу, игры и прочее.
Продолжаю копать. Ситуация такая - если верить стартовому скрипту /etc/init.d/rcS, то "вся система" запускается скриптом /usr/app/run.sh
Этот скрипт (как и подавляющая часть всего того, чем он оперирует) расположена на разделе mtdblock2, который смонтирован в папку /usr/app в режиме RO. Собственно, даже если бы и не RO, то всё равно там файловая система squashfs, которая сама по себе только на чтение.
Дальше - интересней. Скрипт run.sh не запускает веб-сервер (thttpd) прямой командой. Он копирует бинарник /usr/app/bin/ipcam в папку /tmp и уже оттуда его запускает. А вот внутри этого бинарника (ipcam) имеется вызов thttpd с параметром, определяющим корневую папку веб-сайта:
/usr/app/bin/thttpd -d /usr/app/www/В принципе, пользуясь имеющейся возможностью внесения изменений в корневую файловую систему (в частности, в стартовый скрипт /etc/init.d/rcS), а также наличием там порядка 14-15 МБ свободного места, можно было бы параллельно (на другом порту, естественно) запускать другой движок веб-сайта (типа lighttpd и т.п.) с нужными нами параметрами - например задать там карточку памяти в качестве корневой папки.
Надо только найти софт под эту архитектуру. А какая там архитектура, я не знаю, ибо не специалист.
Рассказываю. При исследовании файловой системы с помощью Telnet'а было обнаружено, что в корне веб-сервера камеры имеются две символические ссылки, указывающие на несуществующие папки (или файлы - неважно, главное, что они не существуют).
Вот эти ссылки и объекты, на которые они указывают:
/usr/app/www/img2 -> /tmp/etc/custom/www/img/usr/app/www/js2 -> /tmp/etc/custom/www/js
В реале существует только путь /tmp/etc/custom. Папки www в нём нет, и соответственно нет ничего дальше.
Но эту папку можно создать командой: mkdir /tmp/etc/custom/www
И более того - она сохраняется даже после перезагрузки (не буду вдаваться в тонкости - просто там нормальная ФС, и раздел смонтирован в RW.
Теперь мы как бы можем создать в этой папке симлинк с именем "img" или "js", указывающий на раздел карты памяти, где хранятся видеозаписи (/var/run/sdcard/1), а затем зайдя в браузере по адресу http://<IP-address>/img (или .../js - дело вкуса) увидеть содержимое карточки, а затем скачать оттуда нужные нам файлы (видеозаписи, фото и др.).
Но... есть одно большое "но"! Увидеть-то эти файлы мы увидим, но скачать не сможем. Дело в том, что веб-движок камеры работает с использованием cgi-bin, а cgi-bin не позволяет скачивать исполняемые файлы. Здрассьте, скажете вы, а с каких это пор файлы видеозаписей стали исполняемыми? А всё очень просто - дело в том, что файловая система на карте памяти - ExFAT, и линуксовые атрибуты файлов на ней не поддерживаются, и поэтому все файлы как бы имеют атрибуты 777 - то есть, являются для системы исполняемыми.
Что делать в этом случае? Я пока решаю эту проблему так:
Символическую ссылку в папке /tmp/etc/custom/www создаю не на раздел карты памяти, а на какую-нибудь папку в корневом разделе, доступную для записи (там свободно порядка 15 МБ) - например, на папку /dev (выбор именно этой папки обусловлен тем, что она пересоздается при перезагрузке, поэтому "лишние файлы" оттуда удалятся автоматически). Затем тупо копирую с карты памяти нужные файлы видеозаписей в папку /dev (осторожно! не переборщите с количеством и объемом - если превысите свободный объем, то камера перезагрузится, и придется начинать все сначала). После этого захожу в браузере на http://<IP-address>/img, вижу все файлы в папке /dev, нахожу нужные и скачиваю их на ПК. Затем желательно эти файлы из /dev удалить (в телнетной сессии), либо перезагрузить камеру любым удобным способом.
P.S. Как я и предупреждал, способ дико неудобный, да еще и камера норовит все время перезагрузиться (не нравится ей, когда кто-то в телнете долго сидит). Но другого способа я пока не нашел.
P.P.S. Хочу попробовать на ПК форматнуть карточку в Ext4. Вдруг сработает? Кстати, на самой камере есть команда mkfs.vfat, а вот mkfs.ext4 нет (такая вот там реализация Бизибокса).
Кто знает, в каком формате сохраняет камера видеозаписи?
И сразу же второй вопрос - есть ли относительно простой способ сохранить на ПК или смартфон файлы видеозаписей? Вариант с вытаскиванием из камеры карточки и ее чтения на компе не предлагать.
Я пока нашел только сложный и предельно неудобный способ. Если кому интересно - расскажу.
Качество видео можно установить в настройках. По умолчанию там выставлено среднее качество. Плюс еще рекомендуется включить антимерцание (для Европы - 50 Гц, для Америки 60 Гц).