Chet Haase's Blog

Media Frenzy

Java Media Components

or

Making Java a Player

The question comes up regularly, and on a more frequent and random basis lately, "What is Sun doing about media support in Java?" And sometimes it is not phrased quite so politely.

Video used to be a feature that we lacked:

Now, it seems sometimes that it is the feature that we lack:

In the current world of YouTube, Flash, and iTunes, video has gone from a niche capability to a checkbox item that all platforms must support.

So what are we doing about it, besides pointing out the obvious issue that it isn't there now?

If you attended the Java Technology Desktop overview session at JavaOne this year, you learned, along 500+ of your closest friends in the room, that we're working on a new project that we call Java Media Components(JMC). This new feature, hopefully shipping in Java SE 7, is intended to support basic playback support for Java applications. JMC is also, eventually, intended to address capture and streaming capabilities.

Playing Fair

There are actually two levels of playback that we would like to support:

• Native players
• Java player

Going Native

The native players on most platforms have substantial support for multiple video formats. It would not make sense (read: it would cost serious $$$) for Java to implement players for some of these existing formats. So why not leverage the native platform capabilities instead?

The idea is to expose a simple API for playback control (e.g., play, stop, and rewind), and to allow a Java application to thus control playback of specified content through whatever was available on the native system. For example, playback of an AVI file on Windows might launch Windows Media Player. Moreover, the native player would be exposed through a GUI component that you could integrate into the rest of your application's interface. There would also, depending on the underlying native support, be options to either expose the native controls for the player (e.g., the Play button), or to allow the developer to skin their own controls around the player component.

This native-wrapper functionality is the easiest part of the whole JMC project. The main work is in the simple API design and the glue code to the various players on different platforms. In fact, we already have prototypes of this working for several players, including Windows Media Player and Flash.

Curious readers familiar with lightweight/heavyweight mixing issues in Swing applications might wonder at this point how we will deal with a native player component in a Swing GUI. Good question, thanks for asking. This issue is one of the reasons that we also plan to support mixed heavyweight/lightweight components in Java SE 7. In case I don't write a blog on this feature soon, here's the quick scoop: We can enable this through clipping the heavyweight components against the shapes of the overlaying lightweight components. There are some cases that do not yet work with this mechanism, such as shaped and translucent lightweights, but the system works pretty well in general for other cases.

Playing Nice with Java

Supporting common formats through the native player mechanism will solve a key part of the problem. The ability for a Java application to easily play video that resides on a user's local system through a standard local player is an important case that will be handled through this simple mechanism.

But native player support is not a complete solution. For one thing, if a developer wants a specific video to play through the application, they will have to ensure that the video is available in whatever formats will be supported on all of their users' native platforms. For example, a Quicktime movie would not be playable on Windows unless Quicktime happened to be installed on that system. Similarly, an AVI file may not have much luck playing on Linux.

To solve this problem, we need one common format, and an accompanying codec (coder-decoder), so that any Java application can count on being able to play back any content in that format, regardless of the runtime platform.

This cross-platform format support is a much more involved issue, since it immediately gets into harder issues of:

• Licensing technology from existing player developers, and/or
• Creating or integrating new technology into the platform

We plan to tackle this part of the JMC project after the native players are well in hand. Meanwhile, we are trying to figure out the right solution (which formats, which technologies, etc.).

Playback versus Pixel Access

There is an important consideration in both the native and Java player solutions above: How much do players need to simply display their pixels on the screen, and how much do they need to actually expose the raw pixel data? To a great extent, simply playing on the screen is probably good enough. If an application just wants to play a video, then blasting it to the user's screen is fine. But there are subtle cases here that make the issue a bit more complicated.

For example, what if you wanted to do something more interesting with the video content, like play it on a lightweight Swing widget? Remember that I said that we plan to allow mixing of heavyweight and lightweight components, which should allow a JMC player to at least cooperate with Swing widgets. But that's not the same as a JMC component actually being a Swing component. For example, what if you want to use the video as the icon in a JButton? Or what if you want the video playing in a translucent component? Or what if you want to get really crazy and display video in a 3D object, via JOGL?

