todo.txt

Video IO toolbox for matlab. 用directshow做的

This file contains suggestions for things that may be added in future 
versions of the library.  If any of these items are especially interesting
to you, feel free to contact the author ([e-mail]).

A handy command to search for TODO items in the source code is:
  grep -r TODO * | grep --invert-match '\.svn' | grep --invert-match tracker | grep --invert-match 'TODO\.txt' | grep --invert-match '~:'


distribution:
  Create a distribution that includes just the binaries and .m files.  
  This version should skip the buildVideoIO steps in the tests.

options struct for constructors:
  Allow codec params to be supplied as a struct in videoReader, 
  videoWriter constructors.  Counter-argument: this might be a bad idea 
  because it might be tempting to use @videoWriter/getinfo's output and 
  forget to change the filename, thus overwriting previous video files.

get/set methods:
  Consider making generic @videoReader/get.m and @videoWriter/get.m 
  functions that work like standard Matlab getters.
  
@videoWriter/getinfo:
  Add frameNum field to the return value.

codec metadata:
  Enhance videoWriter([], 'codecs') to return friendly names and/or other 
  useful information (at least on Windows).  To do so, have 
  OVideoManager::getcodecs return a 
    map<CodecName, map<DetailFieldName,DetailFieldValue> > 
  where CodecName, DetailFieldName, and DetailFieldValue are all strings.  
  To use the return result on Windows, do something like:
    getcodecs()["xvid"]["FriendlyName"] // returns "XviD MPEG-4 Codec" on Win32

get defaults:  
  Implement a way of getting the default values for videoWriter constructor
  parameters.  Perhaps the solution is to do the bulk of the parsing in 
  Matlab and pass a fixed options structure to C++?  

colorspaces:
  Allow different colorspaces, e.g. YCC and not just RGB.  This is useful 
  if, for example, the user wants to do image processing in the YCC domain 
  instead of RGB.
  
seeking precision:
  Allow imprecise seeks with ffmpeg, if there is API support.
  
buffering:
  Consider doing decoder prefetching by using a background thread to keep 
  a buffer of the next n decoded frames for videoReader and keeping a 
  buffer for encoding frames with videoWriter.  This should allow much 
  better throughput on multicore systems.  The buffer size should be a 
  user-settable parameter to the constructor at very least.  The user 
  should also be allowed to revert to the current synchronous mode.  
  
SampleGrabber:
  On Windows, it might be worth taking a close look at 
     [DX9SDK]\Samples\C++\DirectShow\Filters\Grabber\grabber_text.txt
  for a different, more powerful method of sample grabbing.
  
DirectShowPopen2:
  Provide a DirectShow plugin where the mex file runs in 64-bit mode but the
  server process runs in 32-bit mode.  This would allow 64-bit Matlab to take
  advantage of 32-bit codecs.

audio:
  Add support for audio.  This will probably require a lot of extra work.
  
avifile/xine support:
  Recreate avifile plugins for 32-bit Linux.  Note that support for avifile 
  was removed because:
    1) the avifile library is hard to build (it requires modifying avifile's 
       source code since it's hard for avifile to stay in sync with ffmpeg's
       rather frequent API changes)
    2) by now (8 Mar 2007), there are few things that avifile does that 
       ffmpeg can't do natively.
    3) avifile likes to write to stdout, and this can't be fixed without 
       modifying the source code (the library initializes itself and prints 
       logger messages before the user has a chance of disabling the 
       logger).  We could return to the old solution of having 
       readMessageHeader ignore any text before a valid header, but doing 
       so makes it more complicated.
  Unless there's a really good reason to resurrect the avifile plugin, it 
  will likely not happen.  If ffmpeg proves to not be powerful enough, it
  might be better to make a xine plugin.  The xine media player's backend 
  uses a library that looks pretty clean.  MPlayer doesn't really have a 
  clean backend, so wrapping it up would be extremely challenging and 
  brittle to its frequent code changes.  xine does seem to have a nice library
  interface, so it might be a better option.
  
imread/load plugins:
  -- Consider autoselecting imread/load plugins by default 
     when wildcards/sprintf-strings are found in the url.  
  -- Consider adding support for reading streamed files.  Right now, the
     load and imread plugins obtain an immutable file list at construction 
     time.  Some users may find it handy to be able to read files that were
     created after construction time.  This feature may be tricky to support
     for the wildcard version.
  -- If users need it, use a more efficient data structure for holding 
     filenames when the first frame number is a very large number (right now
     we use a linear cell array starting at index 0).

imwrite/save plugins:
  -- consider making imwrite/save plugins for writing videos as duals of the
     imread/load reading plugins.

videoIoSysInfo:
  It would be cleaner to move the 3rd-party library status checks of 
  videoIoSysInfo into the makefiles.  This would avoid dependencies between 
  the two and we would be more likely to be able to catch tweaks users might 
  make to the makefiles.