HTML5 video istemcisine gerçek zamanlı http akışına en iyi yaklaşım


213

Gerçekten, fdefler gerçek zamanlı çıktısını node.js kullanarak bir HTML5 istemcisine aktarmanın en iyi yolunu anlamaya çalışırken takılıp kaldım. farklı kombinasyonları denemek için uzun saatler geçirdim.

Benim kullanım durumum:

1) IP video kamera RTSP H.264 akışı, FFMPEG tarafından alınır ve STDOUT'a çıkış olarak, düğümdeki aşağıdaki FFMPEG ayarları kullanılarak bir mp4 kabına yeniden atılır. Bu yalnızca ilk istemci bağlantısında çalıştırılır, böylece kısmi içerik istekleri FFMPEG'i yeniden oluşturmaya çalışmaz.

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) STDOUT'u yakalamak ve istemci isteği üzerine istemciye geri göndermek için http sunucusunu kullanıyorum. İstemci ilk bağlandığında yukarıdaki FFMPEG komut satırını oluşturdum ve STDOUT akışını HTTP yanıtına aktarıyorum.

liveFFMPEG.stdout.pipe(resp);

Ben de HTTP yanıtı FFMPEG veri yazmak için stream olayı kullandım ama hiçbir fark etmez

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

Aşağıdaki HTTP üstbilgisini kullanıyorum (önceden kaydedilmiş dosyaları yürütürken de kullanılıyor ve çalışıyor)

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) İstemci HTML5 video etiketlerini kullanmalıdır.

Daha önce yukarıdaki FFMPEG komut satırı (ancak STDOUT yerine bir dosyaya kaydedilmiş) bir video dosyası HTML5 istemcisine oynatma akış (206 HTTP kısmi içeriği ile fs.createReadStream kullanarak) ile hiçbir sorunum yok, bu yüzden FFMPEG akışı biliyorum doğrudur ve HTTP düğüm sunucusuna bağlanırken VLC'de video canlı akışını doğru bir şekilde görebiliyorum.

Ancak HTTP düğümü üzerinden FFMPEG'den canlı yayın yapmaya çalışmak, istemci bir kareyi görüntüleyip durduğundan çok daha zor görünüyor. Sorunun, HTTP bağlantısını HTML5 video istemcisi ile uyumlu olacak şekilde ayarlamamasından şüpheleniyorum. HTTP 206 (kısmi içerik) ve 200 yanıt kullanma gibi çeşitli şeyler denedim, veriyi bir ara belleğe koyarak sonra şanssız akışla denedim, bu yüzden bunu doğru ayarladığımdan emin olmak için ilk ilkelere geri dönmeliyim yol.

İşte bunun nasıl çalışması gerektiği konusundaki anlayışım, lütfen yanılıyorsam beni düzeltin:

1) FFMPEG, çıktıyı parçalayacak ve boş bir moov (FFMPEG frag_keyframe ve empty_moov mov bayrakları) kullanacak şekilde ayarlanmalıdır. Bu, istemcinin genellikle dosyanın sonunda olan ve akış sırasında ilgili olmayan (dosya sonu yok) moov atomunu kullanmadığı, ancak benim kullanım durumum için uygun olan hiçbir arama mümkün olmadığı anlamına gelir.

2) MP4 parçaları ve boş MOOV kullansam da, hala HTTP kısmi içerik kullanmam gerekiyor, çünkü HTML5 oynatıcı oynatılmadan önce tüm akış indirilene kadar bekleyecek, bu da canlı akışla hiç bitmiyor, bu yüzden işlenemez.

3) STDOUT akışını neden HTTP yanıtına çevirmenin canlı akış sırasında işe yaramadığını anlamıyorum, ancak bir dosyaya kaydedersem bu dosyayı benzer kodu kullanarak HTML5 istemcilerine kolayca aktarabilirim. Belki FFMPEG spawn'ın başlaması, IP kameraya bağlanması ve düğüme parçalar göndermesi ve düğüm veri olaylarının da düzensiz olması bir zamanlama sorunudur. Ancak, bytestream bir dosyaya kaydetmeyle tamamen aynı olmalıdır ve HTTP gecikmeleri karşılayabilmelidir.

