请问用java如何播放rm文件?

petpig 2003-08-31 12:03:46
如题,谢谢
...全文
42 19 打赏 收藏 转发到动态 举报
写回复
用AI写文章
19 条回复
切换为时间正序
请发表友善的回复…
发表回复
ralihm 2003-09-03
  • 打赏
  • 举报
回复
up
sohu98 2003-09-03
  • 打赏
  • 举报
回复
这个很有用

能不能把具体的连接贴上来
sohu98 2003-09-01
  • 打赏
  • 举报
回复
再up
DavidBone 2003-09-01
  • 打赏
  • 举报
回复
我会,这个问题我想了1天,哈哈
郁闷中,只谈技术同美食
computersim 2003-09-01
  • 打赏
  • 举报
回复
Choosing a Streaming Video Technology

How QuickTime, RealVideo, and Windows Media stack up.
Barely four years old, streaming Web video has gone from a mosh pit of scrappy startups looking for attention, to a battleground of multibillion-dollar companies. With broadcast-quality desktop video poised to transform the computing and home entertainment industries, the potential benefits to controlling one of the underlying technologies are huge.

There are three main candidates for streaming video leadership: Apple QuickTime, RealNetworks RealPlayer/G2 Server, and Microsoft Windows Media technology. All claim various advantages over the others. We're going to strip away the hype and contrast the core features of each to help you make intelligent decisions about what and how to implement.

A few quick definitions. There is some vagueness in the industry about what counts as "streaming media." Some argue that only content that's streamed realtime through UDP (a different protocol than the Web standard HTTP) is really streaming. Others use the term to refer to any video that plays on the Web. Because most users aren't aware of the difference, we're going to discuss both here, calling the UDP flavor true streaming and the HTTP kind progres-
sive download.

The biggest difference is that true streaming only works when there's enough bandwidth to play the video in realtime. Progressive download transfers at the available speed, downloading as much of the
file to your disk as necessary to act as a buffer before playback begins. Progressive download can ensure high-quality playback at any bandwidth, but potentially with a very long delay.

Complicating matters is that all three technologies also do a hybrid strategy: realtime streaming via HTTP if a firewall isn't able to pass UDP data.

Real


RealVideo, from RealNetworks, is another pioneering Web streaming format. RealAudio came out in 1994; RealVideo was added with Version 4.0 in 1997. Real has just introduced Version 7.0, an incremental, but substantial, upgrade from the major improvements of G2 in 1999. Its big changes are better decoding performance, improved encoding technologies, and a full player makeover.

The native file format for RealMedia is a RealMedia file, or .rm. You'll also see .ram files, which tell the player where on the server to find the .rm data.



Windows Media


Windows Media, formerly known as NetShow, is Microsoft's entry into the streaming Web video market. The newest of the three, Microsoft is pushing it hard as only it can. Windows Media is a much simpler solution than either QuickTime or Real because Microsoft doesn't position it as a complete platform, but rather the streaming audio and video component of a Web browser. However, it does what it does quite well. Recent innovation has focused on codec improvement and implementation of pay-per-view and authentication features through the Windows Media Rights Manager.

The native file format of Window Media is the Advanced Streaming Format, or .asf.



VIDEO CODECS


Video codecs are probably the single most important factor in determining what makes a great video technology. Bandwidth on the Web is still quite limited, and trying to get high quality video to a consumer is like shoving an elephant through a swizzle stick. To go from uncompressed video to a 28.8kbps modem bitrate requires about 12,000:1 compression! The bang-for-the-bit of a video codec is obviously critical to the user viewing experience. Universal broadband will ease this situation someday, but for the foreseeable future, we need great codecs to help squeeze that elephant through.
computersim 2003-09-01
  • 打赏
  • 举报
回复
Java Media Development with QuickTime for Java

In this first part, we'll consider how JMF's design leaves the door open to improve its capabilities. In the second part, we'll get into the details of QuickTime for Java to deliver more media support.

Opening up Java Media Framework
To handle a given piece of digital media, an application has to know how to handle the following:

Format — how the contents are arranged in a file or network stream.
Multiplexing — how multiple media streams are put mixed together into a single byte-stream. While it might be convenient to write all the video data to a file and then all the audio, the resulting file could be difficult or impossible to play at a consistent speed, so you "multiplex," or interleave, the streams together, putting the pieces of each stream that represent the same time close to one another.
Encoding — how the media is encoded and (usually) compressed.
Rendering — how to present the decoded/decompressed data to the screen, speakers, etc.
Source Code

Download the source code for this article.

Sun's JMF implementation comes with classes that can only handle a handful of the possible formats and codecs you're likely to encounter on the Web. According to the supported media types page, the most popular video formats JMF supports in its all-Java version are the deprecated AVI format and QuickTime's .mov file format ... not Windows Media WMA and WMV, or RealMedia .rm formats. And just because a format is supported doesn't mean a given clip in that format will play. For example, JMF can't handle DivX AVIs or QuickTime files that use the popular Sorenson video codecs.

