Flash / Flex: téléchargement progressif par rapport à rtmp

Question

Je suis en train de comprendre et d'identifier vraiment quand utiliser le téléchargement progressif par rapport à rtmp flex / flash. Il semble que le point principal est que rtmp n'est pas servi par http, alors que le téléchargement progressif est. Comme il est RTMP pas, la ressource est protégée car il n'y a aucun moyen de se connecter au serveur RTMP de l'extérieur du swf.

Même si l'utilisateur peut voir que le code objet et peut comprendre l'emplacement

<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>

ils ne seraient pas en mesure de se connecter à RTMP. Alors rtmp semble être plus utile lorsque vous souhaitez protéger une ressource? Est-ce tout ce qu'il ya à cela?

Answer 1

Je suis d'accord avec xtat , mais que vous voulez ajouter beaucoup plus.

Les avantages et les inconvénients de RTMP (ou tout autre protocole de streaming basé sur UDP) par rapport aux « téléchargement progressif » (ce qui est vraiment juste un sous-ensemble de flux HTTP) à mon avis pas si humble:

• streaming basé UDP-
  • Plus
    • Actuellement beaucoup plus difficile à chaparder flux
    • prend actuellement en charge en direct, qui HTTP-ne pas
    • Multi moulé capable, qui peut être souhaitable sur les intranets
  • Moins
    • beaucoup plus élevé d'utilisation des ressources, par rapport à l'approche basée sur http
    • Besoin de serveurs spécialisés (FMS, Red5, Wowza, peu importe)
    • mise en mémoire tampon plus notable
    • problèmes de pare-feu, en particulier avec les clients d'entreprise
• HTTP basé en streaming
  • Plus
    • mort simple
    • peut rechercher dans les médias. FLV et MP4 (avec un peu d'effort)
  • Moins
    • Trivial chaparder cours d'eau. .: réel Downloader par exemple
    • Les flux en direct ne sont pas actuellement possible, mais lui donner un an. Apple fait une réalité.
    • pas de multi-casting

L'approche basée sur HTTP entier est rempli de et / mais / si situations, beaucoup de malentendus au sujet de ce qui est et n'est pas possible, et le manque de définitions communes.

Il y a deux personnes caractéristiques de base sont à la recherche à discuter lors de flux HTTP: Seeking et bande passante régulée . De là, nous obtenons tous ces termes comme 'pseudo-streaming', 'téléchargement progressif', etc.

Ce sont les définitions que j'utilise pour décrire les serveurs de flux HTTP:

• réglementé débit binaire . Le fichier multimédia plat est analysé par le serveur, et envoyer un média aussi vite que le joueur doit jouer les médias sans mise en mémoire tampon
• recherche : la capacité d'un serveur Web pour rechercher dans les médias et de créer efficacement un nouveau « dossier » à la volée pour une utilisation par le client. Semblable à une demande de plage d'octets http, sauf que les en-têtes et les méta-données de médias sont ajoutés / modifiés.
• téléchargement progressif : Il suffit d'envoyer le fichier, aussi vite que possible. En gros, mettre fichier multimédia sur le serveur Web qui envoie au client d'une manière « stupide », comme comme un gros fichier .iso ou .zip.
• pseudo continu : la capacité d'un serveur Web pour envoyer des fichiers multimédias au client avec un débit binaire réglementé et de rechercher dans les fichiers.

Answer 2

Personnellement, la principale raison de choisir RTMP sur le téléchargement progressif est-il permet à votre utilisateur de passer au milieu d'une vidéo sans avoir à télécharger le fichier entier.

Answer 3

Ces jours-ci, sauf si vous avez besoin d'enregistrer, il n'y a pas vraiment tout point à l'aide RTMP. HTTP est plus simple et évidemment beaucoup plus largement pris en charge, plus facile à déboguer et en effet, il ne permet de chercher, même sur NAA. Voilà ce que j'ai mis en place à Viddler.