Streaming multimediale da pagine HTML interne, ad esempio

Quindi sono un ingegnere del software che cerca di capire alcuni dettagli grintosi su come funzionano i media di streaming. Ho trascorso la maggior parte della giornata cercando di capire i vari codec, formati contenitore e protocolli di streaming pertinenti alla mia applicazione. Finora, ecco la mia comprensione di come funziona, che potrebbe benissimo essere fuorviata:

• Lo streaming multimediale si riduce davvero al formato contenitore e al protocollo streaming :
  • Tutti i dati audio sono codificati (tramite codec audio) in un bitstream audio
  • Tutti i dati video sono codificati (di nuovo, tramite codec) in un flusso di video
  • I due flussi vengono uniti ( multiplexati? ) Insieme in un contenitore che alla fine diventa un file (come MP4, ecc.)
  • Un server multimediale speciale serve quindi questo contenitore (file MP4 o qualche altro formato) a un client (forse un lettore video HTML5 in esecuzione all'interno del browser di qualcuno) tramite un protocollo di streaming standard, come RTSP
    • Nel caso di un client browser, suppongo che il browser stesso abbia un client RTSP che poi presenta in qualche modo agli utenti HTML5 Video Player
• Ho potuto ospitare un file MP4 da un web server, come nginx o httpd, ma dal momento che tali server non sono server RTSP, sarebbe solo in grado di richieste di trattare per la MP4 come le richieste di download , e, quindi, sarebbero in grado di trasmettere la file multimediali
  • Allo stesso modo, se dovessi usare curlper recuperare i file da un server nginx, dal momento che né curlné nginx parlano RTSP, verrebbero trattati come un download di file
• Ma, quando ospito un file MP4 da un server multimediale in streaming (VideoLAN, Red5, Wowza, ecc.) E utilizzo un client RTSP (o qualsiasi client multimediale in streaming supportato) per richiedere un flusso da quel server, che quindi e solo quindi si verifica qualsiasi streaming effettivo
  • Quindi, anche se i "video" di YouTube o Vimeo sono ospitati su pagine HTML servite su HTTP (S) da server HTTP, presumo che i lettori di video incorporati su quelle pagine (che sono dove i video vengono effettivamente riprodotti) stanno effettivamente iniziando un secondo , successiva connessione a un server di streaming e lo streaming avviene su RTSP o altri protocolli non HTTP

Quindi questa è la mia comprensione, e immagino che prima di tutto chiedo che se qualcosa che ho detto sopra non è corretto, per favore , iniziami correggendomi! Supponendo che io sia più o meno corretto:

In che modo i lettori multimediali di streaming, eseguiti all'interno di pagine HTML e serviti da server HTML, stabiliscono connessioni di streaming (RTSP, ecc.) Con server multimediali di streaming (che soddisfano le richieste RTSP)?

In che modo i lettori multimediali di streaming, eseguiti all'interno di pagine HTML e serviti da server HTML, stabiliscono connessioni di streaming (RTSP, ecc.) Con server multimediali di streaming (che soddisfano le richieste RTSP)?

Applicazioni comuni

RTSP attualmente sembra essere usato più con le applicazioni / interfacce dei dispositivi che trasmettono direttamente streaming (ad es. Telecamera IP) o re-stream (come un motore) di quanto non lo sia per lo streaming di file multimediali salvati da una posizione fisica tramite un'interfaccia di riproduzione Web HTTP con un lettore incorporato.

Sembra che RTSP sia un protocollo con stato e usi UDP più di TCP durante lo streaming, e sia usato più come un dispositivo server (come una telecamera IP) che è connesso a una rete TCP / IP e trasmette flussi via UDP, ecc. Quindi ti connetti a questi feed (il server) come client sulla stessa rete e puoi inviare richieste RTSP da utilizzare di conseguenza.

^{Direttive del protocollo}

^{Sebbene in qualche modo simile a HTTP, RTSP definisce sequenze di controllo utili nel controllo della riproduzione multimediale. Mentre HTTP è senza stato , RTSP ha stato; un identificatore viene utilizzato quando necessario per tenere traccia delle sessioni simultanee. Come HTTP, RTSP utilizza TCP per mantenere una connessione end-to-end e, mentre la maggior parte dei messaggi di controllo RTSP vengono inviati dal client al server, alcuni comandi viaggiano nell'altra direzione (cioè dal server al client).}

^{Qui sono presentate le richieste RTSP di base. Sono inoltre disponibili alcune richieste HTTP tipiche, come la richiesta OPTIONS. Il numero di porta del livello di trasporto predefinito è 554 [3] sia per TCP che per UDP, quest'ultimo usato raramente per le richieste di controllo.}

^_fonte

^apolide

^{Un protocollo senza stato non richiede al server di conservare le informazioni sulla sessione o lo stato di ciascun partner di comunicazione per la durata di più richieste. Al contrario, un protocollo che richiede il mantenimento dello stato interno sul server è noto come protocollo con stato .}

^{Uno svantaggio dell'apolidia è che potrebbe essere necessario includere informazioni aggiuntive in ogni richiesta e queste informazioni aggiuntive dovranno essere interpretate dal server.}

^_fonte

Flusso logico

Il modo in cui comprendo il flusso di streaming media in questo modulo è:

• il server in cui risiede il contenuto multimediale incapsulerà, comprimerà, codificherà, ecc. il contenuto di dati video / audio nei formati e segmenti appropriati per lo streaming
• il server Web che ascolta le connessioni per accedere ai media di streaming fornirà tutte le risorse necessarie per trasmettere i media
• il client richiede e scarica risorse e file applicabili, quindi li assembla in modo continuo per la riproduzione tramite il puntatore URL come configurato e altri parametri. Il software di riproduzione a livello client assembla i pacchetti trasmessi in sequenza per consentire la corretta riproduzione del contenuto.

Consulta la sezione Tecnologie di streaming di seguito per un confronto generale tra HTTP e RTSP.

inoltre

Nei seguenti 10 motivi per cui non dovresti mai ospitare i tuoi video personali , ho citato le parti che arrivano al punto per aiutarti a rispondere alla tua domanda in "generale" senza essere troppo specifico.

Sostanzialmente afferma che il sito Web che ha i controlli del lettore multimediale incorporato dovrà:

• ⁽¹⁾ rilevare le impostazioni del browser Web client su "connessione e richiesta" dal client e
• ⁽²⁾ questo imposterà il codec e tutte le altre impostazioni di rilevamento lato client sui valori dei parametri applicabili, quindi
• ⁽³⁾ eseguirà lo streaming del video direttamente dal server di streaming su cui si ospitano i file video e audio in base a un ulteriore codice nelle configurazioni del lettore multimediale incorporato che punta all'URL del file multimediale sul server ospitato.

^{Tecnologie di streaming}

^{Il browser client deve ricevere i dati dal server e trasmetterli all'applicazione di streaming per l'elaborazione. L'applicazione di streaming converte i dati in immagini e suoni. Un fattore importante per il successo di questo processo è la capacità del client di ricevere dati più velocemente che l'applicazione può visualizzare le informazioni. I dati in eccesso vengono archiviati in un buffer, un'area di memoria riservata alla memorizzazione dei dati all'interno dell'applicazione. Se i dati vengono ritardati nel trasferimento tra i due sistemi, il buffer si svuota e la presentazione del materiale non sarà fluida.}

^{Protocollo HTTP}

^{L'HTTP è il modo predominante in cui i documenti sono collegati su Internet. Il client stabilisce una connessione al server contenente il file da trasmettere in streaming, il file viene recuperato e la connessione chiusa. Il server HTTP comunica al browser il tipo di file da trasferire.}

^{Vantaggi dell'utilizzo di HTTP}

^{Quando si esegue lo streaming di un file tramite HTTP, non è necessario un server di streaming speciale. Finché il browser comprende i tipi MIME, può ricevere un file di streaming da un server HTTP. Uno dei vantaggi distintivi dei file di streaming tramite HTTP è che può passare attraverso i firewall e utilizzare server proxy.}

^{Alcuni svantaggi}

^{Lo streaming HTTP utilizza TCP / IP (Transmission Control Protocol e Internet Protocol) per garantire la consegna affidabile dei file. Questo processo verifica la presenza di pacchetti mancanti e richiede la loro ritrasmissione. Questo diventa problematico nello scenario di streaming quando si desidera ignorare i dati se vengono persi nella consegna, quindi i file dinamici continuano a essere riprodotti. HTTP non è in grado di rilevare la velocità del modem, pertanto gli amministratori del server devono produrre intenzionalmente file a velocità di compressione diverse per gli utenti del server con diversi tipi di connessioni. Lo streaming di file da server HTTP non è raccomandato per situazioni molto richieste.}

^{Protocollo RTSP}

^{RTSP è il protocollo standard utilizzato dalla maggior parte dei fornitori di server di streaming. I server RTSP utilizzano UDP (User Datagram Protocol) per trasferire file multimediali. UDP non controlla continuamente che i file siano arrivati ​​a destinazione. Questo è un vantaggio per le applicazioni di streaming perché consente di interrompere i trasferimenti di file purché il ritardo non sia troppo lungo. Il risultato di questo metodo è che a volte c'è una perdita di dati, ma i file continuano a essere riprodotti se il ritardo è ridotto.}

^fonte

^{10 motivi per cui non dovresti mai ospitare i tuoi video}

^{Stiamo parlando di video incorporati e self-hosted}

^{Innanzitutto, carichi il tuo file video su un servizio di hosting video di terze parti come YouTube, Vimeo o Wistia.}

^{Quindi, copi un pezzetto di codice che ti viene fornito e incollalo nel tuo post o pagina sul tuo sito WordPress. Il video apparirà sul tuo sito, nella posizione in cui hai incollato il codice di incorporamento, ma il video stesso viene trasmesso in streaming dai server dell'host video, al contrario del tuo server web, dove è ospitato il tuo sito WordPress.}

^{4. Nessun formato di file singolo standard per i video Web}

^{L'attuale specifica della bozza HTML5 non specifica quali formati video devono supportare i browser. Di conseguenza, i principali browser Web sono divergenti, ognuno dei quali supporta un formato diverso. Internet Explorer e Safari riprodurranno video H.264 (MP4), ma non WebM o Ogg. Firefox riprodurrà video Ogg o WebM, ma non H.264. Per fortuna, Chrome riprodurrà tutti i principali formati video, ma se vuoi assicurarti che il tuo video venga riprodotto su tutti i principali browser Web, dovrai convertirlo in più formati: .mp4, .ogv e .webm}

^{5. Spero ti piaccia convertire i video. Un sacco.}

^{La maggior parte del tuo pubblico probabilmente guarderà i tuoi video dal proprio desktop o laptop con il vantaggio di una connessione Internet ad alta velocità. Per quelle persone, ti consigliamo di consegnare un file di grandi dimensioni in qualità HD in modo che possano guardarlo a schermo intero se lo desiderano. In genere, ciò significa un file 1080p o 720p con un bitrate di streaming elevato (5000 - 8000 kbps).}

^{Ma vorrai anche codificare una versione più piccola, a bassa risoluzione per la consegna a dispositivi mobili come telefoni e tablet, nonché la consegna agli spettatori con connessioni Internet più lente.}

^{6. Lettori video}

^{Un video player è un piccolo software web che installi sul tuo sito che rileverà automaticamente quale dispositivo richiede il tuo video, insieme alla sua velocità di connessione, e quindi fornirà la versione appropriata a quella persona.}

^{7. Codice ingombrante [o codici brevi]}

^{Sia che utilizzi un plug-in di terze parti o le funzionalità video integrate di WordPress, dovrai creare un po 'di codice per dire al lettore video quali formati hai creato e la loro posizione sul server. Sembra qualcosa del genere ...}

<video poster="movie.jpg" controls>
<source src="movie.webm" type='video/webm; codecs="vp8.0, vorbis"'/>
<source src="movie.ogg" type='video/ogg; codecs="theora, vorbis"'/>
<source src="movie.mp4" type='video/mp4; codecs="avc1.4D401E, mp4a.40.2"'/>
<p>This is fallback content</p>
</video>

Qual è la soluzione migliore per aggiungere video al tuo sito?

Usa semplicemente un servizio di hosting video di terze parti, quindi incorpora il tuo video nel post o nella pagina di WordPress.

Fase 1: carica il tuo video su uno dei servizi di hosting video conosciuti e consolidati come Vimeo PRO.

Passaggio 2: una volta che il video è stato caricato e pronto per la visualizzazione, copia l'URL sul video. Torna al tuo sito WordPress e incolla l'URL nel tuo post o nella pagina in cui desideri che appaia il video.

---

^{Quando le persone visualizzano la tua pagina, il video verrà visualizzato nella posizione in cui hai incollato l'URL. Ma il file video stesso verrà trasmesso in streaming dai server dell'host video, al contrario del tuo server, dove è ospitato il tuo sito WordPress.}

_{Il lettore video incorporato rileverà automaticamente la velocità del dispositivo, del browser e della connessione Internet dell'utente, quindi fornirà loro la versione appropriata del file video. Nulla da installare sul tuo sito. Nessun plug-in da aggiornare. Nessun codice complicato.}

_fonte

Di seguito tratterò principalmente la tua domanda su cosa succede quando un video viene visualizzato nel browser. L'argomento è vasto, quindi toccherò solo gli argomenti pertinenti.

HTML5 ha introdotto il <VIDEO>tag che ha risolto il problema dell'integrazione del video visualizzato nel browser durante l'utilizzo di JavaScript e CSS. Il <OBJECT>tag precedente richiedeva software esterno ed era mal integrato con la pagina. Il nuovo tag in effetti richiedeva che anche il browser diventasse un lettore video, sebbene non fossero stati imposti standard. Il risultato è stata la frammentazione totale degli standard, a cui l'unica soluzione è che il server video renderà disponibili diversi formati video e che tutte queste fonti alternative siano specificate nel <VIDEO>tag, da cui il browser sceglierà quello che supporta.

Un esempio di un tag con più origini:

<video width=320 height=240 controls poster=image.jpg>
   <source src="movie.mpd">
   <source src="movie.webm">
   Your browser does not support the video tag.
</video>

Il <VIDEO>tag stesso è indipendente dal protocollo, quindi può utilizzare qualsiasi protocollo supportato dal browser incluso RTSP. Il supporto per il protocollo MPEG-DASH (Dynamic Adaptive Streaming su HTTP) è diventato ultimamente molto completo, quindi verrà riprodotto sulla maggior parte dei dispositivi e dei browser nativi o utilizzando HTML5, il che significa che non sono richiesti plug-in aggiuntivi. Vedi questo grafico sulla compatibilità di dispositivi e browser . Vedi anche questo articolo di Mozilla per preparare il tuo server per servire MPEG-DASH. DASH funziona tramite HTTP, quindi funzionerà fintanto che il tuo server HTTP supporta le richieste di intervallo di byte ed è impostato per servire i file .mpd mimetype="application/dash+xml".

La normale interazione tra client e server è simile alla seguente. Per HTML5 VIDEO, il browser è anche il lettore, sebbene possa aprire una nuova connessione per la riproduzione.

La connessione iniziale fornisce i metadati utilizzati dal client per visualizzare il video. Se il protocollo RTSP è stato utilizzato per ottenere quei metadati, in seguito viene creata una connessione RTP per il trasferimento dei dati video + audio. Il protocollo RTCP viene utilizzato per trasferire comandi aggiuntivi al server.

RTP, RTCP e RTSP funzionano tutti su porte diverse. Di solito quando RTP è sulla porta N, RTCP è sulla porta N + 1. Una sessione RTP può contenere più flussi da combinare alla fine del destinatario; ad esempio, audio e video potrebbero essere su canali separati.

Affinché nessuno venga bloccato dai tuoi contenuti, dovresti rendere disponibili sia codec gratuiti, webM o Theora e video H.264, sia audio Vorbis e MP3. (Facile a dirsi, difficile da fare.)

Questo è ciò che accade in dettaglio per RTSP:

1. Il client stabilisce una connessione TCP ai server, in genere sulla porta TCP 554, la nota porta per RTSP.

2. Il client inizierà quindi a inviare una serie di comandi di intestazione RTSP che hanno un formato simile a HTTP, ognuno dei quali è riconosciuto dal server. All'interno di questi comandi RTSP, il client descriverà al server i dettagli dei requisiti della sessione, come la versione di RTSP che supporta, il trasporto da utilizzare per il flusso di dati e qualsiasi informazione sulla porta UDP o TCP associata. Queste informazioni vengono passate utilizzando le intestazioni DESCRIBE e SETUP e vengono aumentate sulla risposta del server con un ID di sessione che il client e tutti i dispositivi proxy transitori possono utilizzare per identificare il flusso in ulteriori scambi.

3. Una volta completata la negoziazione dei parametri di trasporto, il client emetterà un comando PLAY per indicare al server di iniziare la consegna del flusso di dati RTP.

4. Una volta che il client decide di chiudere il flusso, viene emesso un comando TEARDOWN insieme all'ID sessione che indica al server di interrompere la consegna RTP associata a tale ID.

Ulteriori letture:

• Nozioni di base sui protocolli di streaming
• Comprensione dei protocolli a livello di applicazione - Real Time Streaming Protocol (RTSP)
• Introduzione al video HTML5 (Opera)
• Audio e video HTML5: cosa devi sapere
• Analisi RTSP Wireshark

Ecco una risposta rapida e sporca

C'è una differenza tra la riproduzione di video sul Web e lo streaming in tempo reale.

La riproduzione viene eseguita per mezzo di un lettore incluso nella pagina Web (potrebbe utilizzare Flash, JS o un oggetto video HTML5). Il client (browser) scarica questo lettore e lo esegue. Il lettore, a sua volta, recupera il video da un semplice URL di download. Infatti, anche con Youtube, ci sono programmi che ti consentono di accedere direttamente ai file video ospitati e scaricarli come faresti con qualsiasi file. Poiché il sistema utilizza un vecchio link per il download regolare, non sono necessari protocolli di streaming complessi come RTSP

Lo streaming in tempo reale (diciamo, da una webcam) è ... beh, più complicato. Flash ha questa funzionalità integrata, ma non dovrebbe più essere utilizzata. Il video HTML5 non supporta lo streaming in tempo reale, ma le persone sono state in grado di "ingannarlo" facendo in modo che il server di file hosting cambi costantemente il file video che offre.