заменить сабж на что угодно. Основная задача - писать видео с
локального источника (в теории - до 16 каналов), записывать
непрерывно, чтобы можно было сетевым клиентом под эхотаг и под
оффтопик смотреть в реальном времени и запись. Всякие фичи по анализу изображения типа детектор движения и прочее - не интересны. Бонусом приветствуется возможность кроме аналога подцепить айпишные камеры. Главное - писать в полном разрешении все каналы. Там того разрешения
то кот наплакал, его еще уменьшать считаю неприемлимым.
Может, проще кучу vlc с автоподнятием по падению? Так точно можно записывать без перекодировки, если от камеры видеопоток идёт.
А есть пример рабочей конфигурации с ffmpeg? Я пока не осилил сделать, чтобы он и стриминг и запись одновременно делал.Может, проще кучу vlc с автоподнятием по падению? Так точно можно
записывать без перекодировки, если от камеры видеопоток идёт.
VLC - штука рабочая, но несколько неудобная. Делал я как-то стриминг-сервер
с ТВ тюнера. А потом переделал на ffmpeg, получилось лучше.
VLC - штука рабочая, но несколько неудобная. Делал я как-тоА есть пример рабочей конфигурации с ffmpeg? Я пока не осилил сделать, чтобы он и стриминг и запись одновременно делал. В принципе идея
стриминг-сервер с ТВ тюнера. А потом переделал на ffmpeg,
получилось лучше.
неплохая. Меня устроит, если оно будет на сервере записывать, а на
клиента только в реальном времени контент отдавать. А запись, случись
что, можно уже взять с сервера вручную и посмотреть.
Вот как-то так. ffmpeg захватывает, жмет и пишет на диск. А клиентам с диска
раздает nginx.
#!/bin/sh
ROOT_DIR="/var/www/video"
ARCHIVE_DIR=$ROOT_DIR/archive
STREAM_DIR=$ARCHIVE_DIR/`date +%Y%m%d%H%M`
mkdir "$STREAM_DIR" || exit 1
CAPTURE_OPTIONS="-f video4linux2 -channel 1 -s 720x576 -i /dev/video0 -thread_queue_size 1024 -f alsa -ar 44100 -ac 2 -i hw:0,0"
STREAM_OPTIONS="-f hls -vf crop=700:570:8:5 -c:a aac -ar 44100 -b:a 128k -c:v libx264 -g 48 -keyint_min 48 -b:v 1250k -maxrate 1600k -bufsize 3200k -pix_fmt yuv420p -hls_time 10 -hls_playlist_type event -hls_segment_filename
$STREAM_DIR/video%04d.ts $STREAM_DIR/stream.m3u8"
/opt/ffmpeg/bin/ffmpeg $CAPTURE_OPTIONS $STREAM_OPTIONS
Интересное решение, но есть несколько но.
1. Как у него с задержкой? Я так понимяу, что задержка будет минимум
на длину одного фрагмента. Чем длиннее фрагмент, тем больше задержка,
а чем короче, тем потом неудобнее пользоваться сохраненным архивом.
2.
А будет ли оно работать, если вместо libx264 будет mpeg4 ? У меня все уперлось в эту проблему. Пока что изобразил решение на базе ffserver.
о ни в одном браузере ни с одним плеером в mpeg4 не хочет показывать.
Вот с libx264 - то пожалуйста сколько угодно. о у меня была
первоочередная задача уйти от использования libx264 в любых его проявлениях, ибо у меня и в один то поток в реальном времени не тянет,
а хотелось бы их 16 запихнуть.
Core2duo, 720*576*25fps. Даже если один поток и потянет, то мне это все равно мало. Меня бы mpeg4 вполне устроило, лишь2.
А будет ли оно работать, если вместо libx264 будет mpeg4 ? У меня все
уперлось в эту проблему. Пока что изобразил решение на базе ffserver.
о ни в одном браузере ни с одним плеером в mpeg4 не хочет показывать.
Вот с libx264 - то пожалуйста сколько угодно. о у меня была
первоочередная задача уйти от использования libx264 в любых его
проявлениях, ибо у меня и в один то поток в реальном времени не тянет,
а хотелось бы их 16 запихнуть.
Странно, что даже один поток не тянет. Core i7 1 поколения нормально справляется, теоретически должен даже 4 потока вывозить, по числу ядер. Или
там разрешение большое и битрейт?
Sysop: | Angel Ripoll |
---|---|
Location: | Madrid, Spain |
Users: | 11 |
Nodes: | 8 (0 / 8) |
Uptime: | 45:18:14 |
Calls: | 302 |
Calls today: | 2 |
Files: | 2,759 |
Messages: | 61,063 |