It's free for up to 1 GB of storage and 1 TB of transfer a month. File max size is 105 MB, which is plenty for even a short HD clip.
You have to upload in WMV, but an uploaded file is available as both an embedded Silverlight player (Win/Mac, with Linux coming via Moonlight) and a straight link to the WMV playable by tons of tools, including VLC. And Windows Media Player and other tools will let anyone "Save As" from the web link if they want a local copy.
QuickTime Streaming Server doesn't dynamic stream switching or any kind of ISP caching.
It's fine for what it is, but what it is is a single stream to each viewer. It doesn't offer any of the cost savings and end-user bandwidth adaption of the Move Networks solution.
There's a huge TCO advantage in the Move Networks delivery technology, as it can take advantage of ISP web caches so that multiple viewers on the same network can watch the same file chunk, cutting ISP's in-stream bandwidth requirements hugely, as well as outgoing bandwidth needed. For content like this which has a huge simultanous audience, that means scaling up is much, much cheaper.
Move Networks also offers pretty seamless rate adaption, so you don't get buffering messages as available bandwidth changes.
I'm not aware of anything else like this availble in FOSS or generic MPEG-4. Most MPEG-4 software players and live encoders don't even support RTSP stream switching.
You'd need both Moonlight and a version of the Move plugin that integrates with it. The actual video experience is mainly driven by Move, with Silverlight handling UX and overlays.
Once you've done that, you should be able to navigate to the NBC Olympics video pages (although you still won't be able to view the video content quite yet... we're still working on writing the code to make that work).
Dubai is much more equatorial than NYC, for example (25 degrees north compared to 40), so you'll get a lot more time with the sun directly overhead compared to the caverns of Wall Street. Plus the walls look pretty darn reflective and it's REALLY SUNNY there, so even the ambient reflected light would probably be pretty ample for many places.
And those are some pretty big gaps between the "wedges." 50 meters each?
If only multicast was supported end-to-end in the US internet. Alas, it's not, and multicast really requries broad support.
Multicast mainly gets used in corporate/education/government networks where they've multicast enabled their whole subnet. And in a few countries where they rolled the whole infrastructure out with multicast. But for most of the world, you simply can't get a multicast broadcast out to the majority of end users.
Actually, Net Applications shows PPC dropped below half of Mac users nearly a year ago. Some big consumer sites I've talked to recently say PPC is now around 25% of Macs hitting their servers, and dropping quickly.
This was directly from a couple big consumer web sites. I haven't seen published numbers for this, but I'm sure there must be other web sites that track it.
But I was certainly surprised how quickly PPC has dropped as market share.
Actually, the most recent numbers I've seen is PowerPC Mac are down to about 25% of the Mac share of internet use. There may be a bunch out there, but they're being used a lot less than the Intel models, which would be no surprise. Flash can't even play 320x240 video well on the 1.33 GHz G4 I'm typing this on.
Good point. Of course, if an app only needs ODF level accuracy to the original, any app implementing OOXML can just ignore those more esoteric tags. And it certainly never would need to write them. Think x86 assembly; the ancient instructions are still supported for backwards compatibility (albeit slowly), but only a subset is used in practice by modern compliers.
Sure, it'd be very difficult for any third party to implement support for the legacy tags. But it's there if they can figure it out, and it at least gives a way forward to make legacy files XML structured for easier searching and maipulation.
If you assume the goal of OOXML is to make a documented XML format that supports the features of all existing Office files, it makes a whole lot of sense. And it's a handy thing have, compared to the binary formats.
Some people may think that's not a worthwhile goal, but it's important to recognize what something is designed to do before complaining it's designed badly for how a particular person imagines using it.
I don't think that's what it is; YouTube was server side transcoding long before they had more than one output format.
Even with multiple formats on their server, it'd be faster to transcode locally and upload given the usual user's bandwidth. A typical DV file is 25 Mbps, while all flavors YouTube delivers is probably 2 Mbps at most.
For example, I've got 12/1 updload, download, so uploading a 10 minute DV file would take me 4+ hours.
Remind me again how this differs from a Thin Client?
Processing gets done at the "optimum place" depending on the available mix of CPU power, access to the data, and bandwidth.
For example, with Windows Mobile, if I want to search for a particular message, it'll do the search on the server if I have access. Much faster to just deliver the results than have to pass all the messages down to the phone to do the search!
Flip case, look at YouTube. Why do I have to upload a large file over a slow upload connection so that server-side it gets converted to a small file? For any reasonable scenario, it'd be a lot faster to compress locally and upload the small file, and would save a whole bunch of server-side compute power.
Today, building apps such that different parts can differentially happen on different hardware is really hard. But when it's done, it provides a lot of value.
Also, MP3 is a MPEG-1 era technology (originally called MPEG-1 Layer III, in fact). Vorbis is kind of like WMA 9 in being "somewhat better than MP3" like other late 90's codecs.
However, for an ear-opening difference, try comparing WMA 10 Pro and HE AAC v2 at 48 Kbps to Vorbis at 48 Kbps. Big, big improvement with the more recent codecs.
The Theora decdoer is from a not very competitive late 90's codec (On2's VP3). You can tweak an encoder all you want, but all you can do is asymptotically approach what a compliant bistream is capable of. Moderen video codecs can do a lot more, on top of having much more refinement of the encoders themselves.
Like Vorbis, Theora would only be "good enough" in environments where quality at moderate-low bitrates isn't a major concern. But for web video, other codecs will do much, much better.
Slashdot Mirror
Silverlight Streaming?
http://streaming.live.com/
It's free for up to 1 GB of storage and 1 TB of transfer a month. File max size is 105 MB, which is plenty for even a short HD clip.
You have to upload in WMV, but an uploaded file is available as both an embedded Silverlight player (Win/Mac, with Linux coming via Moonlight) and a straight link to the WMV playable by tons of tools, including VLC. And Windows Media Player and other tools will let anyone "Save As" from the web link if they want a local copy.
I've got a sample/tutorial on my blog:
http://on10.net/blogs/benwagg/Direct-links-to-files-on-Silverlight-Streaming-and-new-All-Stars-clip/
It's one of the few free services that'll give you a straight, ad-free link to the media file.
You don't need a CAL for web server access or streaming media access.
Yes, streaming live video to a large audience would be much easier yet in that universe :).
Alas, we live in this one...
QuickTime Streaming Server doesn't dynamic stream switching or any kind of ISP caching.
It's fine for what it is, but what it is is a single stream to each viewer. It doesn't offer any of the cost savings and end-user bandwidth adaption of the Move Networks solution.
There's a huge TCO advantage in the Move Networks delivery technology, as it can take advantage of ISP web caches so that multiple viewers on the same network can watch the same file chunk, cutting ISP's in-stream bandwidth requirements hugely, as well as outgoing bandwidth needed. For content like this which has a huge simultanous audience, that means scaling up is much, much cheaper.
http://www.movenetworks.com/why-move/frequently-asked-questions
Move Networks also offers pretty seamless rate adaption, so you don't get buffering messages as available bandwidth changes.
I'm not aware of anything else like this availble in FOSS or generic MPEG-4. Most MPEG-4 software players and live encoders don't even support RTSP stream switching.
You'd need both Moonlight and a version of the Move plugin that integrates with it. The actual video experience is mainly driven by Move, with Silverlight handling UX and overlays.
Moonlight hasn't implemented all of the Silverlight 2 features needed for the Olympics yet.
http://jeffreystedfast.blogspot.com/2008/08/moonlighting-olympics.html
Once you've done that, you should be able to navigate to the NBC Olympics video pages (although you still won't be able to view the video content quite yet... we're still working on writing the code to make that work).
Dubai is much more equatorial than NYC, for example (25 degrees north compared to 40), so you'll get a lot more time with the sun directly overhead compared to the caverns of Wall Street. Plus the walls look pretty darn reflective and it's REALLY SUNNY there, so even the ambient reflected light would probably be pretty ample for many places.
And those are some pretty big gaps between the "wedges." 50 meters each?
Found it!
Intel Macs have made up the majority of the Mac internet user base since nearly a year ago.
http://arstechnica.com/journals/apple.ars/2007/11/05/intel-macs-overtake-ppc-macs-in-october
NBC has said that the Olympics content will be availble through the end of the year.
The Moonlight guys are looking for help if you want it to work by that deadline!
http://alexzambelli.com/blog/2008/08/16/moonlight-20-help-wanted/
The website said that it was Vista only, on the main page when I checked
Really? Which web site? This is the page you go to if you click for more Silverlight information in the install dialog: http://www.nbcolympics.com/silverlight/index.html
It clearly lists out XP and Mac OS X.
If only multicast was supported end-to-end in the US internet. Alas, it's not, and multicast really requries broad support.
Multicast mainly gets used in corporate/education/government networks where they've multicast enabled their whole subnet. And in a few countries where they rolled the whole infrastructure out with multicast. But for most of the world, you simply can't get a multicast broadcast out to the majority of end users.
There's actually a ton of stuff archived for those sports. You just have to drill down to each sport's "all videos" page.
297 Swimming videos: http://www.nbcolympics.com/swimming/video/all/index.html
124 Beach Vollyball videos: http://www.nbcolympics.com/beachvolleyball/video/all/index.html
380 Gymnastic videos: http://www.nbcolympics.com/gymnastics/video/index.html
Note that the Highlights and Encore clips are at a higher bitrate (up to 1.5 Mbps) than the Live and Live Rewind clips (up to 650 Kbps).
Alex Zambelli's blog has a bunch of details http://alexzambelli.com/blog/
Actually, Net Applications shows PPC dropped below half of Mac users nearly a year ago. Some big consumer sites I've talked to recently say PPC is now around 25% of Macs hitting their servers, and dropping quickly.
http://arstechnica.com/journals/apple.ars/2007/11/05/intel-macs-overtake-ppc-macs-in-october
Also, Silverlight 2 is supported on Windows 2000, it's the NBCOlympics.com web site that doesn't support it.
http://www.microsoft.com/silverlight/resources/install.aspx?v=2.0#sysreq
Ah, sorry. I didn't phrase that well.
I meant that PPC is down to 25% off all Macs. Total Mac use for the site was about 4%, and PPC was 1% of them.
This was directly from a couple big consumer web sites. I haven't seen published numbers for this, but I'm sure there must be other web sites that track it.
But I was certainly surprised how quickly PPC has dropped as market share.
Actually, the most recent numbers I've seen is PowerPC Mac are down to about 25% of the Mac share of internet use. There may be a bunch out there, but they're being used a lot less than the Intel models, which would be no surprise. Flash can't even play 320x240 video well on the 1.33 GHz G4 I'm typing this on.
Good point. Of course, if an app only needs ODF level accuracy to the original, any app implementing OOXML can just ignore those more esoteric tags. And it certainly never would need to write them. Think x86 assembly; the ancient instructions are still supported for backwards compatibility (albeit slowly), but only a subset is used in practice by modern compliers.
Sure, it'd be very difficult for any third party to implement support for the legacy tags. But it's there if they can figure it out, and it at least gives a way forward to make legacy files XML structured for easier searching and maipulation.
If you assume the goal of OOXML is to make a documented XML format that supports the features of all existing Office files, it makes a whole lot of sense. And it's a handy thing have, compared to the binary formats.
Some people may think that's not a worthwhile goal, but it's important to recognize what something is designed to do before complaining it's designed badly for how a particular person imagines using it.
It is not about "We head Microsoft", it is about the fact that something like WordWrapLikeWord95 should not exist in an ISO standard.
Sure it is, if the goal of the standard is to offer forward compatibility of legacy documents.
Most of the objections around here seem to beg the question of the goals of OOXML, which are different from ODF.
I don't think that's what it is; YouTube was server side transcoding long before they had more than one output format.
Even with multiple formats on their server, it'd be faster to transcode locally and upload given the usual user's bandwidth. A typical DV file is 25 Mbps, while all flavors YouTube delivers is probably 2 Mbps at most.
For example, I've got 12/1 updload, download, so uploading a 10 minute DV file would take me 4+ hours.
Remind me again how this differs from a Thin Client?
Processing gets done at the "optimum place" depending on the available mix of CPU power, access to the data, and bandwidth.
For example, with Windows Mobile, if I want to search for a particular message, it'll do the search on the server if I have access. Much faster to just deliver the results than have to pass all the messages down to the phone to do the search!
Flip case, look at YouTube. Why do I have to upload a large file over a slow upload connection so that server-side it gets converted to a small file? For any reasonable scenario, it'd be a lot faster to compress locally and upload the small file, and would save a whole bunch of server-side compute power.
Today, building apps such that different parts can differentially happen on different hardware is really hard. But when it's done, it provides a lot of value.
"You keep using that word. I do not think it means what you think it means."
Being excitedly positive about something may be many things, but it's not Fear, Uncertainty, and Doubt.
True. But given typical internet bandwidths, "good enough" needs to be very good indeed for professional content.
Theora would be fine for a YouTube like service (which largely uses the even more ancient H.263 codec).
Also, MP3 is a MPEG-1 era technology (originally called MPEG-1 Layer III, in fact). Vorbis is kind of like WMA 9 in being "somewhat better than MP3" like other late 90's codecs.
However, for an ear-opening difference, try comparing WMA 10 Pro and HE AAC v2 at 48 Kbps to Vorbis at 48 Kbps. Big, big improvement with the more recent codecs.
The Theora decdoer is from a not very competitive late 90's codec (On2's VP3). You can tweak an encoder all you want, but all you can do is asymptotically approach what a compliant bistream is capable of. Moderen video codecs can do a lot more, on top of having much more refinement of the encoders themselves.
Like Vorbis, Theora would only be "good enough" in environments where quality at moderate-low bitrates isn't a major concern. But for web video, other codecs will do much, much better.
That improvement is clearly worthwhile, but VC-1 and H.264 have gotten a whole lot better in the last 2.5 years as well.
From the links, I don't see much evidence that Theora has caught up significantly in relative performance to the standardized-but-patented codecs.