Apple's QuickTime X Player Does Not Support Authentication For HTTP Streaming

When Apple launched Snow Leopard in late August, it included a new version of the QuickTime player simply called QuickTime X. While it looks nice and has some new features, one of the major problems is that it can't authenticate to streaming servers or video being delivered via HTTP, which is bad since Apple has been focusing on HTTP support as one of the key advantgaes of the new player.

When you try to play a video the player gives you a message of "unauthorized" and other Mac folks I have asked to check, have gotten the same message. The only work around I can find for it is deleting it and re-installing version 7 of the QuickTime player using the custom install option from the Snow Leopard DVD.

Anyone from Apple care to comment on when this will be fixed? I see a few others have noticed the problem as well and have been talking about it on Apple's discussion list.

Comments

[Erik Herz]

If you want to secure your video, Apple recommends the use of AES-128 encryption of each .ts chunk and HTTPS for the delivery of keys.

Wowza makes this very easy to implement:
http://www.wowzamedia.com/forums/showthread.php?t=5382

Here is some information about this from IETF:
http://tools.ietf.org/html/draft-pantos-http-live-streaming-02#section-5.1

I wonder what the down-side of such an approach is.

Erik

[Scott Johnson]

A Snow Leopard update should leave your Quicktime7 Pro install intact, but moved to the "Utilities" folder.

[stef]

Apple is too focussed on walled garden technologies and services. Logically because it makes them a lot of money. But clearly the web wants an open player.

QuickTime X is a major step back. RTSP streaming performance is worse. There is no control panel where you can tune the players streaming behavior.

You can't step through a stream (keyframes) anymore, which is a very popular feature in science and education. All pro users went back to QuickTime 7.

The HTTP streaming implementation is pretty basic if you compare this to other implementations.

QuickTime (not just the player) was one of Apple's major assets. It is still used as a kick-ass media engine under the hood on iPhones and Macs, but Apple completely lost the race regarding the client.

Content owners want skinnable and programmable players, like Flash and Silverlight. Adobe recognized this first. Microsoft saw this too, but Apple didn't.

[Erik Herz]

"Walled garden"?

Let's summarize: Apple is proposing an IETF standard for the delivery of H264 video in MPEG TS chunks via HTTP. Content protection for the chunks will be via AES encryption and HTTPS. Bitrate adaptation is to be defined via SMIL. Rendering will be via the video tag in any HTML 5.0 compliant browser. This seems more open and more standard than the proprietary protocols/formats and compiled binaries of Silverlight and Flash.

Both Apple and Google believe that the most open "skinnable and programmable players" are the browsers. I believe that they will become the most influential companies regarding the standardization of media on the web, while Adobe and Microsoft's ability to lock us into proprietary products will wane.

Microsoft has already adopted the Apple standard in IIS so they can deliver video to the iPhone. Windows 7 includes a limited license for H264. Perhaps IE9 will implement the HTML 5.0 video tag with support of H264? I predict that it will. When Google makes Webkit-based browsers (Safari and Chrome) the best way to consume YouTube video, Microsoft will be ready to follow the standard.

[Tim]

Erik, is the IETF standard proposal you're talking about the one that was proposed back in June?

It appears the draft is set to expire today (Dec 10), at least according to http://tools.ietf.org/html/draft-pantos-http-live-streaming-01 Has there been any movement to keep the standard proposal alive?