> Вообще-то сжатие видео и сжатие одиночных картинок - весьма разные задачи. Кроме случая когда сжимается "key frame" (aka I-frame в мпег). "Ключевой" кадр является опорным, от него далее ведется отсчет, последующие кадры являются по сути попыткой кодировать отличия от опорного кадра, как можно компактнее. Поэтому желательно чтобы опорный кадр как можно лучше передавал сцену в начальном состоянии. По большому счету, ключевой кадр можно рассматривать как статичную картинку со сценой от которой ведется отсчет изменений. В общем то глобальных отличий от жпега в этом плане там немного.
> или в 21-м веке люди и дальше будут продолжать использовать анимированный GIF.
Lossy сжатие типа жпега/vp8... и lossless сжатие типа GIF(LZW) и PNG(zlib) ориентировано на разный класс задач. Lossy хорошо жмут "фотоподобные" изображения, потому что на таких изображениях не видно их артефактов сжатия. А вот "компьютерная графика" типа скриншотов, кнопок/окон и что там еще - выглядит крайне мерзко. Такие кодеки плохо кодируют большие области с одинаковым цветом или тем паче, контрастные линии в большом количестве (они для этого никогда не создавались). Чтобы не было видно артефактов на резких линиях (типа юзер интерфейсов и прочая) - размер файла должен быть невкусным (JPEG скриншота с качеством сравнимым с PNG весит как правило весьма дико). Lossless кодеки хорошо жмут компьютерную графику и подобное - за счет повторяющихся данных типа больших одноцветных областей или линий. Но напрочь спасуют на фотоподобных материалах, которые спасибо если сожмутся так в ~пару раз. Потому что на фотографиях не так уж и много пикселов точно повторяется. В итоге - GIF это анимация. А VP8 и что-то иное на основе jpeg-like и подобных по смыслу техник с DCT - это видеоклипы. Делать анимацию в lossy или видеоклипы в lossless - не эффективно. Хотя бывают и чудики уталкивающие в гиф откровенные видеосцены (только весит оно потом дико) или бойко скриншотящие в JPG :).