For any of these cases where you want to do anything with the pixels besides simply show them on the screen, you will need access to the pixel data from the video stream. Many of the native players do not offer this capability, but merely allow the controls of playing, rewinding, and stopping the video. Some native systems, such as DirectShow, do allow more flexibility, so we plan to use these approaches when we can. And the Java Player will certainly allow this capability. Since we will provide the decoder for the video through the Java player, we can have those pixels appear on the screen, or in an image, or wherever the application specifies.

What about Capture and Streaming?

Capturing video from an input device and streaming between Java clients are two areas that we would also like to support eventually. Having the Java player is actually a good initial step toward these capabilities, since we will be able to encode and decode into our cross-platform format. But we are taking baby steps here, and feel that the top priority is solid playback support. We would like to get rolling on that playback project first before we take on even more, and harder, issues.

What about Java Media Framework (JMF)?

JMF is an existing media library, provided as an optional package on top of Java SE. JMF is a very large and powerful media development platform that is capable of doing much more than I've discussed here. In particular, while it's possible to write a complete video editing solution in JMF, we are clearly going nowhere near that level of functionality with the JMC project, but rather focusing squarely on playback at first. Again, we are concentrating on attacking the pain points in our existing video support (or lack thereof), and we feel that playback is simply much more in demand than full-on video editing APIs.

One solution here might be to simply revamp our investment in and support of JMF itself, and make it the platform for future video endeavours. However, the level of effort that we would need to invest to bring JMF up to the current level of requirements, including providing codecs for modern formats, would be huge. Also, at about a 2 Megabyte download size now, we're not sure that simply adding in the current JMF to the core platform is the right approach. It seems better to solve the top priority of simple playback by a targeted solution that is possible with a much smaller footprint impact.

We may actually implement parts of the JMC stack on portions of JMF, which would give us the advantage of re-use of some of JMFs capabilities without taking on the entire library. Also, work on codecs for JMC could end up also benefitting the JMF library eventually in any case.

That's the Plan

Plans change, of course, but this writeup represents what we would like to see happen in Java SE 7. Does it sound reasonable to you? Would having simple playback functionality, through both native players and a new Java player, satisfy your craving for media in Java? And if we spin up a new project on SwingLabs soon, would you be interested in helping out in the design and implementation of these pieces?

Comments

• Well, it's certainly a start and much, much, much better than nothing. I hope people (not necessarily Sun, but Sun backing always helps) will eventually "finish" the job and give control over the pieces that will be lacking to JMC... but it's a big improvement over the current situation.

  Thanks for the info and taking the initiative, Chet.

  Rob

  Posted by: reden on May 24, 2007 at 11:51 AM

• This is great news!
  BTW quicktime (even QTJ) supports access to pixel information too (not just direct show) although this functionality is far from obvious (hint: observable image...).
  Ideally the native player layer would be at least partially pluggable so we can write native code for a player on Linux (such as mplayer) and have it work seamlessly with the API. But I'm sure you know we want that ;-)
  It wasn't clear from your post though, if this is a Java 7 feature or if its external to the Java release cycle? (you mentioned the heavyweight fix but thats not essential for working with the API) When can we expect this API? Will it have a Java.net project/JSR?

  Posted by: vprise on May 24, 2007 at 01:05 PM

• It’s good news that at least SUN is working for a solution. Thanks for the information so that I know that I’ll have to go with native solutions since it sounds like that it’ll probably take two years for JMC to have video capture functionality.

  Posted by: jdevp2 on May 24, 2007 at 01:09 PM

• You should check out the very interesting ideas of Chris Adamson here very interesting ideas of Chris Adamson here and some of the comments below the article.

  Posted by: mosabua on May 24, 2007 at 01:13 PM

• 
  mosabua: Yep, it's a good posting. In fact, it was Chris's blog that prompted the timing of mine. We were talking about getting this info out in the open soon anyway, but that discussion was a nice catalyst... I'd like to link from the comments there back to here to make sure that comment readers see what we're thinking.

  
  jdevp2: I guess I wasn't clear enough about this, but the JMC feature is planned for the SE 7 release. The hw/lw mixing feature, as you mention, isn't tied to API changes; I could see that feature getting out there earlier, with enough testing. But the JMC stuff certainly is new API, so it'll have to be intro'd in a major release. Meanwhile, we hope to have a SwingLabs project going so that people can play with the project as it develops.
  

  Posted by: chet on May 24, 2007 at 01:19 PM

• OK chet we have you on the record, you just promised to solve the hw/lw issue before Java 7. I'll bookmark this post ! :-)

  Posted by: augusto on May 24, 2007 at 01:25 PM

