Things to do in AVIFile:
Need handlers for:
Quicktime files
Targa files
JPEG files
MPEG files
Improve streaming interface
Speed improvements:
Use GlobalDosAlloc for buffers?
Read several frames at one time?
Current bugs:
Error returns are lousy.
More things to do:
Automatically generate open/save filter strings. This would
require that we put something in the regdb to indicate which
handlers supported writing....
Should there be some way to pass AVIFileOpen an HMMIO? An
IStorage or IStream?
It would be nice to have some way to be notified when the contents
of a stream change.... Look at IAdviseHolder
ReadData and WriteData need to be renamed, because they
confuse everybody. Also, need better method for accessing
DISP and LIST `INFO' chunks.
Stream names need to be better supported.
During long operations, we need some kind of status callback.
Should everything have version numbers?
"capabilities": Additional information via AVIFile/StreamInfo
about what the handler can do
Do handlers need parameters somehow? Some way to configure
stuff for a particular file format? Am I deluding myself into
thinking I can get away without this stuff?
More thought is needed about "non-seekable" streams. For
instance: can a video capture device be thought of as a
stream?
Can making a stream handler be made easier? One thought: a
C++ base class for a stream handler which people could
override only the methods they want....
How can you change the rectangle for a stream?
Do we need an AVIStreamSetInfo command?
Can we make streams be named? Instead of opening streams by type
and number, people could enumerate the streams in a file and open
them by name.... Looks more and more like IStorage....
Everything needs to be renamed. Functions shouldn't all
start with "AVI".
We need a new interface to handle change notifications. Copy
OLE Advise Holders, Advise Sinks.
Marshal the AVIFile reader in the following way:
Right before reading from an HMMIO, check the current task.
Re-open the file for each new HTASK....
Some way of getting an error string from an error value would
be good.
I don't really use the IEditStream interface for everything.
I should make Vtbls for the editstrm.c implementation, and allow
other handlers to support the stuff.
How can you use ReadData/WriteData to deal with more than one
chunk with the same ID? How about INFO chunks?
Old Stuff that's done:
Does AVIStreamWrite need some way of returning how much of the
data was actually written? (Particularly in the case where
it's doing ACM compression, it may only be able to write out
whole blocks of data....)
EditStreamSetName
EditStreamClone
AVIStreamInfo could use a different structure than an
AVIStreamHeader. In particular, the structure could lose
some useless fields and gain the stream name. Same with
AVIFileInfo.
During long operations, we need some kind of status callback.
Look at using IAVIFile, IAVIStream on the clipboard along with
IDataObject. This seems to require some work to "marshal"
the interface from app to app....
Given an open IAVIFile handle, retrieve its "file format", that
is, some user-readable name for what kind of file it is....
It would be nice to be able to write to the compression streams
The options dialog doesn't make me happy....