4) FFMPEG tarafından oluşturulan bir MP4 dosyasını kameradan aktarırken HTTP istemcisinden ağ günlüğünü kontrol ederken, 3 istemci isteği olduğunu görüyorum: HTTP sunucusunun yaklaşık 40Kb, ardından bir kısmi döndürdüğü video için genel bir GET isteği Dosyanın son 10K'sı için bir bayt aralığına sahip içerik isteği, daha sonra ortadaki bitler için son bir istek yüklenmedi. HTML5 istemcisi ilk yanıtı aldıktan sonra dosyanın MP4 MOOV atomunu yüklemek için son bölümünü istiyor? Bu durumda, MOOV dosyası ve dosyanın sonu olmadığı için akış için çalışmaz.

5) Canlı akış gerçekleştirmeye çalışırken ağ günlüğünü kontrol ederken, yalnızca yaklaşık 200 bayt alınan iptal edilmiş bir ilk istek alıyorum, sonra yeniden 200 bayt ve yalnızca 2K uzunluğunda üçüncü bir istek ile iptal edildi. HTML5 istemcisinin neden bytestream'in kaydedilmiş bir dosyadan akış yaparken başarıyla kullanabildiğim ile aynı olduğunu neden iptal edeceğini anlamıyorum. Ayrıca düğüm FFMPEG akışının geri kalanını istemciye göndermiyor gibi görünüyor, ancak FFMPEG düğümü HTTP sunucusuna ulaşırken .on olay yordamındaki FFMPEG verilerini görebiliyorum.

6) Her ne kadar STDOUT akışının HTTP yanıt arabelleğine bağlanmasının işe yarayacağını düşünmeme rağmen, HTTP kısmi içerik istemcisinin bir dosyayı (başarıyla) okuduğunda olduğu gibi düzgün çalışmasına izin verecek bir ara arabellek ve akış oluşturmam gerekiyor mu? ? Bu benim sorunlarımın ana nedeni olduğunu düşünüyorum, ancak Düğümde en iyi nasıl ayarlayacağından tam olarak emin değilim. Ve dosya sonu olmadığı için dosyanın sonundaki veriler için bir istemci isteğinin nasıl işleneceğini bilmiyorum.

7) 206 kısmi içerik isteğini ele almaya çalışırken yanlış yolda mıyım ve bu normal 200 HTTP yanıtıyla mı çalışmalı? HTTP 200 yanıtları VLC için iyi çalışıyor, bu yüzden HTML5 video istemcisinin yalnızca kısmi içerik istekleriyle çalışacağından şüpheleniyorum?

Ben hala bu şeyleri öğrenmek gibi bu sorunun çeşitli katmanları (FFMPEG, düğüm, akış, HTTP, HTML5 video) ile çalışmak zor bu yüzden herhangi bir işaretçiler büyük takdir edilecektir. Bu sitede ve internette saatlerce araştırma yaptım ve düğümde gerçek zamanlı akış yapabilen kimseyle karşılaşmadım ama ilk olamıyorum ve bunun bir şekilde çalışabilmesi gerektiğini düşünüyorum (bir şekilde !).


4
Bu zor bir konu. Her şey sırayla. Ayarladığınız mı Content-Typekafanın içinde? Yığın kodlama mı kullanıyorsunuz? Ben buradan başlardım. Ayrıca, HTML5 akış için gerekli işlevselliği sağlamaz, buradan daha fazla bilgi edinebilirsiniz . Büyük olasılıkla iyi desteklenmediğini düşündüğünüz için video akışını kendi yöntemlerinizi kullanarak tamponlamak ve oynatmak için bir yol uygulamanız gerekecektir ( buraya bakın ). Ayrıca Google'da MediaSource API'sına gidin.
tsturzl

