Slashdot Mirror

or licensed in a way that makes them uninteresting to most free software developers (like Helix)

I used to work as an open-source developer with the helix engine (still do, in fact), and didn't find the licensing to be that much of a turn-off. It's kinda like the NPL, or the GPL with the special rights for the Licensor outlined in section 3.

You can read the Helix license mentioned in the article here: RPSL

ah yes, my comments about OS X and Linux were related to the positive responses, about the earlier player versions on those platforms, and how they behave themselves very well.

RealPlayer 10 Beta is available only on Windows for now. OS X on the way.

For Linux and Solaris, there is the on-going Helix Player open source project. This is not RealPlayer 10.

https://player.helixcommunity.org/ Here is the overview of the Helix Player:

Overview

The Helix Player is the Helix Community's open source media player for consumers. It will have a rich and usable graphical interface and support all of the types of media currently offered by our Helix DNA Client.
Features

* Gtk+/Gnome interface
* video zoom: original, double size and full screen
* media type support:
o SMIL 2.0
o RealVideo (RV9, RV8, RV7, RVG2)
o RealAudio (RA8, G2 audio)
o MP3
o Ogg Vorbis
o MPEG4 (patent license for MPEG4 must be obtained separately)
o H.263
* Mozilla browser plug-in
* graphical installer
* RPM installer

The latest nightly builds of Helix Player will be able to play most of the RA/RV10 codecs. Current status is RealVideo 10 works, RealAudio low-bitrate works, RealAudio high bitrate (AAC) doesn't work, but should start working in a nightly soon. We will post an update here when RA high bitrate is working as well.

Most of these "concerns" I have seen, are on players that are really, really old, and on windows. Real has been contributing to Open Source for a while now at Helix(TM) Community. You might want to do yourself a favor, and do a little research before you make remarks about something, you obviously don't know anything about. "The Helix community is a collaborative effort among Real, independent developers, and leading companies to extend the Helix DNA(TM) platform, the first open multi-format platform for digital media creation, delivery and playback. The Helix DNA platform is comprised of the following: Helix DNA Client Helix DNA Producer Helix DNA Server RealAudio and RealVideo"

Why can't you download MS1? Could you please let me know if you found a broken link somewhere?

Here is the right information by the way. MS1 I do recommend the nightly builds if you want recent bug fixes. Also MS2 is right around the corner.

As I noted in the RA/RV 10 announcement on the project page, we are working on getting the codecs to work perfectly by ms2 later this month. If there are any other problems I would urge you to file a bug or post it in the forum. And, thank you for giving Helix Player a try! Vikram Dendi Program Manager (Helix Player)

That works on linux, developed in the helix community.

Boy, works on linux is the catch, isn't it?

The helixplayer open source project has a Milestone build, which you can no longer download, as it's pretty old. They have a nightly builds page, though.

I tried the latest Developer Release (DR5). First I tried playing some Real 10 Video. First I tried the Paycheck trailier. The command line client failed with an X error. The GUI client said (here it comes) "Buffering", then hung at different percentages, and crashed for all the other videos on that page. When I say hung, I don't mean stuck waiting for network; the GUI refused to update any further.

helixplay refused to play an mpeg (it didn't crash or anything... it just wouldn't do anything when you click "Play"). splay crashed on an mpeg. Both did play new codeced audio streams and mp3s, though. splay managed to play an older RealVideo stream (in this case NASA TV), but helixplay hung as usual.

Then I tried the latest nightly build (20040107). That one performed exactly the same.

There is another project that provides a plugin to realplayer 8 for playing real 10 content under linux, but finding those files is as hard as finding files on the real.com site. The "binaries" link takes me to a license agreement, but accepting that only led to an error page. Clicking binaries again, and agreeing again takes me to a blank page.

So, can you play Real 10 content in Linux? If you were trying really hard to be optimistic, you could say "not yet", I suppose.

That works on linux, developed in the helix community.

Boy, works on linux is the catch, isn't it?

The helixplayer open source project has a Milestone build, which you can no longer download, as it's pretty old. They have a nightly builds page, though.

