Лучший подход для реальных http время потокового видео HTML5 клиент

Я действительно застрял, пытаясь понять лучший способ потоковой передачи вывода ffmpeg в реальном времени клиенту HTML5 с помощью узла.js, так как в игре есть несколько переменных, и у меня нет большого опыта в этом пространстве, проведя много часов, пробуя разные комбинации.

мой вариант использования:

1) поток видеокамеры RTSP H. 264 IP выбран FFMPEG и remuxed в контейнер mp4 используя следующие установки FFMPEG в узле, выходе к STDOUT. Это запускайте только начальное клиентское соединение, чтобы частичные запросы содержимого не пытались снова создать FFMPEG.

liveFFMPEG = child_process.spawn("ffmpeg", [
                "-i", "rtsp://admin:12345@192.168.1.234:554" , "-vcodec", "copy", "-f",
                "mp4", "-reset_timestamps", "1", "-movflags", "frag_keyframe+empty_moov", 
                "-"   // output to stdout
                ],  {detached: false});

2) я использую HTTP-сервер узла для захвата STDOUT и потока, который возвращается клиенту по запросу клиента. Когда клиент сначала подключается, я порождаю вышеуказанную командную строку FFMPEG, а затем передаю поток STDOUT в ответ HTTP.

liveFFMPEG.stdout.pipe(resp);

Я также использовал событие stream для записи данных FFMPEG в HTTP-ответ, но не делает разница

xliveFFMPEG.stdout.on("data",function(data) {
        resp.write(data);
}

Я использую следующий заголовок HTTP (который также используется и работает при воспроизведении предварительно записанных файлов)

var total = 999999999         // fake a large file
var partialstart = 0
var partialend = total - 1

if (range !== undefined) {
    var parts = range.replace(/bytes=/, "").split("-"); 
    var partialstart = parts[0]; 
    var partialend = parts[1];
} 

var start = parseInt(partialstart, 10); 
var end = partialend ? parseInt(partialend, 10) : total;   // fake a large file if no range reques 

var chunksize = (end-start)+1; 

resp.writeHead(206, {
                  'Transfer-Encoding': 'chunked'
                 , 'Content-Type': 'video/mp4'
                 , 'Content-Length': chunksize // large size to fake a file
                 , 'Accept-Ranges': 'bytes ' + start + "-" + end + "/" + total
});

3) клиент должен использовать видео Теги HTML5.

у меня нет проблем с потоковым воспроизведением (с использованием fs.createReadStream с 206 http частичным содержимым) клиенту HTML5 видеофайл, ранее записанный с помощью вышеупомянутой командной строки FFMPEG (но сохраненный в файл вместо STDOUT), поэтому я знаю, что поток FFMPEG правильный, и Я даже могу правильно видеть потоковое видео в VLC при подключении к серверу HTTP-узла.

однако попытка потоковой передачи из FFMPEG через узел HTTP кажется намного сложнее, так как клиент отобразит один кадр, а затем остановится. Я подозреваю, что проблема в том, что я не настраиваю HTTP-соединение, чтобы быть совместимым с HTML5 video client. Я пробовал различные вещи, такие как использование HTTP 206 (частичное содержимое) и 200 ответов, помещая данные в буфер, а затем потоковое не повезло, поэтому мне нужно вернуться к первым принципам, чтобы убедиться, что я настраиваю это правильно.

вот мое понимание как это должно работать, поправьте меня, если я ошибаюсь:

1) FFMPEG должен быть настроен для фрагментации вывода и использования пустого Moov (флаги ffmpeg frag_keyframe и empty_moov mov). Это означает, что клиент не использует атом moov, который обычно находится в конце файла, который не имеет отношения к потоковой передаче (нет конца файла), но означает нет поиск возможного, что хорошо для моего случая использования.

2) хотя я использую фрагменты MP4 и пустой MOOV, я все равно должен использовать HTTP-частичный контент, так как HTML5-плеер будет ждать, пока весь поток не будет загружен перед воспроизведением, что с живым потоком никогда не заканчивается, поэтому не работает.

3) я не понимаю, почему передача потока STDOUT в HTTP-ответ не работает при потоковой передаче в реальном времени, если я сохраняю файл, я могу легко передать этот файл клиентам HTML5, используя подобный кодекс. Возможно, это проблема времени, поскольку для запуска ffmpeg spawn требуется секунда, подключение к IP-камере и отправка фрагментов в узел, а события данных узла также нерегулярны. Однако bytestream должен быть точно таким же, как сохранение в файл, и HTTP должен иметь возможность обслуживать задержки.

4) при проверке сетевого журнала от клиента HTTP при потоковой передаче файла MP4, созданного FFMPEG с камеры, я вижу, что есть 3 клиентских запроса: общий запрос GET для видео, которое HTTP-сервер возвращает около 40Kb, затем частичный запрос контента с диапазоном байтов для последнего 10K файла, затем окончательный запрос на биты в середине не загружен. Может быть, клиент HTML5 после получения первого ответа запрашивает последнюю часть файла для загрузки mp4 Moov atom? Если это так, он не будет работать для потоковой передачи, поскольку нет файла MOOV и нет конца файла.

5) при проверке сетевого журнала при попытке потокового видео я получаю прерванный первоначальный запрос с полученным только около 200 байтами, затем повторный запрос снова прерван с 200 байтами и третьим запросом, который составляет всего 2K. Я не понимаю, почему клиент HTML5 прерывает запрос, поскольку bytestream точно такой же, как я могу успешно использовать при потоковой передаче из записанного файла. Также кажется, что узел не отправляет остальную часть потока FFMPEG клиенту, но я вижу данные FFMPEG в .на рутине события, поэтому он попадает в узел ffmpeg HTTP сервер.

6) хотя я думаю, что передача потока STDOUT в буфер ответа HTTP должна работать, должен ли я создавать промежуточный буфер и поток, который позволит http-частичным клиентским запросам контента правильно работать, как это происходит, когда он (успешно) читает файл? Я думаю, что это основная причина моих проблем, однако я не совсем уверен в узле, как лучше всего настроить это. И я не знаю, как обрабатывать запрос клиента на данные в конце файла отсутствует конец файла.

7) я на неправильном пути, пытаясь обработать 206 частичных запросов контента, и должен ли это работать с обычными 200 HTTP-ответами? HTTP 200 ответов отлично работает для VLC, поэтому я подозреваю, что HTML5 video client будет работать только с частичными запросами контента?

поскольку я все еще изучаю этот материал, его трудно работать через различные слои этой проблемы (FFMPEG, node, streaming, HTTP, HTML5 video), поэтому любые указатели будут высоко оценены. У меня есть потратил часы на исследование на этом сайте и в сети, и я не встречал никого, кто смог бы сделать потоковую передачу в реальном времени в узле, но я не могу быть первым, и я думаю, что это должно быть в состоянии работать (как-то!).