Cevap için teşekkürler. Evet, içerik türü 'video / mp4'tür ve bu kod video dosyaları akışı için çalışır. Maalesef MediaSource yalnızca krom, diğer tarayıcıları desteklemem gerekiyor. HTML5 video istemcisinin bir HTTP akış sunucusuyla nasıl etkileşime girdiğine dair bir spesifikasyon var mı? Ne yapmak istiyorum eminim, sadece tam olarak nasıl emin değilim (node.js ile ama eğer daha kolay ise C # veya C ++ kullanabilirsiniz)
deandob

2
Sorun arka ucunda değil. Video akışını gayet iyi yapıyorsunuz. Sorun ön ucunuzda / istemcinizde, akışınızı kendiniz uygulamanız gerekiyor. HTML5 yalnızca akışları işlemez. Büyük olasılıkla tarayıcı başına seçenekleri keşfetmeniz gerekir. Video etiketi ve medya API'ları için w3 standartlarını okumak iyi bir başlangıç ​​olabilir.
tsturzl

O görünüyor gerektiğini bu işi yapmak mümkün olması. Kesin bir cevap sunmuyorum, ancak bu sorunun tarayıcının video akışındaki bir sonraki karede değil mp4 konteyner başlığının / atomlarının kalanını beklediğiyle ilgili olduğundan şüpheleniyorum . Çok uzun bir video için MOOV atomu gönderirsiniz (böylece oynatıcı talep etmeye devam eder) ve diğer beklenen başlıklar ve sonra ffmpeg'den kopyalamaya başlarsanız bu işe yarayabilir. Ayrıca, tarama yapamayacakları için tarayıcıdaki js'yi kullanarak fırçalama çubuğunu gizlemeniz gerekir.
jwriteclub

Her gün daha iyi tarayıcılar arası destek alan WebRTC'yi düşünmenizi öneririm .
Alex Cohn

Yanıtlar:


209

EDIT 3: IOS 10'dan itibaren HLS, parçalanmış mp4 dosyalarını destekleyecektir. Şimdi cevap, bir DASH ve HLS manifest ile parçalanmış mp4 varlıkları oluşturmaktır. > Flash, iOS9 ve altı ve IE 10 ve altı gibi davranmayın.

Bu satırın altındaki her şey güncel değil. Bunu gelecek kuşaklar için burada tutmak.


DÜZENLEME 2: Yorumlarda yer alan kişilerin işaret ettiği gibi, işler değişir. Hemen hemen tüm tarayıcılar AVC / AAC kodeklerini destekleyecektir. iOS hala HLS gerektirir. Ancak hls.js gibi adaptörler aracılığıyla MSE'de HLS oynayabilirsiniz. İOS'a ihtiyacınız varsa yeni yanıt HLS + hls.js'dir. veya sadece Parçalanmış MP4 (yani DASH)

Videonun ve özellikle canlı videonun çok zor olmasının birçok nedeni vardır. (Lütfen orijinal sorunun HTML5 videosunun bir gereklilik olduğunu belirtti, ancak asker açıklamalarda Flash'ın mümkün olduğunu belirtti. Bu yüzden hemen bu soru yanıltıcıdır)

İlk olarak şunu ifade edeceğim: HTML5 ÜZERİNDE CANLI AKIŞ İÇİN RESMİ DESTEK YOK . Saldırılar var, ancak kilometreniz değişebilir.

EDIT: Ben bu cevabı yazdım beri Medya Kaynağı Uzantıları olgunlaştı ve artık uygulanabilir bir seçenek haline çok yakın. Çoğu büyük tarayıcıda desteklenirler. IOS bir duraklama olmaya devam ediyor.

Ardından, İstek üzerine video (VOD) ve canlı videonun çok farklı olduğunu anlamanız gerekir. Evet, ikisi de video, ancak sorunlar farklı, bu yüzden formatlar farklı. Örneğin, bilgisayarınızdaki saat olması gerekenden% 1 daha hızlı çalışırsa, VOD'da fark etmezsiniz. Canlı video ile, video gerçekleşmeden önce oynatmaya çalışacaksınız. Devam eden bir canlı video akışına katılmak istiyorsanız, kod çözücüyü başlatmak için gerekli verilere ihtiyacınız vardır, bu nedenle akışta tekrar edilmeli veya banttan gönderilmelidir. VOD ile aradıkları dosyanın başlangıcını istediğiniz noktaya okuyabilirsiniz.

Şimdi biraz kazalım.

Platformlar:

  • iOS
  • PC
  • Mac
  • Android

Codec:

  • VP8 / 9
  • h.264
  • thora (vp3)

Tarayıcılarda canlı video için yaygın Yayınlama yöntemleri:

  • DASH (HTTP)
  • HLS (HTTP)
  • flaş (RTMP)
  • flaş (HDS)

Tarayıcılarda VOD için ortak Dağıtım yöntemleri:

  • DASH (HTTP Akışı)
  • HLS (HTTP Akışı)
  • flaş (RTMP)
  • flash (HTTP Akışı)
  • MP4 (HTTP sözde akışı)
  • MKV ve OOG hakkında konuşmayacağım çünkü onları çok iyi tanımıyorum.

html5 video etiketi:

  • MP4
  • webm
  • ogg

Hangi tarayıcıların hangi formatları desteklediğine bakalım

Safari:

  • HLS (yalnızca iOS ve mac)
  • h.264
  • MP4

Firefox

  • DASH (MSE ile ama h64 olmadan)
  • h.264 yalnızca Flash ile!
  • VP9
  • MP4
  • OGG
  • Webm

IE

  • flaş
  • DASH (yalnızca MSE IE 11+ üzerinden)
  • h.264
  • MP4

Krom

  • flaş
  • DASH (MSE aracılığıyla)
  • h.264
  • VP9
  • MP4
  • webm
  • ogg

MP4 canlı video için kullanılamaz (NOT: DASH, MP4'ün bir üst kümesidir, bu yüzden bununla karıştırmayın). MP4 iki parçaya ayrılır: moov ve mdat. mdat ham ses video verilerini içerir. Ama endekslenmedi, bu yüzden moov olmadan işe yaramaz. Moov, mdat'taki tüm verilerin bir dizinini içerir. Ancak biçimi nedeniyle, HER çerçevenin zaman damgaları ve boyutu bilinene kadar 'düzleştirilemez'. Çerçeve boyutlarını 'lifleyen' bir moov inşa etmek mümkün olabilir, ancak bant genişliği akıllıcadır.

Yani her yere teslim etmek istiyorsanız, en az ortak paydayı bulmamız gerekir. Flash örneğine başvurmadan burada LCD olmadığını göreceksiniz:

  • iOS yalnızca h.264 videoyu destekler. ve sadece HLS'yi canlı olarak destekler.
  • Flash kullanmazsanız, Firefox h.264'ü desteklemez
  • Flash iOS'ta çalışmıyor

LCD'ye en yakın şey, iOS kullanıcılarınızı almak için HLS kullanmak ve herkes için flaş kullanmaktır. Benim kişisel favorim HLS kodlamak, sonra herkes için HLS oynamak için flaş kullanın. HLS'yi JW player 6 ile flash olarak oynayabilirsiniz (veya AS3'te yaptığım gibi kendi HLS'nizi FLV'ye yazabilirsiniz)

Yakında bunu yapmanın en yaygın yolu iOS / Mac'te HLS ve MSE üzerinden DASH olacak (her yerde Netflix yakında yapacak). Ancak yine de herkesin tarayıcılarını yükseltmesini bekliyoruz. Ayrıca Firefox için ayrı bir DASH / VP9'a da ihtiyacınız olacak (open264 hakkında biliyorum; berbat. Ana veya yüksek profilde video yapamıyor. Bu yüzden şu anda işe yaramaz).


Ayrıntılı arka plan ve çeşitli seçenekler hakkında pro / eksileri için teşekkürler szatmary. Bu cevabı kabul edilen cevap olarak seçtim, çünkü kavramların ana hatları orijinal soruyu cevaplamak için bulduğum özel düzeltmeden daha önemlidir. Ödül ile iyi şanslar!
deandob

9
Bu, bu soru için çalışan bir çözüm değildir. Aşağıda bu soruna çalışan bir çözüm var.
jwriteclub

2
Firefox artık MSE ve h.264'ü yerel olarak destekliyor. Onaylamak için en son FF tarayıcısıyla www.youtube.com/html5 adresine gidin. FF 37 ile test ettim. Mac'teki Safari 8+ artık MSE'yi de destekliyor.
BigTundra

@BigTundra evet, safari, Mac'te Yosemite lansmanından bu yana MSE'yi destekliyor. Ancak iOS değil. Windows hakkında emin değilim. (Windows'ta safari hala bir şey mi?) Mac'te Firefox 37.0.2 (my) Mac bu bağlantıya göre MSE'yi desteklemiyor gibi görünüyor. Ancak H.264'ü destekliyor. Firefox geçmişte H.264 desteğini ekledi, kaldırdı ve yeniden ekledi.
szatmary

MPEG-4 / H.264 video formatı için güncel tarayıcı destekleri: caniuse.com/#feat=mpeg4
Maxence

75

Herkes özellikle szatmary teşekkürler çünkü bu karmaşık bir soru ve birçok katmanı var, hepsi canlı video akışı yapmadan önce çalışması gerekiyor. Orijinal sorumu ve HTML5 video kullanımını flash ile vs arasındaki açıklığa kavuşturmak için - kullanım durumum HTML5 için güçlü bir tercihe sahip, çünkü genel, istemcide ve gelecekte uygulanması kolay. Flash uzak bir saniye en iyisidir, bu yüzden bu soru için HTML5 ile devam edelim.

Bu alıştırma ile çok şey öğrendim ve canlı akışın VOD'dan (HTML5 video ile iyi çalışır) çok daha zor olduğunu kabul ediyorum. Ancak bunu kullanım durumum için tatmin edici bir şekilde çalıştım ve çözüm, MSE, flash, ayrıntılı tamponlama şemaları gibi daha karmaşık seçenekleri takip ettikten sonra, Düğümdeki çok basit olmak için çalıştı. Sorun, FFMPEG'in parçalanmış MP4'ü bozmasıydı ve FFMPEG parametrelerini ayarlamak zorunda kaldım ve başlangıçta kullandığım http üzerinde standart düğüm akışı boru yeniden yönlendirmesi gerekli olan tek şeydi.

MP4'te, mp4'ü kendi dizinine sahip olan ve mp4 canlı akış seçeneğini uygulanabilir kılan çok daha küçük parçalara ayıran bir 'parçalanma' seçeneği vardır. Ancak akışa geri dönmek mümkün değil (kullanım durumum için Tamam) ve daha sonraki FFMPEG sürümleri parçalanmayı destekliyor.

Not zamanlaması bir sorun olabilir ve benim çözümümle yeniden düzenlemenin bir kombinasyonunun neden olduğu 2 ila 6 saniye arasında bir gecikmem var (etkin bir şekilde FFMPEG canlı akışı almak zorunda, remux daha sonra HTTP üzerinden sunum için düğüme gönderir) . Bununla ilgili çok fazla şey yapılamaz, ancak Chrome'da video, videoyu biraz gergin ama IE11'den (tercih edilen istemcim) daha güncel yapan olabildiğince yakalamaya çalışır.

Kodun bu yayında nasıl çalıştığını açıklamak yerine, yorumlarla GIST'e göz atın (istemci kodu dahil değildir, http sunucu adresi düğümü olan standart bir HTML5 video etiketidir). GIST burada: https://gist.github.com/deandob/9240090

Bu kullanım örneğinin benzer örneklerini bulamadım, bu yüzden yukarıdaki açıklama ve kod başkalarına yardımcı olur, özellikle de bu siteden çok şey öğrendim ve hala kendimi bir acemi olarak kabul ediyorum!

Bu benim özel sorumun yanıtı olmasına rağmen, en kapsamlı olduğu için szatmary'nın cevabını kabul edilen cevap olarak seçtim.


33
Üzgünüm, ama bunu kendi başıma buldum, cevabımın yazılması bunu oldukça açık hale getiriyor. Önceki cevapların hepsi yararlı ve takdir edildi, ancak önemli ölçüde katkıda bulunmadı ve hatta GIST'de çalışma kodunu gönderdim ve başka hiç kimse yoktu. 'İtibar' ile ilgilenmiyorum, yaklaşımımın ve kodumun iyileştirilebileceğini öğrenmekle ilgileniyorum. Ve işaretlediğim cevap sorunumu çözdü, bu yüzden sorunun burada ne olduğunu karıştırıyorum. SO için oldukça yeniyim, bu yüzden farklı bir şekilde etkileşime girmemi söylediğim için mutluyum, bu siteyi yararlı buluyorum ve cevabım başkalarına yardımcı olmalı.
deandob

2
Orijinal sorunu çözse bile soruyu sorduysanız cevabınızı kabul edilen cevap olarak seçmek bu toplulukta doğru bir şey değil gibi görünüyor. Bu sezgisel gibi görünse de, kavramların dokümantasyonu, diğerlerinin öğrenmesine yardımcı olduğu için iyi olduğum gerçek düzeltmeden daha önemlidir. Cevabımın seçimini kaldırdım ve kavramları en iyi ifade eden szatmaryları seçtim.
deandob

6
@Deandob: Başarıyla sağladığınız bu soruna çalışan bir çözüm için bir ödül yayınladım . Kabul edilen cevap, çalışma çözümü bulunmadığını ve bu nedenle açıkça yanlış olduğunu iddia eder.
jwriteclub

2
Teşekkürler. Başkalarının orijinal cevabımı yanlış olarak indirdiğini ve yeni olduğum için burada işlerin böyle çalıştığını varsaydım. Herhangi bir karışıklığa neden olmak istemiyorum ama meta yığını taşması millet ile kontrol edecektir. BTW - benim çözümüm çok iyi çalışıyor ve diğerleri için uygulanabilir olmalı ve yayınlanan gecikmede ilk gecikmeyi azaltabilecek bir varyasyon var (önce node.js'de arabellek daha sonra istemci sonunda akışın sonunu aramaya çalışabilir) .
deandob

4
Bir moderatörden, soruyu kendime cevaplamak ve cevabı doğru yaklaşım olarak seçmek gibi orijinal yaklaşımımın açıklığına sahibim. Daha fazla bilgi için (veya bu konuyu daha fazla tartışmak isterseniz) meta sitedeki konu başlığına bakın. meta.stackexchange.com/questions/224068/…
deandob

14

JSMPEG projesine bir göz atın . Orada harika bir fikir var - JavaScript kullanarak tarayıcıda MPEG kodunu çözmek için. Kodlayıcıdan gelen baytlar (örneğin FFMPEG), örneğin WebSockets veya Flash kullanılarak tarayıcıya aktarılabilir. Topluluk yetişirse, şimdilik en iyi HTML5 canlı video akışı çözümü olacağını düşünüyorum.


10
Bu bir MPEG-1 video kod çözücü. Eski MPEG-1'in ne olduğunu anladığınızdan emin değilim; DVD'lerden daha eskidir. Bu oluyor biraz daha GIF dosyası daha gelişmiş.
Camilo Martin

13

Broadway h264 codec bileşeni (emscripten) etrafında tüm tarayıcılarda (masaüstü, iOS, ...) canlı (gecikmesiz) h264 video oynatabilen bir HTML5 video oynatıcı yazdım.

Video akışı websocket aracılığıyla istemciye gönderilir, kare başına kodu çözülür ve bir canvada görüntülenir (hızlanma için webgl kullanılarak)

Check out https://github.com/131/h264-live-player github.


1
github.com/Streamedian/html5_rtsp_player Bu adamlar websocket üzerinden rtp h264 kullanan benzer bir şey yaptılar
Victor.dMdB

12

RTSP tabanlı bir web kamerasını bir HTML5 istemcisine canlı olarak aktarmanın bir yolu (yeniden kodlamayı içerir, bu nedenle kalite kaybını bekleyin ve bazı CPU gücüne ihtiyaç duyar):

  • Bir buz döküm sunucusu kurun (web sunucunuzun bulunduğu makinede veya kameradan RTSP akışını alan makinede olabilir)
  • Akışı kameradan alan makinede FFMPEG değil gstreamer kullanın. RTSP akışını alabilir ve deşifre edebilir, yeniden kodlayabilir ve icecast sunucusuna aktarabilir. Örnek boru hattı (yalnızca video, ses yok):

    gst-launch-1.0 rtspsrc location=rtsp://192.168.1.234:554 user-id=admin user-pw=123456 ! rtph264depay ! avdec_h264 ! vp8enc threads=2 deadline=10000 ! webmmux streamable=true ! shout2send password=pass ip=<IP_OF_ICECAST_SERVER> port=12000 mount=cam.webm

=> Daha sonra <video> etiketini icecast-stream ( http://127.0.0.1:12000/cam.webm ) URL'siyle kullanabilirsiniz; webm'yi destekleyen her tarayıcıda ve cihazda çalışır


3

Bu çözüme bir göz atın . Bildiğim gibi, Flashphoner saf HTML5 sayfasında Canlı ses + video akışını oynatmaya izin veriyor.

Onlar kullanmak MPEG1 ve G.711 oynatma için codec. Bilgisayar korsanlığı kodu çözülmüş videoyu HTML5 tuval öğesine dönüştürüyor ve kod çözülmüş sesi HTML5 ses içeriği üzerinden oynatıyor.



2

Bu çok yaygın bir yanlış anlamadır. Canlı HTML5 video desteği yoktur (iOS ve Mac Safari'deki HLS hariç). Bir webm kapsayıcısı kullanarak 'hackleyebilirsiniz', ancak bunun evrensel olarak desteklenmesini beklemem. Aradıklarınızı, parçaları birer birer tarayıcıya besleyebileceğiniz Medya Kaynağı Uzantıları'nda bulabilirsiniz. ancak bazı istemci tarafı javascript yazmanız gerekecektir.


Orada solutionsama yok supportcanlı akış için. Bu doğrudan yukarıda görülen yorumuma atıfta bulunuyor. Ve webm, en son kararlı sürüm olan büyük tarayıcılarda desteklenir.
tsturzl

1
Gerçekten H.264 webm kod dönüştürmemeyi tercih ediyorum ve gerekli olmamalı. Ayrıca IE11 ve Safari'yi desteklemem gerektiğinden, MediaSource uzantıları yardımcı olmaz. Ama eğer sunucu tarafında bir dosya akışı simüle ederse (ki çalışır!) O zaman çalışması gerekir, ama ben node.js üzerinde bir dosya arabelleği simüle etmek zorunda kalacak düşünüyorum.
deandob

1
Diğer önerildiği gibi, VLC veya flash eklentisi gibi yerel olan WebRTC kullanmak için bir olasılık ararım. Bu teknolojinin uygulanmasının hala zor olduğunu biliyorum. İyi şanslar.

1
Ben parçalanmış mod (MP4 canlı akış için gerekli böylece istemci canlı asla gelmeyecek moov dizin dosyası beklemiyor böylece gerekli mp4 bozulma göründüğü gibi FFMPEG en son sürümüne güncelleyerek çalışmak var yayın Akışı). Ve node.js kodum FFMPEG akışını doğrudan tarayıcıya yönlendirmek için çalışıyor.
deandob

1
Evet, IE11'de (tercih edilen tarayıcım) iyi çalışıyor. Chrome'da gergin yanıt alıyorum.
deandob

2

Binaryjs'ı deneyin. Onun socket.io gibi ama iyi yaptığı tek şey ses video akışı olmasıdır. Binaryjs google it


1
Binary.JS, Socket.IO gibi bir şey değildir. Ve medya akışına özgü değil.
Brad
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.