I tried the latest Developer Release (DR5). First I tried playing some Real 10 Video. First I tried the Paycheck trailier. The command line client failed with an X error. The GUI client said (here it comes) "Buffering", then hung at different percentages, and crashed for all the other videos on that page. When I say hung, I don't mean stuck waiting for network; the GUI refused to update any further.

helixplay refused to play an mpeg (it didn't crash or anything... it just wouldn't do anything when you click "Play"). splay crashed on an mpeg. Both did play new codeced audio streams and mp3s, though. splay managed to play an older RealVideo stream (in this case NASA TV), but helixplay hung as usual.

Then I tried the latest nightly build (20040107). That one performed exactly the same.

There is another project that provides a plugin to realplayer 8 for playing real 10 content under linux, but finding those files is as hard as finding files on the real.com site. The "binaries" link takes me to a license agreement, but accepting that only led to an error page. Clicking binaries again, and agreeing again takes me to a blank page.

So, can you play Real 10 content in Linux? If you were trying really hard to be optimistic, you could say "not yet", I suppose.

That works on linux, developed in the helix community.

Boy, works on linux is the catch, isn't it?

The helixplayer open source project has a Milestone build, which you can no longer download, as it's pretty old. They have a nightly builds page, though.

I tried the latest Developer Release (DR5). First I tried playing some Real 10 Video. First I tried the Paycheck trailier. The command line client failed with an X error. The GUI client said (here it comes) "Buffering", then hung at different percentages, and crashed for all the other videos on that page. When I say hung, I don't mean stuck waiting for network; the GUI refused to update any further.

helixplay refused to play an mpeg (it didn't crash or anything... it just wouldn't do anything when you click "Play"). splay crashed on an mpeg. Both did play new codeced audio streams and mp3s, though. splay managed to play an older RealVideo stream (in this case NASA TV), but helixplay hung as usual.

Then I tried the latest nightly build (20040107). That one performed exactly the same.

There is another project that provides a plugin to realplayer 8 for playing real 10 content under linux, but finding those files is as hard as finding files on the real.com site. The "binaries" link takes me to a license agreement, but accepting that only led to an error page. Clicking binaries again, and agreeing again takes me to a blank page.

So, can you play Real 10 content in Linux? If you were trying really hard to be optimistic, you could say "not yet", I suppose.

But I shouldn't assume too much. What problems are you having?

If you find that RealPlayer 10 still isn't solving your problems, you've got two options for a fully legal way of giving your end users what they need beside using our consumer edition of RealPlayer:

• RealPlayer Enterprise - This is a paid product which lets you control what features you deploy to your end users. It's not a free product, but you can download a free trial
• Work with us on developing a Win32 version of the Helix Player (currently only for Linux, soon for Solaris). Given that the Helix Player uses Gtk, and there's a Gtk for Win32, it may not be that tough to port. Not an instant gratification solution, but one which gives you maximum control.

Rob Lanphier
Helix Community Coordinator
RealNetworks

But I shouldn't assume too much. What problems are you having?

If you find that RealPlayer 10 still isn't solving your problems, you've got two options for a fully legal way of giving your end users what they need beside using our consumer edition of RealPlayer:

• RealPlayer Enterprise - This is a paid product which lets you control what features you deploy to your end users. It's not a free product, but you can download a free trial
• Work with us on developing a Win32 version of the Helix Player (currently only for Linux, soon for Solaris). Given that the Helix Player uses Gtk, and there's a Gtk for Win32, it may not be that tough to port. Not an instant gratification solution, but one which gives you maximum control.

Rob Lanphier
Helix Community Coordinator
RealNetworks

Seven Steps to Source! 1) Click the Register link in the upper right 2) Fill in the registration form, submit it, and wait for the e-mail with your password ticket URL 3) Click that URL in the e-mail and set your password on the subsequent form 4) Review and agree to the site terms of use 5) On the left, click on either the RCSL or RPSL link in the Licenses box 6) Review the terms of whichever license you chose (and, in the case of RCSL, fill in the form), and accept the license 7) Also, click on the binary EULA license in the same Licenses box to agree to that, so you can access the compiled binaries found in the distribution project -- needed if you are going to build Helix DNA with RealAudio/RealVideo support