• Augusto: I, uh, I, uh ... Actually, we did consider putting the fix into the Consumer JRE, but if you read that post, you'll know how tight and critical the timeframe is, so we opted (for basic testing/risk/priority) reasons to not rush it into there. We'll see if it can hit an update after that. So you can put my "well, maybe!" on record...

  Posted by: chet on May 24, 2007 at 01:27 PM

• Chet, its good news that Sun is doing this and going the native-binding way seems like the obvious choice.

  One thing I don't get, however, is what's taking so long. A month ago, I got so terribly frustrated with the lack of Firewire capture support that I whipped up a wrapper for Unicap in about three days, and that time included doing quite a few things that are already in JMF (like YUV decoding). Granted, that thing was awfully limited, is pretty slow, only works in UNIX, and whatnot, so its absolutely not comparable to doing this on a production scale, but still, three days! Surely, it must be possible for you guys to come up with something good that satisfies the basic things, across the fold (i.e. including capture and pixel-level access) and put that into the basic JDK.

  Or otherwise, it would be interesting to hear what the issues are. I'm sure people like FOBS (ffmpeg-JMF) and the FMJ crowd would be willing to help out putting a reference implementation for a simple, basic JSR together. Work with the community here!

  Posted by: iluetkeb on May 24, 2007 at 01:28 PM

• It looks as if minds are oriented to build media abstractions lately, a quite interessing thing to look at is the media framework that will be included in the next version of KDE 4.
  This framework, called Phonon is made to offer common media abilities to developpers, but do not provide the backend implementation. Their way of doing things is to leave to other developpers to write the specific backends they need to make the API work.

  Moreover, KDE 4 is intended to work over multiple platforms as Windows, MacOs, Linux, BSD's and others Unixes.

  At the moment KDE 4 has already reached the stage of Alpha versions, and is running, with phonon included, and at least a backend for linux.

  This could be a direction to look after, and moreover, they are under GPL, their code is object oriented (C++) and their will probably offer java bindings (but I dunno to wich extend)

  It's always a good thing to look what's going up around.
  

  Posted by: sinok on May 24, 2007 at 03:41 PM

• Oh by the way, I forgot the links

  KDE

  
  Phonon

  Posted by: sinok on May 24, 2007 at 03:46 PM

• looking forward to it!

  Posted by: surfer66 on May 24, 2007 at 05:08 PM

• Great news that sun is finally doing something in this area!

  I started the gstreamer-java project (http://code.google.com/p/gstreamer-java/) as a way to get video playing in a JComponent with a simple-ish API. I haven't done a video-playing-in-a-button demo yet, but it should be pretty easy. I should also be able to easily prototype the JMC APi when you guys get a draft out.

  btw, from doing that project, one of the things that would be nice would be an easier way to get pixels from say a direct ByteBuffer into a VolatileImage, without having to copy through java first - and without the complexity/added dependencies of using OpenGL.
  

  Posted by: wmeissner on May 24, 2007 at 06:57 PM

• > we are trying to figure out the right solution (which formats, which technologies, etc.).
  Please pick up the phone and call On2. Ask them about VP6 and VP7. You can also watch some video examples on their site. BTW VP& is the video codec into Flash. VP7 is even better.

  http://www.on2.com/

  Their codec is propietary the licensing terms are very flexible. Sun can probably get a good deal (like Adobe)
  

  Posted by: imjames on May 24, 2007 at 11:50 PM

• Gstreamer [1] might be an interesting project for you. It's aim is to be cross platform, it has a nice architecture and is very binding-friendly. As for the video format, ogg vorbis / theora are a pair of modern codecs, they are free, and there exists already a pure java implementation (afaik GPL) [2].

  [1] http://www.gstreamer.net/
  [2] http://www.fluendo.com/products.php?product=applet

  Posted by: gnagy on May 25, 2007 at 05:20 AM

• Did you look at the media APIs in J2ME? Perhaps binding those APIs to existing desktop media players would give a richer set of APIs than JMC with much less resources than bringing JMF back from the dead.

  Posted by: desperado on May 25, 2007 at 05:21 AM

• Chet,

  What you suggest is much more complicated than the way Flash does it... and I have to ask why. I'd assert that Flash is the competition here. I would humbly suggest, then, that first, Java needs to catch up with Flash... then it can overtake.

  Digital video is, in general, in a nightmare. All the different proprietary formats that are around mean that even integrating with "native" players on people's computers is never going to be a great solution. You need multiple of different pieces of software in order to guarantee that you can encode/decode different formats correctly. And that might vary from computer to computer. My suggestion for Java would be to side-step these issues...

  Fingers crossed, the Consumer JRE work you are doing will be successful. That would mean Java applets will, for the first time ever, really be worth developing. In that case, what developers could really use isn't a pretty much doomed attempt to support all codecs (having an app work 90% of the time isn't really good enough). Rather, what I think they need is great support for just a single, open codec, built into the Consumer JRE, such that they can guarantee that video they want to serve will play correctly. Support for other codecs - both in Java and from native players - would be icing on the cake in my book.

  More on my blog - The Consumer JRE And Open Source Video Streaming

  
  What I really like about my solution is that it's so simple, and quick, to implement. It would, I think, bring the key capability to Java that enabled Flash to become so dominant with video on the web. Except... this Java solution would have the benefit that everything would be based on open formats (as opposed to the proprietary FLV format that Flash uses).

  Best,

  Simon
  

  Posted by: psynixis on May 25, 2007 at 05:39 AM

