The next version is coming along nicely now I just checked in some good work around the pipeline refactor. things are much simpler now, and will be much more memory friendly … which will allow you to use larger videos.
- The pipeline API is much simpler now. It will be much easier to extend in the future. I have an interface (IVideoContent) which the importer will return. This IVideoContent will be responsible for actually doing the work of loading the frame data for the content writer to write to disk.Particularly of interest is the fact that IVideoContent.Frames property returns an IEnumerable<Texture2DContent>. Using the yield keyword allows the writer to do it’s work one frame/texture at a time … and then it’s free for the garbage collector to collect.
- There will be no need for a custom processor … the pipeline will just use the pass through processor.
- In-memory vs Streaming will simply be a parameter on the importer.
note: haven’t tested this yet, but you may not be able to parameterize an importer (if I’m reading the docs right). If that’s the case, then point 1 is moot, and I’ll simply have a processor that will let you choose options like in-mem vs streaming, and some other things like image formats.
- Runtime API won’t be affected. as of yet, I don’t have any plans on changing that API, so code that you’ve already written won’t have to change.
So far, all the feedback I’ve gotten (aside from memory issues with large videos) has been positive. Haven’t gotten any bug reports, which leads me to believe that things are, at least, stable This is good, and makes me think that I need to put a priority on reaching a feature complete state.
The only major feature I can think of that’s missing is audio … so I’m thinking that this is what I will work on next after this version is out the door. However, if you have any requests, or ideas on what you’d like to see in the next version pipe up in the discussion forums.