Insbesondere durch Amazon AWS CloudFront gibt es nun ein sehr gutes einfaches Content Delivery Network (CDN) um Live und Vod Inhalte des Flash Media Servers performat weltweit zu verteilen.

Ach übrigens … kennen Sie schon unser neues Blog zum Thema Amazon Cloud … als autorisierter Amazon Web Services Solution Provider sind wir voll im Thema!

Highlight ist die Unterstützung von iOS Devices über das HLS Streaming.

Question: Companies often ask me what they need to do to their firewall to allow Peer-Assist to work from our Cloud-based service through their firewall. I usually say they need to open port 1935 for UDP and ports 19350-65535 for UDP. Is this correct?

Answer: They need to allow UDP outbound on any port for P2P to work. When clients open direct connections to neighbors in the Group, these will happen over random UDP ports (whatever port number the kernel doles out when the client opened its socket).

Allowing traffic inbound over port 1935 and the high port range only needs to be done at the FMS end of the network (and you should be OK with only opening port 1935 as long as you allow UDP outbound from all these ports). Here as well, if you have any server-side RTMFP NetConnections/NetStreams/NetGroups participating as a peer in a Group you’ll need to allow UDP outbound on any port.

Here’s some more background on what’s going on with the RTMFP port configs at the server end:
The port range, by default 19350-65535, is defined because each FMSCore process that starts up (and the number of these depends on the number of app instances you have running and how they’re configured to distribute across FMSCore processes) has its own dedicated RTMFP listener/adaptor. Assume you have 3 app instances and each is configured to run in its own process; then you’ll have three FMSCore processes running and each will have its own RTMFP listener running. These listeners acquire the next available port from this range as they come online. So in this case, they’ll likely bind 19350, 19351 and 19352 (assuming those ports are available).

When a new client connects to the FMS, it initially is communicating with the FMSEdge process on UDP port 1935, and depending on the app instance the client is trying to connect to, it will be redirected (this is a low-level RTMFP capability, not a traditional RTMP redirect) to the port bound by the RTMFP listener for the FMSCore process hosting the target app instance. As part of this redirect, the RTMFP listener that the client is being redirected to is also notified that a client is being redirected to it, and it sends a packet out toward the client which should be sufficient to punch a hole in the firewall allowing the redirected clients traffic back in over the new port (say, 19351). Once redirected, all RTMFP traffic from this client to the app instance it connected to will happen at port 19351 at the server. The port number in use at the client end will be random, and this is the port that peers will try to talk to it at and it will talk out to them from which is why you want to allow UDP out from any port at the client end because the port it uses isn’t predictable.

Hier ein Link zu einem sehr guten RTMFP Connecivity Checker: http://cc.rtmfp.net/

Relativ neu ist, dass man mittels einer externen Library LibRTMP Video-Dateien beliebiger Formate auch direkt als LiveStream an den Flash Media Server einspeisen kann.

Um an die LibRTMP Datei zu gelangen, muss man zunächst das RTMPDump Projekt herunterladen. http://rtmpdump.mplayerhq.hu/download/ Am besten dort die neueste Version für z.B. Windows (rtmpdump-2.3-windows.zip) nehmen. Aus dem ZIP die Datei librtmp.dll herauskopieren und in das FFmpeg Bin Verzeichnis kopieren.

Record a live stream from a RTMP server

These instructions assume you have a Adobe FMS server running on the machine “localhost”, and have an application named “live”. The live application is installed by default on FMS.

1. First, connect your current encoding tool to rtmp://localhost/live.
2. Then, publish a stream named “testStream” with your favorite parameters.
3. Finally execute the following command to record a FLV file to disk of that stream:

 ffmpeg -i rtmp://localhost/live/testStream -acodec copy -vcodec copy -y test.flv

Publish a H264 MP4 file as a live stream to a RTMP server

These instructions assume you have a Adobe FMS server running on the machine “localhost”, and have an application named “live”. The live application is installed by default on FMS.

The file we are going to publish is named “testfile.mp4″

1. First, connect your current video playback tool to rtmp://localhost/live.
2. Then, start playing a stream named “testStream” with your favorite parameters (it will be smoother if you buffer 2-3 seconds).
3. Finally, execute this FFmpeg command to ‘stream’ the file to the RTMP server:

 ffmpeg -i testfile.mp4 -re -acodec copy -vcodec copy -f flv rtmp://localhost/live/testStream

Mehr Beispiele findet man hier:  http://wiki.xuggle.com/Live_Encoding_Tutorial

Audio AAC Encoding ist wichtig, wenn man Live Publishing auch für IOS Geräte anbieten möchte (kommt ja mit Flash Media Server 4.5), da IOS dort zwingend den AAC Audio Codec benötigt.

HLS für IOS Devices wird mit dem kommenden Flash Media Server 4.5 erstmals unterstützt werden. Siehe diese Ankündigung von Adobe.

Der Vorteil von HTTP Streaming (HDS oder HLS) liegt darin, dass insbesondere die CDNs ihre HTTP Caching Infrastruktur nutzen können und dass alles über Port 80 und HTTP läuft, also Firewalls prinzipiell kein Problem mehr darstellen. Einen sehr guten Vortrag über die Vor- und Nachteile von HTTP Streaming findet man in diesem Vortrag: HD Streaming with HTTP Dynamic Streaming.

Ein sehr grosser Nachteil von HTTP Streaming (HDS oder HLS) insbesondere bei Live Streaming ist die doch sehr grosse Latenzzeit: For Apple HLS (HTTP Live Streaming), they require having at least 3 ts files before playback starts, and their recommended ts file duration is 10 secs. That means you can expect about a 30 sec latency in HLS. That’s per Apple specs and recommendations and not due to implementation. For Adobe HDS (HTTP Dynamic Streaming), you can expect a latency in the range of 1-2 F4F fragments; I believe we recommend a fragment duration of 4 seconds. So you can expect latency in the range of about 4-8 seconds. For the lowest latency possible, RTMP beats them all.

Wollte man Live Videos mit dem neuen H.264 Codec encodieren, musste man bisher immer auf den Flash Media Live Encoder ausweichen, der zwar kostenlos ist, aber natürlich nicht so nahtlos in einer z.B. Video Chat Anwendung zu integrieren ist.

Mit dem Flash Player 11 ändert sich nun alles … denn nun können Live Videos mit dem H.264 Codec encodiert werden.

Siehe dazu auch: A dream comes true: H.264 encoding into Flash Player 11.

Eine erste Flash Player 11 basierender LiveEncoder existiert auch bereits: H.264 WebEncoder basierend auf FP11

Big new features in this update include

• Full Support for Microsoft Windows 7
• Additional Capture card certification: Blackmagic Decklink + AJA Kona (formally Xena)
• Support for new RTMP DVR workflows (supporting DVRCast 1.2 for Flash Media Server)
• For DVR support with your Flash Media Server, you can download DVRCast 1.2 here from our FMS tools page.