tags:

views:

207

answers:

3

Hi, I have to read a large file containing many animation frames from CD/DVDrom and display it into screen as an animation. When reading from hard disk, the strategy of reading a frame into memory, processing, displaying and then reading next frame works good, but when I read from optical device, access time kills the animation.

I use C and winapi OpenFile/ReadFile methods.

How should I read contents of a file stored on an optical device to achieve realtime speed of animation ( I have seen a program that does it even in double speed, for sure it does not buffer the whole file before animation start ) ?

+4  A: 

Two techniques:

  1. LARGE buffer or cache, as in multiple MB. CD/DVD has reasonable sequential I/O but very slow seek/access speeds (as you have noted), so it's fast to refill the buffer. You just need the buffer to be large enough that it covers a few seconds to allow the disk to spin up if needed, and seek if already spun up.

  2. Multi-threading: keep one thread continuously reading and a separate thread decoding animation. Reader thread should block if it gets too far ahead of decoding.

These techniques apply to any programming language, and can be combined for best effect. One reading buffer and one decoded frame buffer protects you twice as well against the decoding time and the access time.

EDIT: These are the techniques MPlayer uses. In addition, you should consider your encoding format if you can -- different formats can trade off CPU time on decoding for less data to read from disk. A couple pieces of info for estimating how much video should be compressed.

  • Read speed for 1x CD-ROM: 150 kiB/s (bare minimum speed)
  • Read speed 4x CD-ROM: 600 kiB/s (standard minimum drive)
  • Read speed 16x CD-ROM: 1600 kiB/s (maximum obtainable, usually only runs up to 8x)
  • Read speed 1x DVD Drive: ~1.3 MiB/s
  • Standard definition video compressed with MPEG2 at DVD-quality: ~600 kiB/s
  • Standard definition video compressed with MPEG4 at DVD quality: ~100 kiB/s
  • Uncompressed standard definition video: ~30 MB/s
  • Standard 1000x1000 (1 megapixel) image at 24 bit color: 3 MB
  • Standard 1 megapixel image at 8-bit color (grayscale): 1 MB

Edit2: additional info

  • Note that DVDs commonly can be read at 8x or so if your drive supports it (most do now).
  • Animations start to appear smooth at 24+ frames/second. Below that they will appear jerky to a viewer.
  • Lossless compression is usually good for about a 50% reduction in size for photographic images. Your mileage may vary though.
  • Smooth playback of animations will be partly dependent on how you speak to the video hardware. Some methods will produce better results than others. I HIGHLY suggest you look at the code for MPlayer in this case.
BobMcGee
Should the data be read in some defined data chunks, or overlapped io is a better idea?
bartek
@bartek: overlapped IO will bypass the system cache, so it will (probably) be _smoother_ but not necessarily faster.
John Knoeller
Thank's a lot, i'ts really helpful. I'm not sure I understand what does it mean "continuously reading", does if makes any difference if I call ReadFile many times with smaller read_buffer or less times with larger buffer? I found that using std::fstream seems to use disc smoother, can it be true?
bartek
@Bartek: for these purposes, it doesn't matter what your read method is, as long as it is continuously pulling from file and feeding to a separate decoding thread (maybe splitting into frames as a pre-processing step). Try the different read methods and see which ends up with highest throughput. The most important thing about the threading approach is that you **separate the I/O thread from decoding**. This means that your throughput is only limited by the slower step, rather than the combination of the two. Can be critical for things both I/O AND CPU intensive.
BobMcGee
+2  A: 

One thing to try is compression. Loading a zip file off the drive, for example, will take less time but require more CPU time to process. If lossless compression is possible then that may be worth inspecting. Understanding a CD drive is useful too. The drive spins at a fixed rotational velocity. This means that data on the outside of the disc loads faster than data on the inside. A burner, however, will burn data from the inside outwards so you may end up having to burn a lot of data before the "animation" to get max read speed.

Goz
This is good advice (and applies to hard drives too), but if I read right, the questioner doesn't have much control over data placement on disk or animation format. I think it wouldn't be a bad idea to mention read speeds for optical drives vs. standard bitrates for compressed video formats.
BobMcGee
to be more precise, I read a dicom (medical image format) files, the data in multiframe images is always stored frame by frame in a single data segment, sometimes it is lossless encoded.
bartek
Can you encode it lossily? Can you place it wherever you want on the disc?
Goz
If I'm a CD creator, I can, but normally I have to read what I get, also IHE has several restrictions on data encryption and patient CD's
bartek
I'm quite frustrated because I can't achieve good performance when other's can. I don't understand CD drive io good. I didn't tried FILE_FLAG_SEQUENTIAL_SCAN yet.
bartek
+1  A: 

use CreateFile with OPEN_ALWAYS, and FILE_FLAG_SEQUENTIAL_SCAN

John Knoeller