• I would have to agree wholeheartedly with Simon's blog, there is already an ogg theora applet working and running right now.

  It looks like it would be trivial to integrate with JavaFX. This would make FX a real contender in the RIA space that it is being targeted for.

  This is low hanging fruit, tackle this first, then tackle the more complex areas of a full media framework for Java.

  I know that if the Consumer JRE improves startup times as promised, and FX has video capabilities, then our company would seriously consider replacing flash with FX in our web applications.

  Now if only there were a tool such as Flash Designer.. :)

  Posted by: kedaly on May 25, 2007 at 06:44 AM

• Why not target vlc, that player can be used on most platforms...

  http://www.videolan.org/vlc/

  Posted by: francisdb on May 25, 2007 at 10:11 AM

• I also agree with Simon. One needs to watch out here, the JDK is open source now. Wouldn't linking the VM to a proprietary codec implementation violate the GPL? I know right now we are stuck with a few situations like that currently, but the goal has always been to remove those dependencies right? Why add more?

  I like the idea of having a standard codec for Java. We all know that trying to figure out what the user has installed is a chaotic mess. It also places the responsibility on the user to have everything set up right. As the list of dependencies goes up the chance for a problem increases.

  Java 1.7 installed?
  check.
  QuickTime 9.99
  check
  Windows Media Player 14.12
  error

  
  When you build/use a standard codec for java you place the responsibility on the content DEVELOPER. Process exist for validating that the developer created something that works. One cannot test every combination of every version of every codec of every platform where someone might want to open a video file.

  If the codec is free, and tools exist to convert existing files into this codec then content developers will be happy.

  If the solution "just works" then content consumers will be happy.

  As you said building a complete video editing solution is the job of JMF. For everything else I would think a standard codec for Java would go a long way to achieving the effect you want.

  Posted by: aberrant on May 25, 2007 at 10:59 AM

• Totally agree on the last posts. I would also focus first on having a 100% java codec / player setup. Content should be converted, but it would run anywhere and put someleverage on JavaFX. And it would play nice with ConsumerJRE. Just my opinion.

  Posted by: tbee on May 25, 2007 at 11:21 PM

• I have to agree with gnagy about the ogg vobis/ theora codec. It is GPL'd and has an already available java implementation. This seems like the most logical choice for the cross platform java codec. I also agree with francisdb about targeting the vlc player for the native implementation as there is already a java wrapper for it at http://trac.videolan.org/jvlc/. This link might be worth taking a look at!

  Posted by: badapple on May 26, 2007 at 04:46 AM

• We still lack "World Peace" too.

  Posted by: enygmata on May 26, 2007 at 04:12 PM

• Typical Sun move.

  
  First doing a half-arsed Job (JMF). Then letting it rot away. Then, instead of finally fixing things, dropping it, and replacing parts of it by another half-arsed job (JMC).

  My prediction: The initial JMC version will be full of bugs and unusable, beyond running the included demo code. It will get one maintenance release. After that 50% to 70% of JMC will work, for some value of "work". Then Sun will let it rot. During that time Sun will lament why JMC doesn't take over the world, ignoring all criticism and requests for finally getting the dammed thing fixed.

  Then, after the thing is dead for all practical accounts, Sun will pretend to wake up, provide once again lip-service how important Java media is, and announce yet another media API.

  JMC? Nothing to see here. Move along.
  

  Posted by: ewin on May 27, 2007 at 03:12 AM

