Najlepsze podejście do przesyłania strumieniowego http w czasie rzeczywistym do klienta wideo HTML5

Naprawdę utknąłem próbując zrozumieć najlepszy sposób na strumieniowe przesyłanie w czasie rzeczywistym danych wyjściowych ffmpeg do klienta HTML5 za pomocą węzła.js, ponieważ w grze jest wiele zmiennych i nie mam dużego doświadczenia w tej przestrzeni, spędzając wiele godzin na próbowaniu różnych kombinacji.

Mój przypadek użycia to:

1) Kamera Wideo IP RTSP H. 264 strumień jest pobierany przez FFMPEG i remuxed do kontenera mp4 przy użyciu następujących ustawień FFMPEG w węźle, wyjście na STDOUT. To jest uruchamiane tylko na początkowe połączenie z klientem, aby częściowe żądania zawartości nie próbowały ponownie wywołać FFMPEG.

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

2) używam serwera HTTP węzła do przechwytywania STDOUT i przesyłania strumieniowego z powrotem do klienta na żądanie klienta. Gdy klient po raz pierwszy się połączy, spawnuję powyższy wiersz poleceń FFMPEG, a następnie przesyłam strumień STDOUT do odpowiedzi HTTP.

liveFFMPEG.stdout.pipe(resp);

Użyłem również zdarzenia stream do zapisu danych FFMPEG do odpowiedzi HTTP, ale nie robi różnicy

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

Używam po nagłówku HTTP (który jest również używany i działa podczas strumieniowania wstępnie nagranych plików)

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) klient musi użyć znaczników wideo HTML5.

Nie mam problemów z odtwarzaniem strumieniowym (za pomocą fs.createReadStream z zawartością częściową HTTP 206) do klienta HTML5 plik wideo wcześniej nagrany z powyższą linią poleceń FFMPEG (ale zapisany do pliku zamiast STDOUT), więc wiem, że strumień FFMPEG jest poprawny, a nawet mogę poprawnie zobaczyć wideo na żywo w VLC, gdy połączenie z serwerem węzła HTTP.

Jednak próba streamowania na żywo z FFMPEG przez węzeł HTTP wydaje się być o wiele trudniejsza, ponieważ klient wyświetli jedną klatkę, a następnie zatrzyma. Podejrzewam, że problem polega na tym, że nie konfiguruję połączenia HTTP, aby było kompatybilne z klientem wideo HTML5. Próbowałem różnych rzeczy, takich jak używanie HTTP 206 (częściowa zawartość) i odpowiedzi 200, umieszczanie danych w buforze, a następnie przesyłanie strumieniowe bez powodzenia, więc muszę wrócić do pierwszych zasad, aby upewnić się, że jestem ustawiam to we właściwy sposób.

Oto moje zrozumienie, jak to powinno działać, proszę mnie poprawić, jeśli się mylę:

1) FFMPEG powinien być ustawiony tak, aby fragmentował wyjście i używał pustego moov (FFmpeg frag_keyframe i empty_moov MOV flagi). Oznacza to, że Klient nie używa atomu moov, który zazwyczaj znajduje się na końcu pliku, co nie jest istotne podczas przesyłania strumieniowego (bez końca pliku), ale oznacza brak możliwości szukania, co jest dobre dla mojego przypadku użycia.

2) mimo że używam MP4 fragmenty i puste MOOV, nadal muszę korzystać z częściowej zawartości HTTP, ponieważ odtwarzacz HTML5 będzie czekał, aż cały strumień zostanie pobrany przed odtwarzaniem, co przy strumieniu na żywo nigdy się nie kończy, więc jest niewykonalne.

3) nie rozumiem, dlaczego strumieniowanie strumienia STDOUT do odpowiedzi HTTP nie działa podczas streamingu na żywo jeszcze Jeśli zapisuję do pliku mogę łatwo streamować ten plik do klientów HTML5 za pomocą podobnego kodu. Może to problem z wyczuciem czasu, bo uruchomienie FFmpeg spawn zajmuje sekundę, podłącz do kamery IP i wysyłać kawałki do węzła, a zdarzenia danych węzła są również nieregularne. Jednak strumień bajtowy powinien być dokładnie taki sam jak zapis do pliku, a HTTP powinien być w stanie zaspokoić opóźnienia.

4) podczas sprawdzania logu sieciowego z klienta HTTP podczas przesyłania strumieniowego pliku MP4 utworzonego przez FFMPEG z kamery, widzę, że są 3 żądania klienta: ogólne żądanie GET dla wideo, które serwer HTTP zwraca około 40Kb, a następnie żądanie częściowej zawartości z zakresem bajtów dla Ostatnie 10K pliku, a następnie ostateczne żądanie dla bitów w środku nie załadowane. Może Klient HTML5 po otrzymaniu pierwszej odpowiedzi prosi o załadowanie ostatniej części pliku MP4 Moov atom? W takim przypadku nie będzie działać do przesyłania strumieniowego, ponieważ nie ma pliku MOOV i nie ma końca pliku.

5) sprawdzając dziennik sieci podczas próby przesyłania strumieniowego na żywo, otrzymuję przerwane początkowe żądanie z tylko około 200 bajtów odebranych, a następnie ponownie żądanie ponownie przerwane z 200 bajtów i trzecia Prośba, która ma tylko 2K długości. Nie rozumiem, dlaczego klient HTML5 przerwałby żądanie, ponieważ bajt jest dokładnie taki sam, jak mogę z powodzeniem używać podczas przesyłania strumieniowego z nagranego pliku. Wygląda na to, że node nie wysyła reszty strumienia FFmpeg do klienta, ale widzę dane FFMPEG w .na rutynowych zdarzeniach, więc dostaje się do serwera HTTP węzła FFmpeg.

6) chociaż myślę, że Orurowanie strumienia STDOUT do bufora odpowiedzi HTTP powinno działać, czy mam zbudować bufor pośredni i strumień, który pozwoli żądaniom klienta HTTP partial content poprawnie działać tak, jak to robi, gdy (pomyślnie) czyta plik? Myślę, że jest to główny powód moich problemów, jednak nie jestem dokładnie pewien w węźle, jak najlepiej to skonfigurować. I nie wiem, jak poradzić sobie z żądaniem Klienta o dane na końcu pliku, ponieważ nie ma końca pliku.

7) czy jestem na złej drodze, próbując obsłużyć 206 częściowych żądań treści i czy to praca z normalnymi odpowiedziami HTTP 200? Odpowiedzi HTTP 200 działa dobrze dla VLC, więc podejrzewam, że klient wideo HTML5 będzie działał tylko z częściowymi żądaniami treści?

Ponieważ wciąż uczę się tych rzeczy, trudno jest przejść przez różne warstwy tego problemu (FFmpeg, node, streaming, HTTP, HTML5 video), więc wszelkie wskaźniki będą bardzo mile widziane. Spędziłem wiele godzin na badaniach na tej stronie i w sieci, i nie natknąłem się na nikogo, kto był w stanie zrobić strumieniowanie w czasie rzeczywistym w węźle ale nie mogę być pierwszy i myślę, że to powinno się udać (jakoś!).