Extending JMF
The good news is that you're not stuck with this modest media support, thanks to the plug-in architecture. The design of JMF allows it to decide at runtime what code to use to handle a given format, multiplex scheme, and encoding. It does this by carefully parceling out responsibility for format handling, demultiplexing, decoding, and rendering into different classes, then using reflection to discover what kinds of handlers are available.

Extending JMF often means writing new DataSources and/or Players or Processors. A DataSource represents both the media's organization and access to it. In other words, you'd look to a DataSource to determine the media's content type and to open a stream to the media. A Player represents the ability to "play" the media, that is to say, to start reading and decoding the time-based data, and presumably to render it to the screen and/or speakers. Player has a subclass called Processor that allows lower-level access to the decoded media, which you might use to add effects or "transcode" to another format. To keep things simple, in this article, I provide code for only a small subset of Player-defined functionality.

You don't always instantiate DataSources and Players directly (although we did force the issue of our own special .jar-file-handling DataSource in a previous ONJava.com article). Instead, you ask a class called Manager to try to find an appropriate DataSource for a MediaLocator (which is basically a wrapper for a URL), and then an appropriate Player for a DataSource.

How Manager Works
In each case, Manager takes a list of known package prefixes, combines that with a standardized subpackaging and class-naming scheme, and looks for the resulting class in the CLASSPATH. For DataSources, the subpackage path is media.protocol.protocol-type, where protocol-type is the protocol part of the URL — for example, http or file. So, for the default package prefixes javax, com.sun, and com.ibm, the Manager would try to handle an http:-style URL by searching for the classes, respectively:

javax.media.protocol.http.DataSource
com.sun.media.protocol.http.DataSource
com.ibm.media.protocol.http.DataSource
The scheme is similar for Players, except that the subpackage path needs to incorporate the content-type, such as video.mpeg or audio.midi. The basic subpackage path is media.content.content-type.Handler. Yes, Handler, not Player ... it's kind of weird that way. There's also a special rule for Players: if no class is found for a given content-type, the CLASSPATH is searched again with unknown for the content-type. Generally, this "unknown" class is expected to be a "catch-all" player, quite possibly an OS-specific native player. So for video.quicktime content-type and the default package-prefixes as above, Manager would search for six classes:

javax.media.content.video.quicktime.Handler
com.sun.media.content.video.quicktime.Handler
com.ibm.media.content.video.quicktime.Handler
javax.media.content.unknown.Handler
com.sun.media.content.unknown.Handler
com.ibm.media.content.unknown.Handler
Each time it finds one of these classes, Manager attempts to call the Player's setSource() method. The search is over when it finds a Player that doesn't throw an exception when setSource is called.

By the way, in our implementation there's no difference between the DataSource for the http, file, and rtsp protocols, so there's a single com.mac.invalidname.punt.media.protocol.DataSource class, and the protocol-specific subpackages have trivial subclasses of this class.

Using the JMF Registry
To control the behavior of Manager, JMF provides the JMFRegistry application, which allows an end user to inform JMF of new plug-ins and to control some of Manager's behavior.

To use the JMF Registry, use the executable that comes with the OS-specific JMF release, or in the all-Java JMF, enter at the command line:

java -classpath $JMFHOME/lib/jmf.jar JMFRegistry
Of interest to this article is the "Packages" tab. This defines the list of package prefixes used above, in the order in which they will be tried.

When you're ready to try the JMF-to-QuickTime bridge, run the JMF Registry with the punt.jar file in your CLASSPATH. Use the Add buttons to add com.mac.invalidname.punt to both the Protocol Prefix List and the Content Prefix List, then select the package and use the "Move Up" buttons to make it the first choice in the lists. The result should look like this:


sohu98 2003-09-01
  • 打赏
  • 举报
回复
再up
keyinwind 2003-09-01
  • 打赏
  • 举报
回复
REAL公司有提供realsystem for java的API啊,不过client必须安装realone才可以
lotofu 2003-09-01
  • 打赏
  • 举报
回复
会的贴出来,大家学习嘛!!
何必呢?
raygtr 2003-08-31
  • 打赏
  • 举报
回复
JAVA好像不能播放RM格式!必须将RM转为AV才可以!
sohu98 2003-08-31
  • 打赏
  • 举报
回复
up

我也想知道!

还有用java 能否开发音频和视频的通信软件????
ac669 2003-08-31
  • 打赏
  • 举报
回复
关注!
xiazhihan 2003-08-31
  • 打赏
  • 举报
回复
RM我不知道可不可以,但是JAVA已经有这方面的技术规范了
Wnyu 2003-08-31
  • 打赏
  • 举报
回复
up
shishangx 2003-08-31
  • 打赏
  • 举报
回复
UP

观察中。。。。。
zjzf 2003-08-31
  • 打赏
  • 举报
回复
我也是,
liwei55555 2003-08-31
  • 打赏
  • 举报
回复
必须先要下再到合适的压缩包才有可能,java.sun.com和real网站好像都有!
wangyanqiu 2003-08-31
  • 打赏
  • 举报
回复


帮你up!
sohu98 2003-08-31
  • 打赏
  • 举报
回复
自己up

62,612

社区成员

发帖
与我相关
我的任务
社区描述
Java 2 Standard Edition
社区管理员
  • Java SE
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