RealNetworks Public Source License (RPSL) You can view the terms of the RPSL to see whether it fits your needs. To agree to this license, please register on the site -- you will then be given a chance to agree to the *actual* RPSL and gain access to the RPSL-licensed source code.

That's why they're working on this:

https://www.helixcommunity.org/

Didn't Real Networks decide to write an open source media player? Or at least one where bits of it were open source. Basically everything but the useful bit.

1. How are Real's formats any more proprietary than Microsoft's?

The Helix Player Project looks like it is both open and (optionally) closed. Other projects use similar dual open and closed licences.

You can download the helix player. It is quite stable, and wonderfully free of crap.

RealNetworks' first public use of the .rpm file extension is practically simultaneous with Red Hat use: (see RealAudio 2.0 release and Red Hat 2.0 release).

The need for using .rpm with modern browsers is way less than it was. However, there's enough legacy content out there that we can't just stop using it.

However, we're in the process of working on the Helix Player installer right now, so if you've got some ideas for how the two can peacefully co-exist, we'd love to hear it.

Rob

Two good examples are RealMedia and Flash. I realise that there are solutions to both of these, but the quality is nothing compared to what is available for Mac or Windows.

Really? My experiences don't agree with your observations.

I haven't had any problems with Flash, it's just as annoying as the Windows version when displaying ads, lets me play the little flash games, navigate all the flash sites, and see all the flashtastic content on the web.

As for RealMedia, their new Helix Player has been working great for me. So good that I actually install it on all my Linux desktops, unlike RealOne for Windows which I never touch.

Sounds like you're doing some fun stuff there. I work for MNN cable access in NYC. We just finished rebuilding our studio where we just got done dealing with these same issues. I understand joo.

1> Lighting. This is probably the most important part of making a show look good. I think I'd be doing you a disservice to say "get two inkies, three 5K fresnels, blah blah blah." You should really consider bringing in a good lighting designer who can not only recommend some good fixtures, but who can also put together some stock light plots that will look good for 95% of all productions. Never sleep on good lighting for a studio. It really makes all the difference.

2> Cameras. We went with the Hitachi Z3000W as our studio camera. It's digital, it has great resolution, and a wicked nice lens. They provide a lot of bang for the buck (can't remember how much we paid, tho.) Take a look at Triax cabling for connecting the cameras back to Control. It's flexible, the signa's clean, and they're a lot easier and cheaper to replace. For a teleprompter, we're just using QTV with WinCue. Works fine.

3> Audio. We had some Behringers around but they didn't stand up to the abuse we put it through. Then we found the Sony ECM-55B. It's our workhorse lav. I've had nothing but headaches with wireless so I'm not going to comment on them.

4> Decks. There are a ton of Good Broadcast Reasons to go with BetaSP but it's just so damn expensive. I love DV. Because we're public access, we have to work with civilians who can't afford $20 per tape. Let them master to DV at $4 a pop and they can go home, finish in iMovie or Premiere on their home computer and bring it back in to us all clean and digital like. Sure, it's compressed and of course it might artifact, but working with analog in post is a system bandwidth hassle. Meanwhile DV works at full-res on my mom's iMac. Until Thompson decides to make the Filmstream for $3K, I'm sticking with DV. I say go with DV if you can (DV, DVCAM, DVCPRO, whatever.) You can't beat the price.

5> I'm not a big fan of the Streaming In A Box solutions. What you get for your streaming really depends on what you want to deliver. Do you want to provide video on demand? Bring the video into a Mac or PC via FireWire, use Discreet Cleaner to convert the file to MPEG4, Real, whatever, and drop it on a streaming server with lots of storage, hordes of RAM, and some fat ass bandwidth. Just looking to simulcast your broadcast? Even easier: run the program output of your master control switcher to a video capture card on a superfast PC. Start up some live encoder software (QuickTime Broadcaster, Helix Producer, MPEG4IP) and have it send a unicast stream to a replication server attached to the net. With live streaming, you don't need any storage at all (unless you need to archive.)

