Как удобно накопить 1 млн отдельных JPEG?

Делай поддиректории, имя которых — n символов из начала имени жпега, в них клади.

Но 1млн - это очень мало. Почему от этого количества ext4 должно стать плохо?

% find /media/data -type f | wc -l
509572

Есть только эта фича: ежесекундно обновляемая картинка по урлу.

Это называется mjpeg. И его, кажется, можно спокойно сконвертить в нормальный кодек. А складывать по 1млн файлов, никому от этого хорошо не будет :)

Возьми в качестве основы этот скрипт Небольшой сценарий для сканирования изображений. С автоматическим определением сканера.

Cast dk-
Вроде как чувак не понаслышке знаком с вопросом складирования тучи картинок.
Не придет сам - поройся в его темах.

Как браузер кэши хранит? Вот так же надо, поддиректории делать. А если всё в одну? Не знаю, может тормозить начнет.

Пиши сразу в avi/MJPEG, напиши свой код. Я так и делал.

https://github.com/andrey-utkin/imgs2video

Можно базу данных, например:

INSERT INTO camera VALUES (pg_read_file('/path/to/file')::bytea);

p.s. За одно и с метадатой (номер камеры, дата etc.) проще будет работать.

вообще-то правильная вторая (неозвученная) половина вопроса - а что TC хочет делать с этими кадрами ? То есть как использовать..

Складировать то похрен как, всё абы как не сложно - можно файло-помойкой, можно по каталогам, можно в базу, можно добавлять к видеопотоку, можно покадрово в gif/png/tiff..а лучше вообще в /dev/null :-)

Есть такой формат баз данных для JPEG, AVI его зовут ;)

главное все в один каталог не пихать :) любая фс подохнет (в смысле лагать будет).

ТС.
Правильный таймлапс (восприятие плавности движения и т.п.) это когда выдержка кадра равна 0.5 времени паузы между кадрами.

Тебе правильно joy4eg про MJPEG советует. Он так и отдаётся всегда сервером как отдельные картинки, просто в HTTP заголовке есть пометка, что это кино. Попробуй скормить свой урл напрямую ffmpeg'у. Если не пойдёт, то можешь попробовать вручную указать формат mpjpeg или mjpeg: ffmpeg -f mpjpeg -i http://....

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

Если ты таки хочешь сразу клеить кучу отдельных джипежек, то у ffmpeg есть jpeg_pipe, работает вот так:

cat frames/*.jpg | ffmpeg -f jpeg_pipe -r 60 -i pipe:0 -c:v copy movie.mp4

Джипежки просто завернутся в MJPEG кодек в mp4 контейнер. Можно сразу перекодировать, ну ты знаешь.

То есть, ты можешь curl'ом или скриптом, например, выкачивать джипежки и сразу отдавать их ffmpeg'у без сохранения в отдельные файлы:

while true; do
    curl http://url/to/your/file.jpg
    sleep 1 # это, конечно, булшит, но ты меня понел, да?
done | ffmpeg -f jpeg_pipe -r 60 -i pipe:0 -c:v copy movie.mp4

Я не проверял, но должно работать.

-r 60

Ещё проще — ты можешь свалить все джипежки в один файл:

while true; do
    curl http://url/to/your/file.jpg
    sleep 1
done > mymovie.mjpeg

И он корректно будет распознан ffmpeg'ом. Фреймрейт только надо будет вручную указывать. Я, кстати, не знаю, что будет делать curl при 404, но, согласно здравому смыслу, в stdout ничего писаться не должно.

если 1M - это потолок, то можно спокойно вылить в 1 каталог, мой роутер вполне справляется с разгребанием картинок с камер (правда USB), там только ls тормозит, ffmpeg это нипочём. Если больше, я бы создавал каталог с текущей датой и писал туда. Если 1 кадр - 1 секунда, то их будет 86400 на каталог - это немного. Вопрос тут в том, что с ними потом будет происходить - если только генерация таймлапсов по ffmpeg - больше ничего не нужно делать, если нужна обработка, отдача в веб, поиск - лучше сформировать ключи быстрого доступа, я это делал симлинками, и каталоги с разными критериями, двтв/время, камера, alarm/idle, и тп. Если отдавать в web, можно добавить запись в (sqlite) базейку и демона, который сформирует картинки разных размеров и статические html, который будет обрабатывать 10-20 картинок за раз и останавливаться при повышении загрузки.

да, не надо потом пытаться делать ls -l в каталоге с картинками и говорить вах-вах тормозит. ls читает данные из каждого inode. Также ни один каталожный сервис туда ходить не должен. Самой файловой системе пофиг.

Есть такой формат баз данных для JPEG, AVI его зовут ;)

Для jpeg есть motion jpeg - mjpeg. В середине 90х годов были даже аппаратные решения для работы с mjpeg. Как пример Matrox Animation Station.

главное все в один каталог не пихать :) любая фс подохнет (в смысле лагать будет).

Злостное 4.2
Лагать будет только файлменеджер при заходе в такой каталог. А так, большинству современных фс (нет, fat32 не является современной фс) пофиг на количество файлов в каталоге. man Двоичные_деревья

AVI + JPEG это не оно самое?

AVI + JPEG это не оно самое?

Не, там контейнер другой.

AVI

Зачем это говно, когда есть нормальный mkv?

Ну вот, вопрос для Эдика, а он самозабанился

главное все в один каталог не пихать :) любая фс подохнет (в смысле лагать будет).

Враньё.

Пиши в один файл, будет нормальный MJPEG-поток. К нему потом можно даже довесить заголовок и получить AVI.

Лучше накапливать картинки за каждый час и каждый же час компилировать видео тем же ffmpeg. При реализации надо будет обязательно учесть что связь с камерой может валиться.