Real time transcoding of multiple RTMP-Streams

Update

Looks like Apple made an IETF draft proposal, and some people are already working on segmenters:

HTTP Live Streaming - draft-pantos-http-live-streaming-01
http://tools.ietf.org/id/draft-pantos-http-live-streaming-01.txt

iPhone HTTP Streaming with FFMpeg and an Open Source Segmenter
http://www.ioncannon.net/programming/452/iphone-http-streaming-with-ffmpeg-and-an-open-source-segmenter/

Ok, looks like the HTTP server acts simply as a dumb HTTP server. Poking around the example website provided by Akamai gives me enough info to get started with static content streaming.

http://iphone.akamai.com/

The whitepaper ( http://www.akamai.com/dl/akamai/iphone_wp.pdf ) provides information about the transport stream encoding, so the .ts streams are straightforward.

The encoder (or a separate segmenter process) will produce H.264/AAC content in a sequence of small content segments, in MPEG-2 TS format (.ts). There is also an M3U8 index file that references the segments; in the case of live content the M3U8 is continuously updated to reflect the latest content.

H.264 Encoding should be single-pass Baseline Profile, frame re-ordering disabled. Key frames are suggested every 5 seconds, ideally an even divisor of the chosen segment length.

The website provides an M3U8 file, which is simply an M3U playlist, but in the UTF-8 character encoding format.

That file then links to an M3U8 file for each bitrate. I assume they must all have cuts at the same positions (every 2 or 10 seconds, for instance) so that switching can be seamless. It appears to be completely client driven - the client decides how to measure bandwidth and which version it's going to get.

The contents of the main file are:

#EXTM3U
#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=860000
hi/prog_index.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=512000
med/prog_index.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=160000
lo/prog_index.m3u8

Then each of the other files are:

hi/prog_index.m3u8

#EXTM3U
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:10,    
fileSequence0.ts
#EXTINF:10,    
fileSequence1.ts
#EXTINF:10,    
fileSequence2.ts
#EXTINF:10,    
fileSequence3.ts
#EXTINF:1,    
fileSequence4.ts
#EXT-X-ENDLIST

med/prog_index.m3u8

#EXTM3U
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:10,    
fileSequence0.ts
#EXTINF:10,    
fileSequence1.ts
#EXTINF:10,    
fileSequence2.ts
#EXTINF:10,    
fileSequence3.ts
#EXTINF:1,    
fileSequence4.ts
#EXT-X-ENDLIST

lo/prog_index.m3u8

#EXTM3U
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:10,    
fileSequence0.ts
#EXTINF:10,    
fileSequence1.ts
#EXTINF:10,    
fileSequence2.ts
#EXTINF:10,    
fileSequence3.ts
#EXTINF:1,    
fileSequence4.ts
#EXT-X-ENDLIST

This works with the HTML 5 video tag:

<video width=”640” height=”480” >
   <source src=”content1/content1.m3u8” />
</video>

Still a lot of unanswered questions, but this is probably enough to get started.

-Adam

It's probably packet loss. Are your switches optimizing multicast or just flooding the traffic out all ports?

You can transcode the stream - I use something like

#transcode{vcodec=h264,venc=x264{keyint=15},acodec=mpga,vb=2500,ab=128}:std{mux=ts,access=udp,dst=x.x.x.x}

keyint specifies how often to put a keyframe in the stream - the lower it is, the better the stream will recover from dropped packets in my experience.