flash/flessione:download progressivo vs.rtmp

Question

Sto cercando di capire e individuare realmente quando utilizzare il download progressivo rispetto al download progressivo.rtmp in formato flessibile/flash.Sembra che il punto principale sia che rtmp non viene servito con http, mentre lo è il download progressivo.Poiché non è rtmp, la risorsa è protetta poiché non è possibile connettersi al server rtmp dall'esterno del swf.

Anche se l'utente può vedere il codice oggetto e capire la posizione

<object data="http://media.example.com/jw-player/player.swf" >
    <param value="streamer=rtmp://sub.example.com/video
           &amp;file=1330/title/folder2/theflvresource.flv
           &amp;id=FlvPlayer" name="flashvars">
</object>

non sarebbero in grado di connettersi a rtmp.Quindi rtmp sembra essere più utile quando vuoi proteggere una risorsa?È tutto qui?

Answer 1

Sono d'accordo con xtat, ma voglio aggiungere molto altro.

I pro e i contro di RTMP (o qualsiasi protocollo di streaming basato su UDP) rispetto a"download progressivo" (che in realtà è solo un sottoinsieme dello streaming basato su HTTP) secondo la mia non così umile opinione:

• Streaming basato su UDP
  • Professionisti
    • Attualmente è molto più difficile rubare flussi
    • Attualmente supporta live, cosa che non è basata su HTTP
    • Funzionalità multicast, che può essere auspicabile nelle Intranet
  • Contro
    • Utilizzo delle risorse notevolmente più elevato rispetto all'approccio basato su http
    • Necessità di server specializzati (FMS, Red5, Wowza, qualunque cosa)
    • Buffer più evidente
    • Problemi con il firewall, soprattutto con i clienti aziendali
• Streaming basato su HTTP
  • Professionisti
    • Morale semplice
    • Potere cercare nei media.FLV e MP4 (con qualche sforzo)
  • Contro
    • È banale rubare i flussi.Per esempio.:Downloader reale
    • I live streaming al momento non sono possibili, ma aspetta un anno.Apple sta rendendo tutto questo una realtà.
    • nessun multicasting

L'intero approccio basato su HTTP è pieno di e/ma/se situazioni, molti malintesi su cosa è possibile e cosa non è possibile e mancanza di definizioni comuni.

Ci sono due caratteristiche fondamentali che le persone tengono in considerazione quando parlano di streaming basato su HTTP: cercando E larghezza di banda regolamentata.Da ciò otteniamo tutti questi termini come "pseudo-streaming", "download progressivo", ecc.

Queste sono le definizioni che utilizzo per descrivere i server di streaming basati su HTTP:

• bit-rate regolamentato:Il file multimediale flat viene analizzato dal server e invia i contenuti multimediali alla velocità necessaria al lettore per riprodurli senza buffering.
• cercando:la capacità di un server web di cercare nei media e creare effettivamente al volo un nuovo "file" per l'utilizzo da parte del client.Simile a una richiesta di intervallo di byte http, tranne per il fatto che le intestazioni e i metadati multimediali vengono aggiunti/modificati.
• download progressivo:Basta inviare il file il più velocemente possibile.Fondamentalmente, inserisci il file multimediale sul server Web che invia al client in modo "stupido", come un file .iso o .zip di grandi dimensioni.
• pseudo-streaming:la capacità di un server web di inviare file multimediali al client con un bitrate regolamentato e di cercare nei file.

Answer 2

Personalmente, la ragione principale per scegliere RTMP su download progressivo è permette l'utente per passare al centro di un video senza dover scaricare l'intero file.

Answer 3

In questi giorni a meno che non avete bisogno di registrare, non c'è davvero nessun punto per utilizzando RTMP. HTTP è più semplice e ovviamente molto più ampiamente supportato, più facile da eseguire il debug e in effetti lo fa permette per la ricerca, anche su CDN. Questo è quello che ho istituito presso Viddler.