[rescue] Sun 711
James Lockwood
james at foonly.com
Thu May 2 10:03:42 CDT 2002
On Thu, 2 May 2002, Joshua D Boyd wrote:
> But again, why not just call Sun and see what they have to say?
You would have to go third-party for an app like this, and that can get
ugly. I'm not aware of any framebuffers that will fit a Sun and meet the
specs desired.
> It depends. You don't want to open each file and close it while playing
> I would think, but that would be a good place to start. Assuming it
> doesn't work, a possible next step would be to open all the files at
> once, and keep them open the whole time. That would save on all those
> extra open and close calls, and might be good enough.
Speaking as someone who has written a playback interface (though on a
somewhat less grand scale than this):
You do not want to be opening a file for every frame, the overhead though
less than it was years ago still exists. Either access the data as one
big uncompressed file/raw partition, or bunch the frames into "frameset"
files. 1 second each at 300MB/ea would be a convenient size.
You don't have enough time to do most lossless decompressions. TIFF buys
you nothing for your app except some extra parsing overhead, which can be
significant. Consider having an intermediate step (assuming your data
comes in as TIFF) where you load each frame into a raster and then save
the raster image into your file structure.
You _must_ do readahead here. The easiest way to do it is to use a shared
memory ring buffer (600MB-1GB would probably be good here, 2-3 seconds)
and either 2 processes or threads. One constantly tries to keep the ring
full of new data, pausing only when it has completely filled it. The
other process pulls one frame off the ring every $FRAMEINTERVAL. If you
have a couple seconds of readahead you do not need low latency, unlike
what an earlier post claimed.
For extra credit, determine the exact byte requirements for your display
and save your rasters in a format that can be directly blitted in. This
may well be the only practical way to do it.
> In other words, Fusion is going to do a rendering pass to see what it would
> look like on film. While it is doing that, could you have it spit a
> quicktime file to the playback machine, or is that out of the question?
>
> I ask because while writing your own player is possible, being able to use
> an existing video library would make life easier for you.
Quicktime player overhead, even with uncompressed video, is significant at
this data rate.
-James
More information about the rescue
mailing list