Slashdot Mirror
Open-Source Streaming Video, Sans Plug-Ins
gravityworshipper writes: "Nice new project, Sureplayer, making a GPL MPEG-1 streaming video encoder that plays through any browser with Java. The Ogg Vorbis people may have something wonderful someday, but this is already sort of working (and has a catchier name). The sound still sucks (doesn't work at all in N4.7X for Linux), but they're looking for people to help. I am tired of using (proprietary) Real and not being able to see Quicktime or Windows Media Player video at all in Linux. Sureplayer encoder/server is open source, so makes it easier and cheaper for indie artists to put video online, and easier for their work to be seen because no client download required, just a browser with Java. Real & MS & QT give away the client, then charge big $$ for encoding/server software, which users don't realize but video people do. I saw this is a NewsForge Report. Cool!"
The Quicktime Streaming Server is free and works on Linux, OS X and NT. The encoding software is around $199 (not 'big bucks' in my book) and you don't even need to upgrade Quicktime to 'Pro' for $30 to watch streaming content. I'm using this combination and it kicks ass! Easy, cheap and effective - I'm maxxing out my 100Mbit connection no problem on an older G3 mac.
And to be even more accurate, MS recently started *paying* radio stations to use Media Server/.WMA audio. That's why a lot of stations recently dropped Real even though Real still has 90+% market share for streaming media (no station is suicidal enough to do that sort of thing otherwise).
I agree - stick with DivX or some truely open source CODEC like ffmpeg (also MPEG-4 compatible) or MPEG2Movie whiuch achieves similar compression (but better speed) in an MPEG-2 format. OpenDivX isn't even MPEG-4 - it's just a basic half-pel motion comp MPEG-1 algorithm plus a deblocking filter. It's amazing how many people confuse the bitstream formats with the codec features - why not call OpenDivX Quicktime since the MPEG-4 bitstream format is Quicktime? Sigh.
Was anyone else a little disturbed by that Perl Harbor Video? "Hating is not enough", "Remember the vengeance in our hearts" "When you buy bonds this week, remember that they are vengeance bonds".
:P
Sheesh, talk about disturbing propaganda, the video makes our country sound like it's run by a bunch of klingons
Rate me on picture-rate.com
"and dear god does this website suck now." -- CmdrTaco
A Java applet is effectively the same as a plugin such as Flash or QuickTime. You still have to download the player program. In Java it's distributed as CLASS files (often packaged in a Java ARchive); with "normal" plugins it's an executable file.
You still have to worry about program size (how long will it take to download over a slow connection), versioning (what if the user has an old version of the player, or what if a newer version won't play older content), and security (what if the user disables, refuses to download, or does not grant the proper access rights to the program).
There are some advantages to using Java:
- The applets are generally smaller and quicker to download (since a large part of the class library already exists on the user's system.
- You can develop a single program that will work on all platforms (see note below)
- Installation of the applet is generally transparent to the user, but this is mostly because the applets are using the old Java 1.0 security model that doesn't require any user intervention, and thus poses great restrictions on what the applet can do.
However, because of the horrible implementations of JVMs in the major browsers, point #2 is pretty much moot; you can't be sure that your applet will work correctly in every browser/platform combination without extensive testing.Add to that the fact that the most popular browser family in the world (Internet Explorer) runs a Java version that is horribly out-of-date, and will never upgrade. So you're always stuck using the oldest and ugliest class library; at least you can hope for a recent version when using Flash.
You can get around all of these problems by requiring that the user have Sun's Java Plugin (a browser plugin that has the most recent JVM, and a standardized implementation). Of course, this defeats the entire purpose of not requiring plugins to view the content.
So please, all web developers, stop saying that your software doesn't require a plugin. You're only right on a technicality; the net effect to your users is still the same.
No it isnt... divx is the preferred format for ripping. OpenDivx is just a basic implementation of MPEG-4 v1. The rest of the world is moving on, m$ (of which divx was ripped) and 3ivx are at version 3 for instance.
OpenDivx is missing a lot of advanced compression features, and its going to get sued to hell for contributory patent infringement if they get succesfull.
It was always amazing to me how Realnetworks managed to convince the world that you had to use the PNM(Progressive Networks Media) protocol and their proprietary server to stream audio and video. I deployed some of their version 2 (vintage dark ages) server products - which cost us a fortune - and in the back of one of the technical references it mentions that little fact. "Oh, and if you're not actually streaming LIVE video content, then you can stream it via HTTP and you didn't have to spend XX thousands of dollars to buy our server. All you actually needed was the encoder. Sorry we didn't tell you before you bought".
Now to be perfectly honest, I can't blame (the then named) Progressive Networks for not making this fact known. It was my inexperience with streaming media at that time that led me astray. It does however indicate the underlying business model they were using was based entirely in a fabrication. As I recall, the server, and not the encoder was the expensive part of the package we were sold.
--CTH
---
--Got Lists? | Top 95 Star Wars Line