Quote:
Originally Posted by IanB
Various tools and explorer plugins like to 'investigate' .AVI files. And then there are virus scanners and security products. It is crucial these never be allowed to read through the contents of the pseudo .AVI files.
.....
Joe, does PFM have knowledge of the "Application name" when a pseudo file access happens? Could various applications be black listed and the returned contents just be 1 big zero fill. Or maybe a white list so only say VirtualDub.exe, X264.exe and Vegas*.exe get to see the rendered pseudo contents.
|
No current mechanisms exist in PFM to allow the formatter to change behavior based on the process name. If it were supported, it would only be available during open, not at read.
But, I really do not like this sort of a solution. It looks like a quick fix, but it has a lot of drawbacks.
Examples:
1) Explorer related I/O, such as various shell extensions, is going to happen in the open dialog in applications in the white list.
2) Some of the anti-virus products and system extensions open files and do I/O in the context of the triggering process (this is true of prefetch as well).
3) Some apps/plugins may do work out-of-process, so the user has to track down the name of processes they did not run and add them to the white list.
4) Dllhost.exe, rundll32.exe, and the like.
One thing that should help is to set the FILE_ATTRIBUTE_OFFLINE flag on the virtual media files. This is a trivial change to avfs.dll. I would have done this originally, but it was not supported two years ago when we first put AVFS together. This flag will convince explorer to leave the file alone, only show default icon, etc.. Many 3rd party shell extensions and applications also honor this flag, otherwise they are unusable in enterprise environments that use any sort of HSM. The shell extensions that do not check this flag should be bugged back to the developer.
The anti-virus issues can be handled (usually) with exclusions. Well, if the anti-virus product does not support user exclusions then the user might want to look for another vendor.
Quote:
In the original implementation, I went for up tight maximum packing in the pseudo AVI file. On reflection perhaps a sparse highly padded approach would have been better.
...
It would be trivial to have the frame data aligned on some nice round offset (say 64K or more) and add a 'JUNK' padding/guard block between each frame chunk. The data contents in the 'JUNK' blocks doesn't even matter, so no actual memory transfer/zero fill needs to occur, further boosting performance.
|
I can not recall if there were any compat issues with the padding between frame and audio chunks. There is the existing AVFS_AVI_NoInterleave option to disable interleaving the audio and video chunks. Some more padding options would probably be useful.
The below thread indicates the no-interleave option solves some performance issues. I am suspicious about the comment that it introduces audio sync issues, but this is the sort of compat trouble that playing with the index and with padding is likely to cause.
http://www.dvinfo.net/forum/canon-eo...tml#post990122