Settle on the stream API. Should the redundant read_frame() be removed? Can we handle all asynchronous streams with the synchronous API and an asynchronous buffering mechanism behind the scenes? The idea being that we want a simple API.
Add some notion of timestamps to the vidl_frame. It seems like it would be useful to know when each frame was captured (maybe relative to the first frame), especially if you are allowing for dropped frames or capturing non-uniformly in time.
Improve conversion routines to and from vil_image_views.
Add support for more parameters in the 1394 camera standard.
Write a VXL book chapter for vidl (in progress). This is required to promote vidl to core and ultimately replace vidl (which has a very limited book chapter). Also, it would be good to have a user's guide other than the Doxygen generated pages.
Decide on a standard (maybe XML?) for stream parameter files, and add code to read and write these files. This is related to the factory creation stuff. Should we push to put modern factory creation code in vbl?
Update vidl/examples/vidl_player to include all implemented streams. We'd like to have a single GUI demo application that can feed any istream to any ostream (provided they have been compiled into vidl).
Update comments within the code. This includes the "advance but don't acquire" remark. This was intended for the case of file parsing where one can seek to another frame without decoding it, but is incorrect for live streams. Advanced Copy & paste techniques have spread the comment around ;-).
A DirectShow ostream should be added.
We'd like to create a DirectShow filter that replaces the ISampleGrabber currently used in the vidl_dshow_istream family. This would remove the limitations imposed by the use of the ISampleGrabber and potentially could consolidate the file/live_istreams into a single vidl_dshow_istream.
1.7.5.1