119 lines
3.3 KiB
Plaintext
119 lines
3.3 KiB
Plaintext
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....
|
|
|
|
|
|
|