CopperCircle - after some time of testing I think OpenVIP may not be the best choice for us. When you run the oringinal OpenVIP Editor, you'll notice that it's relatively slow when it has to jump to a certain frame. Of course, this is depending on the Codec used, but since I am using nonlossy HuffYuf a lot to prevent degeneration, it's real slow.
There is a method using Avisynth and MCIsendString together: A temporary Avisynth script is opened as a movie by MCI, but the script only sends one single frame (the wanted frame). This way, MCI couldnpt mess things up, and it would send the right frame, no matter what. The only problem I see right now, is: In BLitz I can grab the MCI Canvas video frame in fullscreen only, in windowed mode it simply didn't work. Then again, BlitzAvi that is used to save the Avi, requires windowed mode unless you want it to become frozen. In my current tool DrGreen I had to use some real weird tricks that will minimize and maximize the fullscreen app using some WinApi commands to make BlitzAvi work in fullscreen. Additionally it's pretty tricky to make the Api Alerts and Prompts work with the fullscreen Mode (see code archives, coordinated Flip).
Well, in DrGreen I used an extreme amount of complicated tricks, only to be able to access video frames. And after all, MCI isn't reliable at all, instead it misses/drops frames, something that is completely inacceptable.
I would be willing to use a commandline tool (eg. Avi2wav) that will seperate the Audio and Video of an Avi, then edit the frames only, then save it without Audio (eg. using BlitzAvi), then use some third party Avi Muxer that will mix and save the original Wav with the new Avi. I'm pretty sure there are several tools that are capable of this.
I still think if you want to access single frames as quick as possible, you (or the video reader) should use some kind of access table, in the best case with a SEEK adress for direct frame access, in the worst case a SEEK adress to a keyframe that is the basement for the wanted frame.
I am still thinking about to write my own AVI reader, and maybe I would accept a limitation in the number of possible codecs, since basicly it's an inhouse tool.
What do you think Lee, should we try to write an Avi reader that is using optimized access with adress tables? If so, I'd really suggest to use two nonlossy formats only: completely uncompressed and HuffYuf. Because, usually you are editing small scenes, a few seconds only, so the size isn't a huge problem. Using Huffyuf for example would allow to use max. 2GB files (at least on Win98 etc.), that's about 1.5 Minutes in full MiniDV resoltution, including sound.
The source to the huffyuf decoder/encoder is available for free from here:
http://neuron2.net/www.math.berkeley.edu/benrg/huffyuv.html
I'm not a C++ expert and I don't know how useful this would be, maybe somebody have a look.
Other than that, I guess it can't be that hard to write an Avi Reader for uncompressed Avis. and isn't it the way a lot of pro tools use uncomressed Avi anyway?
There is a method using Avisynth and MCIsendString together: A temporary Avisynth script is opened as a movie by MCI, but the script only sends one single frame (the wanted frame). This way, MCI couldnpt mess things up, and it would send the right frame, no matter what. The only problem I see right now, is: In BLitz I can grab the MCI Canvas video frame in fullscreen only, in windowed mode it simply didn't work. Then again, BlitzAvi that is used to save the Avi, requires windowed mode unless you want it to become frozen. In my current tool DrGreen I had to use some real weird tricks that will minimize and maximize the fullscreen app using some WinApi commands to make BlitzAvi work in fullscreen. Additionally it's pretty tricky to make the Api Alerts and Prompts work with the fullscreen Mode (see code archives, coordinated Flip).
Well, in DrGreen I used an extreme amount of complicated tricks, only to be able to access video frames. And after all, MCI isn't reliable at all, instead it misses/drops frames, something that is completely inacceptable.
I would be willing to use a commandline tool (eg. Avi2wav) that will seperate the Audio and Video of an Avi, then edit the frames only, then save it without Audio (eg. using BlitzAvi), then use some third party Avi Muxer that will mix and save the original Wav with the new Avi. I'm pretty sure there are several tools that are capable of this.
I still think if you want to access single frames as quick as possible, you (or the video reader) should use some kind of access table, in the best case with a SEEK adress for direct frame access, in the worst case a SEEK adress to a keyframe that is the basement for the wanted frame.
I am still thinking about to write my own AVI reader, and maybe I would accept a limitation in the number of possible codecs, since basicly it's an inhouse tool.
What do you think Lee, should we try to write an Avi reader that is using optimized access with adress tables? If so, I'd really suggest to use two nonlossy formats only: completely uncompressed and HuffYuf. Because, usually you are editing small scenes, a few seconds only, so the size isn't a huge problem. Using Huffyuf for example would allow to use max. 2GB files (at least on Win98 etc.), that's about 1.5 Minutes in full MiniDV resoltution, including sound.
The source to the huffyuf decoder/encoder is available for free from here:
http://neuron2.net/www.math.berkeley.edu/benrg/huffyuv.html
I'm not a C++ expert and I don't know how useful this would be, maybe somebody have a look.
Other than that, I guess it can't be that hard to write an Avi Reader for uncompressed Avis. and isn't it the way a lot of pro tools use uncomressed Avi anyway?