• ewin makes some good points.

  Personally, I'd like to see Sun continue to invest in - and improve - the existing JMF.

  Posted by: sprhodes on May 27, 2007 at 11:55 AM

• A standard codec is a very compelling idea and the success of Flash proves how well that can work. Start there, then add the other Flash features like simple audio and video capture that "just works".

  I can see why the native integration idea you talk about seems interesting, but to me it just sounds like a huge PITA from a testing perspective. If the pure Java approach is reasonable, we'd basically always choose to use that.

  To be honest, JMC is going to have to be pretty compelling. We're in the same boat as many others seem to be: we made a deep investment in JMF that was ultimately very frustrating and are now moving onto other solutions like Flash and native libs.

  Posted by: mattjive on May 27, 2007 at 06:00 PM

• I agree with ewin.
  Fix JMF... if possible make a light-weight version that includes only a single Java codec. (The OGG stuff seem like a good place to start).
  There is so much broken in JMF that needs fixing and the overlap with the proposed JMC is nearly 100%.
  We don't need or want yet another media API. JMF has some great ideas and beginnings... if only it worked it would be a very good media API.

  Posted by: swpalmer on May 28, 2007 at 07:49 AM

• Playback isn't everything. As cortado (the theora applet) has shown, playback can even be done just fine with the current JVM. What Flash has over Java-as-delivered at the moment is capture on all platforms. Think video-conferencing. Or just getting that darn video into the box in the first place ;-) For that, native code is an absolute necessity because you need to access the hardware.

  Posted by: iluetkeb on May 29, 2007 at 12:51 AM

• I want to lend my voice to others here: start with a Java format, then look into native stuff if people want it. I don't want native, and I'll never use native. The simple reason is that native destroys "write once, run anywhere" - and, at that point, why go with Java at all? I'll just move on to a better tool with more mature media capabilities. If I want to embed video in my apps, I want to use one format that works everywhere, and I don't care what the format is as long as you give me a way to convert into that format. This shouldn't be hard, just go with Ogg or something similar. The hardest part will be the licensing, as there are already 100% Java Ogg players. See if you can partner with someone who has such a player.

  If you go down this path, you will make a two fold mistake: 1) everyone wants a Java format. If you do native support first, we will find it interesting, but not useful. So, we have made no progress, which leads us to 2) This is a mistake because it is tied to Java releases. First, we wait for 1.7 for the useless video, then we have to wait again for 1.8 before we get something we can use. This means that we will have to wait years before we get the Java video solution, and by then, Java will have lost the media war so badly it won't matter anymore.

  Posted by: adepue on May 29, 2007 at 09:17 AM

• I agree that Playback is the most fundamental feature that needs to be added to the standard JRE so that it can be generically leveraged, but the real question is playback of what?

  The only solution that allows one file to be recorded and then played back anywhere is to use the one common format approach. As pointed out in almost every reply this is how Flash has become to dominate the market, but its also where Java can regain the lead.

  Although the idea to playback OS specifc formats through one API is cool and has its benefits its not the silver bullet that being able to playback one file on any system is.

  Posted by: cfoushee on May 29, 2007 at 01:02 PM

