Re: RAM FileDescriptor
On 10/15/12 12:07 PM, David Lamb wrote:
On 15/10/2012 2:41 PM, Jeff Higgins wrote:
On 10/15/2012 02:08 PM, bob smith wrote:
Let's say you have a function that plays a movie that is passed in as
a FileDescriptor. Is there any way to load the movie into RAM and get
a FileDescriptor for the RAM?
Looking here:
<http://docs.oracle.com/javase/7/docs/api/java/io/class-use/FileDescriptor.html>
the most likely route seems to be java.io.RandomAccessFile.getFD(). But
I don't know what "a FileDescriptor for the RAM" means. Will you clarify?
I doubt it exists as a general concept and thus probably doesn't exist
in Java. I seem to recall that some operating systems from many years
ago let you map a file into RAM and operate on it from there, but I'm
moderately sure that feature either went through the standard file
system stuff and was (nearly) invisible, or you accessed a massive byte
array directly.
Java's NIO does actually have this capability (for example, in
MappedByteBuffer)
<http://docs.oracle.com/javase/7/docs/api/java/nio/MappedByteBuffer.html>
The former corresponds to people's advice to use a
FileInputStream amd the latter to a ByteInputStream as appropriate.
Wouldn't your movie exceed the capacity of RAM? or are you limiting
yourself to short ones?
I would say that the method shouldn't require a specific subclass of
InputStream, but *all* of them. *or* it should take a class which
supports random-access to the data (abstracted from whether it does so
by reading the entire data set into memory, or uses a file, or as
YouTube and other plays do, buffers the network data as it comes in).
FWIW, modern systems don't need to load video data into memory to get a
reliable output. The compressed data is "small enough" compared to the
expected throughput that buffering (other than some base level, such as
OS) the uncompressed data in memory makes little sense.