6> Newsdesks. Check out uniset. They make good looking inexpensive sets and CYC panels (for doing green screen). We've been very happy with their stuff.

One last thing: check out DVLince - an all-DV server based production workflow for under $300K. Sony just bought them to rebrand it as their own gear. It might not be exactly what you need, but it's worth checking out.

The webpage is severely out of date, but there's a lot of work going on with linuxarm/qtopia right now (because of Motorola, among others).

Rob

• Motorola is working with RealNetworks on RealOne for Motorola phones
• Motorola and RealNetworks' work is based on Helix
• There's support in Helix for Ogg Vorbis

Rob Lanphier
Helix Community Coordinator

• Motorola is working with RealNetworks on RealOne for Motorola phones
• Motorola and RealNetworks' work is based on Helix
• There's support in Helix for Ogg Vorbis

Rob Lanphier
Helix Community Coordinator

The open standards version of RealPlayer is called Helix.

Why are we being hardasses about making sure that people agree to licenses? It's a combination of the way the legal system works, and our general conservativeness that stems from being a publicly traded company.

Right, well look: here is an example of an exemplary corporate-sponsored open source project. Rule number 1:

Do not make it difficult to get the source.

Once you're made the decision to go open source, then you have to walk the walk.

Note that Larry's tract is oriented towards end users presumably of binary programs. You're dealing with developers, that's already a big difference. For example, you know the developers intend to pass the licensed material on to others, and you know they won't enforce the same level of documentation as you do on your main page.

Note also, that Larry's paper doesn't say anything about requiring the licensee to identify themself.

Now let me say, I'm disappointed to see the kind of reaction you're getting from many people here to what I see as an important and valuable contribution. What can you do to fix that? Start with your home page. Why is it https, for starters? OK, let's not go there. Just think about this: go out there to any of the thousands of OSS project pages and consider the difference between them and your page.

As an OSS developer, the links I want to see on a project page are:

- What is this
- Who are we
- link to FAQ
- News
- License
- *Download*
- Mailing lists (archives, subscribe)
- Become a registered developer
- Now the PR...

You can leave out much stuff like "Welcome" and "Participating". The people coming into your site already know they're welcome if they see links such as above, and they know what to do with them, i.e., they already know how to participate.

As for assenting to the license agreement, just link the agreement from the download link, and link the tarball page from the license. Nice and easy, and normal.

Don't require anybody to fill out questionaires to get the source. That's a guaranteed way to get off on the wrong foot. Instead, save the questionaire for people who want to become registered developers. The key point here: you don't get a second chance to make a first impression, make the first one a good one.

Presumably, your job #1 is to get the source code out. Anything you do to interfere with that is just getting in the way of your own agenda. I strongly suggest you go out and start looking at other project pages, and make yours look more like the others.

This is a great set of observations. We've learned a lot in the past year, and we realized that with this initiative, we can't be as hyperfocused on developers as we have been in the past. Hence why we're working on the building a great piece of *open source* end user software for Linux/Solaris/etc.

So in short, you're correct, the initiative is focused on developers, and I'm glad you're recognizing the value of the system.

Rob Lanphier
Helix Community Coordinator

