HTTP Streaming - Why not H.264

[iwod]

Is there any reason why we can't use H.264 for HTTP streaming?

http://arstechnica.com/web/news/2009/07/apple-proposes-http-streaming-feature-as-a-protocol-standard.ars

[Dark Shikari]

Who said we can't? Plenty of sites and applications already do.

[CruNcher]

It's just Apples approach to get away from proprietary stuff like Smoothstreaming creating their own Industry Standard :) so making their Quicktime X Client (inside Safari for example) Silverlight and Flash Client feature aware :P
Preparing their Quicktime X Ecosystem for Chunked (Bandwith adapting) Encoding/Decoding capabilities. So basically just their answer to Microsofts SmoothHD ;)
If Microsoft has their own Solution they of course as competitor need also their own one normal business ;) (only difference they want to standardize Chunked (Encrypted) Encoding/Streaming/Client fileformat with Encryption key/Decoding)

The Summary says Everything:

"Summary

A multimedia presentation is specified by a URI [RFC3986] to a
Playlist file, which is an ordered list of additional URIs. Each URI
in the Playlist file refers to a media file which is a segment of a
single contiguous stream.

To play the stream, the client first obtains the Playlist file and
then obtains and plays each media file in the Playlist. It reloads
the Playlist file as described in this document to discover
additional segments."

It will be funny to see the big Patent Wars starting "Who invented Chunked Encoding/Streaming/Decoding" :P

I would say if that should ever be questioned then even Microsoft would lose ;)

Though the idea of Chunked Encoding and Streaming is so old it seems to me like a trivial patent without any value @ all and now everyone is adapting to it :P

[smok3]

the idea is hopefully about the fact that the 'smart' client and simple web server can figure things out alone (without the additional special software on the server side and without the usage of server-side languages)? p.s. it certainly works like that in silverlight.

[CruNcher]

yep that's the idea just from Apple this time ;)
the major difference is that they want to use Mpeg-2 .ts (transport stream) or .mpg (program stream) as container chunks for the H.264 Video streams if i read correctly.
It uses it's own client playlist format to manage all the stuff when doing the chunked encoding so this format .m3u8 and it's definitions the server has to support (create the chunks and playlist) and the client needs to interpret them correct the same thing as is done with Silverlight and IIS :P

It shows another time how the industry sucks ass instead that Microsoft and Apple sit together with Adobe @ the table create 1 standard everyone of them creates their own shit that even uses the same basics just name it different and making the lives of their customers a painful one as those want to target every human on earth and be fully independent of such kid games needing their own Apple Server now and another from Microsoft :( that's why HTML5 video was a big big chance to once and for all end this :(

On the other side Apple has the bigger chance that their Chunked Streaming system becomes the new standard as they have first provided it as a draft :) so now Microsoft and everyone else has to just adopt it into their products and we all be happy ;)

The next step is clear Open Video Alliance announces their Open Chunked Streaming specs for Theora

[iwod]

Any Chance of HTTP streaming going into HTML5 standard?
Anyway, i skim read the article thinking it had to be MPEG 2 Codec. That is why i thought why uses and old and inefficient codec for streaming.

Any lot of people in Ars post concern for this method, Ben said something about having Trillion of files stored for Streaming etc...

I really hope apple would show their implementation soon.

[Ritsuka]

No, Apple is using H.264 and AAC, not MPEG2, and from what I know it's already working well on the new iPhone OS, and some guy already created a server using ffmpeg and others open source softwares: http://www.ioncannon.net/programming/452/iphone-http-streaming-with-ffmpeg-and-an-open-source-segmenter/

[smok3]

now, what i ask myself is why is there mp4? is it really completely useless container for streaming purposes?

[CruNcher]

isn't that clear smok3 :) it's compatible to all the used Hardware for many stream clients especially the .ts muxing and if you want to save additional bandwidth you also can use the .mpg way which is also common hardware implemented :)

i guess Safari should support this .m3u8 streaming already as that is the client in the iphone 3 os so it should work on Desktops alike :) and can be compared to Silverlight, still the question remains how it will find it's way into IE,Opera,Firefox,Chrome seems the only way would be currently over Silverlight and Flash Player client adaption and somehow i fear that's not gonna happen so soon.

and H.264 inside .mpg works nice and is fast @ seeking also, the support open source wise though is still bad (professionally it's fully supported see Mainconcept products) :)

Though yeah indeed it's somehow funny if you think about the fact that Microsoft and Adobe use primarily .mp4 and Apple who was basicly the main inventor of it decides now to use .mpg .ts for that streaming purpose :D on the other side it makes you mad again that they can't (or better don't want) decide for 1 common way todo it :(

[benwaggoner]

Though yeah indeed it's somehow funny if you think about the fact that Microsoft and Adobe use primarily .mp4 and Apple who was basicly the main inventor of it decides now to use .mpg .ts for that streaming purpose :D on the other side it makes you mad again that they can't (or better don't want) decide for 1 common way todo it :(
Indeed. David Singer of Apple was himself the inventor of fragmented MPEG-4 as used in Smooth Streaming. It was rather startling they didn't use it; it's rather perfect for this application.

Non-framgmented MP4 isn't a good format for this, because you'd have to download the headers for every bitrate in advance. With fMP4, a contiguous range of bytes can be independently decoded without any outside references required.

Here's a whitepaper on our implementation of it (written by zambelli):
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=03d22583-3ed6-44da-8464-b1b4b5ca7520

[Drachir]

now, what i ask myself is why is there mp4? is it really completely useless container for streaming purposes?

The MP4 file format, isn't intended to be delivered for streaming purpose. But the MP4 file format provide feature like hint-tracks, to support a RTP streaming server.


4. Will MP4 define an on-the-wire streaming protocol?

No. MP4 is being called a streamable format as opposed to a streaming format.The file format contains structures to facilitate streaming of the content in standard network protocols rather than defining a new format of its own. So MP4 is never carried over the wire; the contents of an MP4 file are delivered via standard TransMuxes.


For progressive download, fragmented MP4 files can speed up HTTP fast-start.

There is also RTSP support for Silverlight 3.0:
http://www.streamcoders.com/products/silversuite.html

[aldenml]

Actually is a bit strange that Apple decide to use this container but the way they defined HTTP Live Streaming has one "advantage" over Smooth Streaming. All the logic behind HTTP Live Streaming resides in the client; you have all the chunks created in the server. With Smooth Streaming you need some kind of service to read the fragment inside the fMP4 and send the chunk to the client.

The problem is that having one file per chunk (even for a chunk-duration of 10 seconds) is extremely difficult to handle large video sets with many bitrates per video.

In the other side, Smooth Streaming is more aggressive in the heuristic for bitrate selection and you need to handle only a few big files for each video. Here is more information about fragmented mp4 and smooth streaming: http://blog.cmstream.net