• Good that media is being taken seriously, hopefully for real this time. Here are my thoughts, directed at the post, and to Sun:

  YES we need a simplified player API. (FMJ and ION have wrapped native players in the manner you describe - FMJ uses the JMF API, not sure what ION uses)
  YES we need a low level capture API. (lti-civil does this, but I'd be just as happy if JMC created a Sun-supported one)
  The APIs should be orthogonal in a sense to JMF - it should be possible to implement parts of JMF using them, and possible to implement them using JMF
  NO - nothing should go into the JRE until it is mature, slim, and cross-platform (like Java sockets, Javasound). So the wrap some players on some platforms and support some codecs somewhere - I see this as very useful, but not JRE-worthy the way you describe it.
  Priorities - the single codec that runs everywhere should be the first thing you described that should go into the JRE, and IMO it should be higher priority than the wrapping of native players. Without it, JavaFX is crippled.
  PLEASE open-source the non-patent-encumbered parts of JMF. If it is doomed to be abandonware, why not let the community turn it into something that works. It would sure make the FMJ project easier...

  
  Ken Larson, lti-civil and FMJ admin

  Posted by: kenlars99 on May 30, 2007 at 02:07 PM

• Absolutely the number priority is a codec that works across all platorms without any proprietary software loads. Because my current suite of videos are all MOV-Cinepak, I must have a easy way to transcode into the new, platform-independent format. I've yet to locate the Ogg-theory solution to this problem, although I suspect that this capability will precede Sun's product. VLC doesn't work for me on my computer.

  A new project (JMC) makes little sense when the existing JMF works most of the time. Layer a simpler api on top of it if you must. Subset it. Massage it. Don't start from scratch again with a project that will take forever to complete.

  I don't care about capture, but understand that others do.

  Posted by: hekeller on June 02, 2007 at 10:25 AM

• I think that the priority should be a come up with a "Java Codec" people want to integrate video in their applications in a WORA way,
  if somebody just want to play videos from the local machine, there are plenty of native video players

  Cheers
  JD

  Posted by: jdavi on June 11, 2007 at 04:55 AM

• So in conclusion, Adobe need not fear a Java video editing application being capable of replacing Adobe Premiere (Elements) for so some time.

  
  Sorry to be a bit of a damb squib (slightly disappointed)

  
  I agree there should be two capabilities, however. First to be able to play back video streams. Second to be able to get at pixel (otherwise how else could you code video transition).

  
  There are a couple of other fundamental requirements.

  
  USB and Firewire connectivity in Java. (How else can you capture the video or music )
  How do you record or capture video
  This sort of thing should not be done by a JVM. Delegate the rendering algorithm accelerated hardware or native code
  Look at the reasons why a Cubase or Resound cannot be done in Java: The latency issues.
  In the spirit of JRE modularisation, aim to modularise the new media capabilities from the beginning.

  
  

  Posted by: peter_pilgrim on June 12, 2007 at 02:35 AM

• I've covered this on InfoQ here: http://www.infoq.com/news/2007/06/java-media-components

  It's interesting to see the spectrum of how people are reacting to this.

  Posted by: diathesis on June 13, 2007 at 06:55 AM

• The first thing is to a produce a player to play mp3, wmf, avi, wav, qt, and, possibly, flash formats.

  Azlan

  Posted by: azlan95 on August 22, 2007 at 11:08 PM

• I've been watching this project for a while, but haven't seen any updates on whether this is really in the works and when it (or a beta) will be ready. Could you update this page with the current progress or at least confirmation that this project is still planned for the Java 7 release? I'm very much hoping to use this much-awaited new java language feature to support media cross-platform, rather than being forced to use Quicktime, which is both difficult to integrate and limited to Windows/Mac.

  Posted by: tpischke on September 17, 2007 at 05:00 AM

• >>One solution here might be to simply revamp our investment in and support of JMF itself,

  Why not reactivate JMF and refactor it (divide and conquer) into a number of JMF-Subsystems, the first could be JMF-PB (play back).

  Surely stepwise refinement (evolution) is better that revolution.

  It is not only Sun that have invested a lot in JMF but all of the Java community who used and are still using JMF(currently there is nothing else really available). I am very annoyed that Sun not only forces me to throw away all of my investment in JMF and learn a new API but also to wait god knows how long until things like video capture are supported (if it ever is)!

  3 steps backward for a promise of 1 step forward in JRE7.0 and a hope of a second step sometime in the (distant?) future does not seem a good compromise to me!

  Dave
  

  Posted by: dmgaskin on September 18, 2007 at 03:15 AM

• As far as revamping JMF, don't forget about FMJ, which is attempting to do that.

  http://fmj-sf.net

  Posted by: kenlars99 on October 18, 2007 at 12:44 PM

• Okay. Great to see so much focus again on media players and capture. I spent quite some time getting QTJ to work in an MDI and after finding out Apple is killing that off I found my on solution and included it into MyUniportal.

  Check it out! no quicktime or windows media player install needed!

  http://www.myuniportal.com

  Have fun!

  -Tony

  Posted by: tdanecito on November 03, 2007 at 02:28 PM

This work is licensed under a Creative Commons License.