Getting the code is admittedly more complicated than it needs to be (and we're working on that), but hyperbole like the parent post should not be modded up as "Informative". The steps are:

1. Sign up for the site, filling in a form with proposed user name, real name, company name, and email.
2. Receive confirmation URL, and visit included URL
3. Agree to site terms of use
4. Agree to RPSL (an OSI certified license)
5. Get source code via CVS/SSH

Why are we being hardasses about making sure that people agree to licenses? It's a combination of the way the legal system works, and our general conservativeness that stems from being a publicly traded company.

There are good reasons to ensure that "manifestation of assent" occurs, even for open source. I'll defer to Larry Rosen's excellent paper on the topic. Larry, as you may know, is the General Counsel for the Open Source Initiative, and while his opinion is only an opinion, it's a very well informed one.

As for the functionality, it's more than just "shells". There's complete software there, and it's the foundation of our commercial products. Additionally, the combination of Ogg Vorbis, SMIL 2.0, JPEG, GIF, and PNG is very powerful, and *all open source*. No RealAudio/RealVideo necessary, and the app is pretty unique. For an example which plays in the Helix Player (and versions of RealPlayer/RealOne Player with the Ogg Vorbis codec installed), check out the following link:

http://rtsp.org/2003/demos/oggsmil/oggdemo.smil

Once one starts looking at SMIL (especially SMIL 2.0), you begin to realize that a system that can support it does a lot.

Rob Lanphier
Helix Community Coordinator

But anyway, better read all this carefully.

Real Networks: https://www.helixcommunity.org

For Helix Community, we have a dual-licensing model which gives the community an OSI certified license (RPSL), and a more commercially focused license (RCSL). Additionally, there are components that remain proprietary.

Where do you draw the line? That's always tough, but having the dual-license makes it easier to err on the side of opening up "too much".

Rob Lanphier
Helix Community Coordinator

For Helix Community, we have a dual-licensing model which gives the community an OSI certified license (RPSL), and a more commercially focused license (RCSL). Additionally, there are components that remain proprietary.

Where do you draw the line? That's always tough, but having the dual-license makes it easier to err on the side of opening up "too much".

Rob Lanphier
Helix Community Coordinator

For Helix Community, we have a dual-licensing model which gives the community an OSI certified license (RPSL), and a more commercially focused license (RCSL). Additionally, there are components that remain proprietary.

Where do you draw the line? That's always tough, but having the dual-license makes it easier to err on the side of opening up "too much".

Rob Lanphier
Helix Community Coordinator

Check out Helix's helix-client site. There've been some early developer release binaries available for quite some time.

For real world use, you're probably better off using something like mplayer w/ the realplayer-codecs or if you're using Windows, something like JetAudio, or as others have mentioned, Media Player Classic + Real codecs

...since July last year. Go fetch.

Hello? Is this brain on? (-:

There's nothing to this. You probably don't need additional hardware. Maybe a sound card. I have a 500 Mhz P3 box simultaneously encoding two video+audio streams full time. One is Windows Media and one is Real. The box is more than enough. You're talking about encoding just audio. One computer should do fine.

Get & install two soundcards. Connect the outputs of each source into the line in of each.

Get a copy of Darwin Streaming Server or Helix Server or any of the shoutcast MP3 streaming things.

The benefit to using Darwin or Helix is that they're made to record from live input rather than just streaming files on the drive.

... I tend to think the Helix client, alone or incorporated into a WM player, is the right way to go.. Or at least pick _ONE_ good framework and avoid massive effort duplication ... (and that was only up to the G's!)

It seems there's an awful lot of video players that come from a number of "itches" or "brushing up on linux multimedia programming" urges, with little attention paid to usability, and that really doesn't serve the USERS as well as a more focused app.

There's already a project folder for Ogg Support.

Kudos to them for not encouraging WM without getin' paid.

The Ogg Vorbis support was designed by the Xiph.org Foundation mainly for the client. It could very well be that the plugin they wrote "just works" on the server, though I don't think anyone has tested that yet.

I imagine that we'll get things working on the server side before too long. Feel free to jump in at the Helix/Xiph development area to chip in.

Rob Lanphier
Helix Community Coordinator

The Ogg Vorbis support was designed by the Xiph.org Foundation mainly for the client. It could very well be that the plugin they wrote "just works" on the server, though I don't think anyone has tested that yet.

I imagine that we'll get things working on the server side before too long. Feel free to jump in at the Helix/Xiph development area to chip in.

Rob Lanphier
Helix Community Coordinator

I've been working on a plugin for the server and can say the SDK is pretty good. A little loose on the docs sometimes, but releasing the source probably will help.

My plugin didn't deal directly with streaming, but when scanning the docs it looked like they expose the interfaces you would need to integrate new codecs & file formats into the client & server.

They did have some funky restrictions (as I recall):

• You can't suggest to the user to change mime-type associations away from realplayer.
• You can't have any auto-update software except real's update.

Are the RSPL and ASPL compatible? I mean, can we take code from Darwin and code from Helix and legally put it into the same app?

We wish we could be GPL-compatible, but that is more of a restriction in the GPL than in the RPSL.

Rob Lanphier
Helix Community Coordinator

We wish we could be GPL-compatible, but that is more of a restriction in the GPL than in the RPSL.

Rob Lanphier
Helix Community Coordinator

I'll take off my RealNetworks hat for a sec. I'm not a big fan of DRM solutions. I've seen the days of hardware dongles and other silly solutions that don't seem to go anywhere, and have not had a personal interest in being involved in that sort of thing. Many DRM systems are intrusive, and as I sit here on my Linux box without the ability to play back our DRM content, I understand why the community gets frustrated.

That said, you'll notice that I still work at RealNetworks. I feel that, as a whole, the company wants to do the right thing, and I'm hoping I can enlist the community's help in that.

As for the criticism of "ooo, DRM is bad bad bad, and anything associated with it is bad bad bad", here's my response to that:

• I think what RealNetworks is doing with open source in the Helix Community could really change the landscape for the better.
• As for DRM; I'm not personally involved in our DRM efforts, and don't plan to be, but I see it as a necessary evil. To really be in our business these day, one has to provide a solution (mind you, our business is not only software production, but content distribution through our RealOne SuperPass service). And I don't see it as immoral (as some do), just silly.
• As for the legislative efforts relative to DRM, I'm told we are on record as opposing the broadcast flag provisions (still investigating). At any rate, I think we've been pretty good citizens when it comes to our positions on legislation.
• This is a win for open formats. Transcoding is an ugly process, and DRM systems need to get their content from somewhere. If the input (and output) of a DRM system is an open format (e.g. Ogg Vorbis), then content providers can decide to go with that format, confident that should they ever need to protect that content with a DRM system down the road, there's a solution for them.

Rob Lanphier
Helix Community Coordinator

I'll take off my RealNetworks hat for a sec. I'm not a big fan of DRM solutions. I've seen the days of hardware dongles and other silly solutions that don't seem to go anywhere, and have not had a personal interest in being involved in that sort of thing. Many DRM systems are intrusive, and as I sit here on my Linux box without the ability to play back our DRM content, I understand why the community gets frustrated.

That said, you'll notice that I still work at RealNetworks. I feel that, as a whole, the company wants to do the right thing, and I'm hoping I can enlist the community's help in that.

As for the criticism of "ooo, DRM is bad bad bad, and anything associated with it is bad bad bad", here's my response to that:

• I think what RealNetworks is doing with open source in the Helix Community could really change the landscape for the better.
• As for DRM; I'm not personally involved in our DRM efforts, and don't plan to be, but I see it as a necessary evil. To really be in our business these day, one has to provide a solution (mind you, our business is not only software production, but content distribution through our RealOne SuperPass service). And I don't see it as immoral (as some do), just silly.
• As for the legislative efforts relative to DRM, I'm told we are on record as opposing the broadcast flag provisions (still investigating). At any rate, I think we've been pretty good citizens when it comes to our positions on legislation.
• This is a win for open formats. Transcoding is an ugly process, and DRM systems need to get their content from somewhere. If the input (and output) of a DRM system is an open format (e.g. Ogg Vorbis), then content providers can decide to go with that format, confident that should they ever need to protect that content with a DRM system down the road, there's a solution for them.

Rob Lanphier
Helix Community Coordinator

Real has been moving toward this sort of thing for a long time. I don't know why anone sticks with them: their player is crap, they're just an obnoxious company, and they make it _really_ hard to download the free player.

But what about their open source initiative? Can one make a more tolerable player with that? (I tried sourceforge, but they're too busy for a search at the moment.)

Real Networks has open sourced some of its code, creating the Helix Community. Also, the Helix Server is able to stream RealVideo, Quicktime, Windows Media and MPEG-4 from a single server running on a Linux box! Try that with any other server.

Regarding Ogg + MPEG-4 video. The licensing terms for MPEG-4 Video are pretty gnarly. How about Ogg and H.263+ (which, incidently, is what the 3GPP standardized on). That combination nearly works today in Helix DNA Client. We're already committed to making this available in our mainline products like RealOne Player and Helix Universal Server.

The headline should be "3GPP Becoming Mobile-Phone Standard", and it's not all that surprising, but it's very good news for everyone (including RealNetworks, where I'm from). We've been doing a lot of work in the 3GPP, and it's great to see that work paying dividends. If you really want to find out what this stuff is about, look at the spec (and yes, I hate the fact that these are Word docs in zipfiles as much as anyone).

Much of the confusion around this subject comes from a lack of understanding of the difference between .mov, .mp4, and .3gp. DoCoMo's announcement was good news for 3GPP, and given the support throughout the Helix platform for 3GPP formats, codecs, and protocols, we view it as great news for the Helix Community.

As another poster pointed out, only a piece of 3GPP is based on Quicktime is the container file format itself (the bit that says "here's a 3000 byte chunk of data with this 32bit codec identifier"). Another piece (the protocol) is based on work RealNetworks pioneered (RTSP). Moreover, the Helix DNA Client supports the 3GPP specification today.

RealNetworks added MPEG-4 and 3GPP support 10 months ago with the RealSystem Mobile Server (see press release),
and MPEG-4 support will be included in the Helix DNA Server when it is released in the near future.

As for the speculation about Apple releasing 3GPP encoding support, we would welcome them to the party. In early November we announced that a version of our Producer product for creating 3GPP content will ship in Q1 of 03. (see press release) Moreover, we offer our encoding framework as open source (and naturally open APIs) so that you can add support for whatever format you want to. We've given you a head start by implementing Ogg Vorbis support.

Again, the new phones sound great. Lots of new devices for Helix encoders and servers to work with.

The headline should be "3GPP Becoming Mobile-Phone Standard", and it's not all that surprising, but it's very good news for everyone (including RealNetworks, where I'm from). We've been doing a lot of work in the 3GPP, and it's great to see that work paying dividends. If you really want to find out what this stuff is about, look at the spec (and yes, I hate the fact that these are Word docs in zipfiles as much as anyone).

Much of the confusion around this subject comes from a lack of understanding of the difference between .mov, .mp4, and .3gp. DoCoMo's announcement was good news for 3GPP, and given the support throughout the Helix platform for 3GPP formats, codecs, and protocols, we view it as great news for the Helix Community.

As another poster pointed out, only a piece of 3GPP is based on Quicktime is the container file format itself (the bit that says "here's a 3000 byte chunk of data with this 32bit codec identifier"). Another piece (the protocol) is based on work RealNetworks pioneered (RTSP). Moreover, the Helix DNA Client supports the 3GPP specification today.

RealNetworks added MPEG-4 and 3GPP support 10 months ago with the RealSystem Mobile Server (see press release),
and MPEG-4 support will be included in the Helix DNA Server when it is released in the near future.

As for the speculation about Apple releasing 3GPP encoding support, we would welcome them to the party. In early November we announced that a version of our Producer product for creating 3GPP content will ship in Q1 of 03. (see press release) Moreover, we offer our encoding framework as open source (and naturally open APIs) so that you can add support for whatever format you want to. We've given you a head start by implementing Ogg Vorbis support.

Again, the new phones sound great. Lots of new devices for Helix encoders and servers to work with.

Visit the Helix Community and download the Helix DNA Binaries.
This pack comes with an application called HelixPlay. This player is crappy and not very user friendly, but it's small (~2MB compressed; ~5MB expanded) and has no spy ware. It's enough to view RealVideos, if you have to.

• Helix DNA Client Documentation
• Helix DNA Producer Documentation