Moderator (MDR): MDR-Andrea
Guest Speaker (SPK): SPK-ivan
MDR-Andrea: Hello and welcome to Java Live. Today we will be talking about the JavaTM Media Framework. Our guest is Ivan Wong, project lead for the JMF. Perhaps you've had a chance to look at the JMF 1.0 Beta (available on the JDC web site—Early Access) and have questions. Go ahead and start sending them in.
scsulliv: Can you explain the purpose of the MediaProxy?
SPK-ivan: In short, the MediaProxy is used as an intermediate step during the creation of a JMF player. In general, the intent is to use a URL to fully identify a media (protocol, mime type). So Manager.createPlayer(URL) will work. But in some cases, the media type cannot be fully described by a static URL. That's when a MediaProxy can be used. The MediaProxy could be used as an intermediate to query info about the media, e.g. reading from an out-of-band network connection to fully identify the media type before a Player is instantiated.
srp: Are there plans to allow recording of data (voice from a microphone, for example) that the JMF can use?
SPK-ivan: The current version of JMF does not yet support capturing from a device (e.g. microphone). We are definitely looking at that right now. We'll mostly likely include microphone support in Java Sound, the sound engine JMF is using.
steelman: I understand that getAudioClip is becoming static, so as not to require an instanstiated applet for sound. But is there anything more than existing applet audio manipulation via AudioClip which is limited to loop(), play(), stop()?
SPK-ivan: Yes and no, JMF uses Java Sound internally to provide a much richer API than AudioClip. But that will not be exposed yet, as a public API. We are currently refining that API, so it could become public in a future release of JDK.
steelman: Is the HeadSpace audio format supported?
SPK-ivan: Yes. RMF is supported.
netjunki: Does the version of JMF available on the website work on the SGI?
SPK-ivan: No. But SGI has a version of JMF implementation for JMF spec 0.93 (I think). Please check their web site for more info.
netjunki: The version on their site is for JMF spec 0.96. But the two versions are different. Do you know when/if a new version will be released for SGI?
SPK-ivan: Thank you for your correction. SGI annouced about a month ago that they are putting a indefinite delay on their development effort on JMF to concentrate on core Java (VM) technologies.
winzeler: Has there been example code developed to demonstrate MediaProxy? Perhaps in the new 1.0 beta?
SPK-ivan: We use MediaProxy internally in JMF beta to create players for RTP. The initial URL indentifies a session address, which we use to produce an RTP session manager as a MediaProxy. That in turn creates a player to playback the streams from the RTP session. Check our docs on the RTP Player for more info.
robHanna: Is this to compete with, and dare I mention competition realVideo, or is it for use on local applications?
SPK-ivan: JMF as it stands today is only for media playback. So we definitely can't compete with RealNetwork on the server side. ;-) On the client side, there is actually a lot we can do together with them. We did a trial test a couple months ago to use our JMF players to interoperate with other company's streaming servers (RTSP based), FYI.
jmax: What sort of support for a microphone are you talking about?
SPK-ivan: Capturing from a device in general. Microphone is an example.
winzeler: When will the JMF spec. settle on media formats?
SPK-ivan: JMF 1.1, hopefully! :)
srp: It's good to hear that you're adding capturing from a microphone—that's less native code we have to maintain! :-)
You have GSM decoding, but what about GSM encoding? We've got Java code that can do GSM decoding for our application, but I'd rather switch to use JMF fully, so we'd like to have the GSM encoder (or anything better, like RMF).
SPK-ivan: We also support GSM decoding for JMF beta 1.0. Encoding, together with capturing from a device is next (high priority) on our list.
scsulliv: Is there any publicly available source code that shows how to implement a PushDataSource?
SPK-ivan: I'm not aware of that. Internally we use PushDataSource for our RTP Player. Other than that, we are also exploring writing PushDataSources of streaming media (MPEG) types of applications. I'll see if we can ship some sample DataSources with our next release.
kdlitwak: This description of the JMF proxy sounds a lot like the description I read yesterday of the Java Activation Framework for recognizing and responding to media types. What would be the difference, and how might they work together?
SPK-ivan: Sorry, I'm not familiar with Java Activation Framework.
jmax: Is there a time frame for the Java Sound API? How can we as developers get in on the process?
SPK-ivan: THe API probably won't make it into the next major relase of the JDK. Just like other public APIs there'll be licensee review process prior to releasing it.
jmax: We've been working with the JMF for a while now, in the Early Access program, and so far we're quite pleased with the implementation.
SPK-ivan: Thanks, jmax. Glad to hear that.
scsulliv: Do you have plans to package the com.sun.media.PlayerBean separately from the javax.media classes? Will it be freely available?
SPK-ivan: That sounds like a good suggestion. Thanks. We'll see.
winzeler: Will you be publishing a transcript of these discussions in case we have to step away?
MDR-Andrea: Yes, the transcripts are available on the JDC site, in the Discussion Forums section. It will be ready in the next few days.
scsulliv: Can I assume that the object returned by Player.getVisualComponent is serializable? Shouldn't I be worried that getVisualComponent might be an instance of a platform-dependent class? Is it advisable to store the visual component in a transient variable?
SPK-ivan: Good observations. In fact, the Player Bean currently internally includes a transient player object. The Bean itself is made Externalizable and we save only the states of the player and restore it on the fly by creating a new player object.
scsulliv: I've implemented my own Handler class to handle a proprietary media file format. During implementation, I found it extremely difficult to implement the entire Player interface. Are you planning to add any support classes to JMF that will make it easier for developers to implement custom Handler classes?
SPK-ivan: Very much so. Internally we use a few basic utility classes to build every one of the players. We realize it will benefit our customers if we can expose those classes (we have been asked by some other partners as well).
scsulliv: Are you going to release source code for your Player Bean? I would like to understand how you handled the serialization issues via Externalizable.
SPK-ivan: Another good suggestion. We'll see.
jmax: Does that mean that you've created a Real Player in the JMF?
SPK-ivan: Not really. The trial test with Real network was done with RTSP, RTP with motion JPEG, H.261 and ulaw audio.
steelman: This may not be coverted by JMF, but what about support for a standard like TIFF G4?
SPK-ivan: We haven't looked into that. But that's exactly why JMF is designed to be extendable. We can't imagine covering all media formats possible.
jmax: Is anyone looking at impelemting SMIL with the JMF?
SPK-ivan: Not that I know of.
winzeler: Did they (Headspace) blind you with science?
SPK-ivan: Huh? :)
MDR-Andrea: Not yet. :-)
jmax: What behind the decision to make the JMF javax instead of a core API?
SPK-ivan: The size of the package (footprint) is one.
MDR-Andrea: As it is noon, Ivan is going to work his way through the six questions remaining in the queue.
jmax: How about SMPTE time code support built directly into the JMF?
SPK-ivan: The Time object can be extended to support SMPTE. We don't have plans to put it in yet. You can certainly extend that and use it with JMF player, as long as the proper conversion to nanoseconds in performed in your class.
scsulliv: Can I safely use the classes in com.sun.media without losing portability? Or are the classes "off limits" like the sun.* packages in the JDK?
SPK-ivan: No. javax.media.* is public API while com.sun.media.* is Sun only. We are working to make some of those utility classes public, as I mentioned before.
dbryson: What is the plan for JMF and the rest of the announced APIs? Will they become standard parts of Java (i.e. like java.io.*, etc.) or are they intended as addons that the various licensees can choose to implement or not? Will distributable implementations be made available by Sun?
SPK-ivan: As it stands right now, javax.media is an extension. So no, licensees are not required to implement it. We certainly hope that they will.
steelman: I thought I saw a reference to some part of JMF using Microsoft's DirectX somewhere in the JMF materials. Is that right?
SPK-ivan: Yes, we use DirectDraw for video rendering on Windows. We also use ActiveMovie's MPEG decoder to playback MPEG. Otherwise, much of the code is Java and portable C/C++ code.
winzeler: Will the default ControlPanelComponent ever have a specification or minimal requirements in the spec? Implementing a full custom GUI is not entirely trivial. Will Sun/partners release utility classes that allow developers to define the GUI look and feel?
SPK-ivan: There is no specification on what the ControlComponent looks like. And yes, we are looking into providing our GUI utility classes as support classes for our customers' use.
Thanks for all great questions. If you have further comments, please feel free to send it to jmf-beta@sun.com. We'd like to hear what you use JMF for. The more feedback, the better JMF will become. You all know that, right? :)
MDR-Andrea: Thanks, everyone, for joining Java Live today—especially Ivan. This transcript will be available in the next few days on the JDC web site in the Discussion Forums section. Thanks for all of your questions, comments, and suggestions. See you in two weeks! Check the Discussion Forum schedule for more details.
