not entirely sure here, but OpenGL seems able to compress textures relatively quickly.
or, is the idea that the built-in texture-compressor provided by OpenGL isn't "good", or isn't very fast, or something else?...
Generally, if a DXT compressor is very fast, then it's probably producing low quality results.
One other downside of asking GL to compress your data for you is that (on Windows) this is implemented in the graphics driver code, which is likely to be different on each of your user's PCs. This means that maybe one user's driver has a slow DXT compressor, while another's is fast. Maybe one user gets really bad quality textures, while others get decent quality? It's hard to ensure a consistent experience when you outsource some behaviour of your game to an unknown 3rd party plugin like this.
For an example of objectively measuring the quality of different compression approaches, see L. Spiro's DXT compression blog post here, where he talks about measuring signal to noise ratios, or this blog post that LS links to has some good visual examples of how different the results of different algorithms can look.
As for video, there's probably not much point in DXT compressing individual frames (unless, yes, you somehow could directly transcode from the video format to DXT blocks!). The time spent performing the DXT compression would probably outweigh the theoretical benefits, which include:
* quicker time to transfer the frame to VRAM (but this time is probably already small compared to the MPEG/etc decoding time)
* faster pixel shader execution due to faster texture fetching (but pixel shading isn't likely a bottleneck)
* reduced VRAM usage (which isn't that important as you only need a frame at a time)