Файлы AVI. Структура файлов, понятие кодека.
Контейнер AVI
Основное преимущество универсального формата AVI (и, кстати, «секрет» его долголетия), в отличие от потоковых форматов типа MPEG, а тем более от таких специализированных разновидностей, как MP3 (MPEG Audio Layer 3), в том, что «стандартных» AVI-файлов практически не существует: AVI — фактически не более чем «контейнер», который содержит общее описание содержимого в стандартизованном виде.
Таким образом, AVI-файлы только внешне выглядят одинаково, но внутри они могут сильно различаться, и, в то время как MPEG-, MP3- и MJPEG-файлы содержат потоки только определенного вида сжатия (компрессии), AVI может содержать много различных видов компрессии в любых сочетаниях. Однако работать с AVI-файлом можно будет только пока необходимый кодек доступен для кодирования/декодирования.
Серьезным недостатком AVI-формата является то, что аудио- и видеофрагменты не содержат никаких меток времени или индексов кадра. Данные упорядочиваются по времени последовательно, в порядке поступления. Приложение для захвата или проигрывания видео должно само позаботиться о синхронизации видео- и аудиопотоков. Но если деление видео на кадры совершенно естественно, то звук представляет собой непрерывный поток, который приходится искусственно расчленять на фрагменты, соответствующие кадрам (из-за этого точная синхронизация изображения и звука часто отсутствует и звук может „расходиться“ с изображением). В простейшем случае каждому кадру видео соответствует кусок звукового сопровождения, но далеко не все AVI-файлы делаются по этой простой схеме.
Недостаток временных меток был устранен в расширении AVI-формата - OpenDML AVI (поддержанный затем в DirectShow и в ActiveMovie), которое добавляет новые куски по меткам времени.
Контейнер уже давно устарел и все никак не хочет уходить на пенсию, причем подавляющая часть медиа контента в сети до сих пор распространяется именно в нем.
- Для каждой цепочки AVI-файла теряется 24 байта на заголовки и индекс. Это приводит к потерям чуть более 5МБ/час.
- Может быть сохранено только содержимое с фиксированной частотой кадров. Т.е. не возможно поместить в AVI смешанный материал, например, смесь NTSC видео и киноматериала. В действительности, есть хаки, позволяющие сохранять содержимое с переменным fps в AVI, но они увеличивают (и без того большую) избыточность впятеро или более того и поэтому непрактичны.
- Аудио в AVI-файлах должно быть или с постоянным битпотоком (CBR) или с постоянным размером кадра (т.е. все кадры декодируются в одно и то же число выборок).
- AVI не способен отличить P-кадр от B-кадра. Не предусмотрено спецификацией. DivX / Xvid решают эту проблему в обход спецификации, что тоже не совсем хорошо и может создавать проблемы.
- Контейнер AVI создавался для работы через интерфейс VfW (Video for Windows) и как раз VirtualDub является программой, использующей исключительно VfW. Поскольку VfW является сильно устаревшим и не гибким, современные программы используют DS (DirectShow). Программы использующие DS замечательно работают с контейнерами под DS заточенными, но вот с VfW возникают проблемы в виде расхождения аудио и видеодорожек. Поэтому не следует использовать для работы с AVI-файлами программы, работающие не через VfW.
- Отсутствует поддержка современных кодеков.
Заголовок
В соответствии с общей структурой RIFF-типа, AVI-файл должен иметь следующий вид:
код:
RIFF 'AVI ' // четырехбуквенный идентификатор файла (в RIFF-формате)
LIST 'hdrl' // список заголовков блоков, определяющих форматы потоков
LIST 'movi' // блоки данных (потоков) AVI-файла
'idx1' // необязательный блок, определяющий размещение блоков данных внутри AVI-файла <AVI Index>
То есть в AVI-файле должно быть по крайней мере два обязательных блока: заголовка и данных, которые, в свою очередь, могут содержать подблоки. Первый блок будет содержать общую информацию о видеоролике: разрешение кадров и их частоту, формат аудио и т.д. Сначала в заголовке для записи длины потока отводилось 32 байт, поскольку в файловой системе FAT 16 максимальный раздел диска не мог превышать 2 Гбайт, поэтому и максимальный кусок видео, который можно было записывать в AVI-файле, не мог превышать 2 Гбайт (с учетом знака переменной размера). Во времена возникновения формата казалось естественным, что длина файла не может превышать размер логического диска. С появлением файловых систем FAT 32 и NTFS верхняя граница размера раздела значительно отодвинулась, однако потребовалось еще немало времени, чтобы ввести расширение формата и дождаться программ, способных это ограничение обходить.
Список „hdrl“ может состоять из подсписков:
код:
LIST 'hdrl' // список заголовков блоков, определяющих форматы потоков
'avih' // главный заголовок AVI-файла
LIST 'strl'
'strh' // заголовок потока
'strf' // формат потока
'strd' // дополнительный заголовок данных
Список „movi“, в свою очередь, состоит из подблоков:
код:
LIST 'movi' // блоки данных (потоков) AVI-файла
SubChunk | LIST 'rec ' // подблок | список записей
'##wb' (размер блока 4 байта) (data) // звуковые данные (блок)
'##dc' (размер блока 4 байта) (data) // видеоданные (блок)
'##db' (размер блока 4 байта) (data) // видеоданные (блок)
Таким образом, подблок данных организован в виде последовательности записей, каждая из которых состоит из одного кадра видео и соответствующего звукового сопровождения. Первоначально ##dc-блок был предназначен для хранения сжатого изображения, а ##db-блок - для несжатого DIB (Device Independent Bitmap). Но фактически они оба могут содержать сжатые данные.
Кодек
Кодеки могут как кодировать поток/сигнал (часто для передачи, хранения или шифрования), так и раскодировать — для просмотра или изменения в формате, более подходящем для этих операций. Кодеки часто используются при цифровой обработке видео и звука.
Большинство кодеков для звуковых и визуальных данных используют сжатие с потерями, чтобы получать приемлемый размер готового (сжатого) файла. Существуют также кодеки, сжимающие без потерь (англ. lossless codecs). Но для большинства применений выгоднее кодеки с потерями информации, так как малозаметное ухудшение качества оправдывается значительным уменьшением объема данных. Почти единственное исключение — ситуация, когда данные будут подвергаться дальнейшей обработке: в этом случае повторяющиеся потери на кодировании/декодировании окажут серьёзное влияние на качество.