On Mon, Nov 06, 2006 at 01:56:53AM +0100, Michael Niedermayer wrote:
btw, ralph if you disagree here, iam curious about the cases where you think that a crc field on frames makes sense
The main thing, I think, is that most decoder implementations are not robust against garbage data (and in some cases cannot be, entirely) so a crc on the frame data helps catch corruption that could crash or mangle playback. It's not a security issue per se, since malicious code could of course set correct crcs, but it still improves robustness. As a counterexample, RTP packets don't have an internal CRC, but since they're supposed to fit within an unfragmented UDP packet, they can piggyback on the transport's checksum for a similar level of integrity. The other point is file verification. Since people collect and serve media files, it's convenient to have an embedded integrity check to detect corruption. An embedded hash or separate checksum can do the same thing, but it's not automatic, and doesn't work with streaming. They do help with truncation detection though. PNG images (and FLAC frames) have CRCs, JFIF jpeg and GIF do not, so perhaps you can make an argument that it's more important for lossless storage. But I've only heard the png developers talk in terms of integrity verification motivated as above. -r