2012-12-26 17 views
5

Korzystanie z Motion na Linuksie, każda kamera internetowa jest serwowana jako strumień na własnym porcie. Chciałbym teraz obsłużyć te strumienie, wszystkie na tym samym porcie, używając Node.js.Rura strumienia MJPEG za pośrednictwem proxy Node.js

  • Edytuj: To rozwiązanie działa. Musiałem dostać ciąg brzegowy ze strumienia MJPEG oryginału (który był „BoundaryString” w moim filmie config)
 

app.get('/motion', function(req, res) { 

    var boundary = "BoundaryString"; 

    var options = { 
    // host to forward to 
    host: '192.168.1.2', 
    // port to forward to 
    port: 8302, 
    // path to forward to 
    path: '/', 
    // request method 
    method: 'GET', 
    // headers to send 
    headers: req.headers 
    }; 

    var creq = http.request(options, function(cres) { 

     res.setHeader('Content-Type', 'multipart/x-mixed-replace;boundary="' + boundary + '"'); 
     res.setHeader('Connection', 'close'); 
     res.setHeader('Pragma', 'no-cache'); 
     res.setHeader('Cache-Control', 'no-cache, private'); 
     res.setHeader('Expires', 0); 
     res.setHeader('Max-Age', 0); 

    // wait for data 
    cres.on('data', function(chunk){ 
     res.write(chunk); 
    }); 

    cres.on('close', function(){ 
     // closed, let's end client request as well 
     res.writeHead(cres.statusCode); 
     res.end(); 
    }); 

    }).on('error', function(e) { 
    // we got an error, return 500 error to client and log error 
    console.log(e.message); 
    res.writeHead(500); 
    res.end(); 
    }); 

    creq.end(); 

}); 
 

Myślę ten serwuje strumień MJPEG/w 192.168.1.2:8302 jako ruch , ale tak nie jest. Może dlatego, że nigdy się nie kończy, a ten przykład proxy nie był tak naprawdę przykładem transmisji strumieniowej?

+0

Można zamiast tego użyć opcji nginx. – david

+2

To musi być rozwiązanie węzła. – skerit

Odpowiedz

1

Przesyłanie strumieniowe przez HTTP nie jest problemem. Robię to regularnie z Węzłem. Myślę, że masz problem z tym, że nie wysyłasz nagłówka typu treści do klienta. Przechodzisz od razu do zapisu danych bez wysyłania żadnych nagłówków odpowiedzi.

Pamiętaj, aby wysłać właściwy nagłówek treści z powrotem do klienta składającego żądanie, przed wysłaniem rzeczywistych danych treści.

Być może trzeba będzie handle multipart responses, jeśli klient HTTP węzła nie robi tego za Ciebie.

Polecam również debugowanie tego za pomocą Wireshark, dzięki czemu można dokładnie zobaczyć, co jest wysyłane i odbierane. To pomoże ci szybko rozwiązać podobne problemy.

Należy również zauważyć, że niektórzy klienci mają problem z kodowaniem kodowanym, czyli to, co Node wyśle, jeśli nie określisz długości zawartości (której nie możesz, ponieważ jest ona nieokreślona). Jeśli chcesz wyłączyć kodowane kodowanie, zapoznaj się z moją odpowiedzią tutaj: https://stackoverflow.com/a/11589937/362536 Po prostu musisz wyłączyć: response.useChunkedEncodingByDefault = false;. Nie rób tego, chyba że musisz! I pamiętaj, aby wysłać w tym nagłówku Connection: close!

+0

Chunk-thing jest problemem dla strumienia mjpeg. Widzę, że normalny strumień jpeg jest zawsze podawany jako jedna całość. Powinienem więc poczekać na całą ramkę, a dopiero potem wysłać ją do klienta. – skerit

+1

Ah, znalazłem! W nagłówku odpowiedzi potrzebowałem ustawić granicę wieloczęściową używaną w oryginalnym strumieniu mjpeg (który w ruchu jest zawsze taki sam "BoundaryString") W ten sposób mógłbym przesłać fragmenty bez dodawania do niego żadnych danych. – skerit

0

To, co musisz zrobić, to zażądać strumienia mjpeg, gdy jest to konieczne, w jednym wątku, i odpytać każdego klienta za pomocą mjpeg lub jpeg (jeśli potrzebujesz wsparcia dla IE).

Powiązane problemy