Это формат файла или потоковый формат чьи спецификации определяют только способ сохранения данных

Обновлено: 06.01.2025

Медиаконтейнер, мультимедиаконтейнер (англ. Media container ) — формат файла или потоковый формат (поток необязательно должен быть сохранён в виде файла), чьи спецификации определяют только способ сохранения данных (а не алгоритм кодирования) в пределах одного файла. Медиаконтейнер определяет, сколько метаданных фактически может быть сохранено, вместе с тем он не определяет никакую кодификацию самих данных. Медиаконтейнер фактически является метаформатом, так как он хранит данные и информацию о том, как данные будут сохраняться непосредственно внутри файла. Как следствие из этого, программа, которая способна корректно идентифицировать и открыть файл (прочитать поток), записанный в каком-либо формате, впоследствии может быть не способна декодировать фактические данные, записанные внутри медиаконтейнера, так как или метаданные в медиаконтейнере являются недостаточными, или программное обеспечение неспособно декодировать данные, закодированные в медиаконтейнере.

В теории формат-контейнер способен хранить любой тип данных, однако на практике для каждого типа данных существуют отдельные группы контейнеров. Эти группы «настроены» для специфических требований и информации, которая будет сохраняться в них. Медиаконтейнеры являются типичным примером такой группы файловых контейнеров, которые предназначены для сохранения медиаинформации, которая условно делится на изображения, видео и аудио. В случае фильмов медиаконтейнер должен не только сохранять видео- и аудиопоток, но и при воспроизведении обеспечивать их синхронизацию. Также в медиаконтейнере может сохраняться несколько однотипных потоков, например фильм (видео-поток) с несколькими звуковыми дорожками (аудиопотоками) и субтитрами (текстовыми потоками).

Контейнер файла используется для идентификации и чередования различных типов данных. Более простые контейнерные форматы могут содержать различные типы звуковых данных, закодированных определённым кодеком. Более сложные медиаконтейнеры могут поддерживать множественные аудио- и видеопотоки, текстовые субтитры, информацию о разделах (рус. chapter ), метаданные (рус. теги ), наряду с информацией для синхронизации воспроизведения различных потоков одновременно. В большинстве случаев заголовок (рус. header ) файла, большинство метаданных и синхронизационные данные определены форматом контейнера. Например, есть контейнеры, оптимизированные для видео низкого качества с низким битрейтом, а есть контейнеры, оптимизированные для больших файлов, содержащих множество потоков высокого качества.

Составные части контейнера файла имеют различные наименования. В RIFF и PNG их часто называют «chunks» (рус. куски ), в MPEG-TS их называют «packets» (рус. пакеты ), а в JPEG они называются «segments» (рус. сегменты ). Основной контент данных составных частей называется «данные» или «полезная нагрузка». В большинстве контейнерных форматов каждая составная часть в последовательности имеет свой заголовок (рус. header ), в то время как медиаконтейнер TIFF вместо этого сохраняет смещения, что приводит к трудностям в сохранении информации. Модульные составные части облегчают восстановление других составных частей в случае повреждения файла или при «выпадении» кадров или при не указано название статьи.

Некоторые медиаконтейнеры предназначены для сохранения только аудиоданных:

(формат файла IFF, широко используемый на платформе Mac OS) (формат файла RIFF, широко используемый на платформе Microsoft Windows) (англ. Extensible Music Format — рус. расширяемый формат музыки )

Некоторые медиаконтейнеры предназначены для сохранения только статических изображений:

(англ. Flexible Image Transport System — рус. гибкая транспортная система изображения ) — медиаконтейнер для статичных изображений, необработанных данных (англ. raw data ) и связанных метаданных. (англ. Tagged Image File Format — рус. теговый файловый формат изображений ) — медиаконтейнер для статичных изображений и связанных метаданных.

Большинство медиаконтейнеров приспособлено для сохранения всех или почти всех типов медиаинформации, включая аудио, видео и текст. Самые популярные из них:

Есть также много других медиаконтейнеров, например NUT, MPEG-1, MXF, GXF, ratDVD, SVI, VOB и DivX Media Format. См. также статью «Сравнение мультимедиаконтейнеров».

В дополнение к «чистым» контейнерным форматам, которые определяют только «обёртку», а не алгоритм кодирования, есть некоторые файловые форматы, которые определяют и слой хранения, и слой кодирования, как часть модульного дизайна и для совместимости «снизу вверх». К таким медиаконтейнерам относятся JPEG File Interchange Format (JFIF) для JPEG-изображений и Portable Network Graphics (PNG).

Таких программ на самом деле немало. Это AutoCAD, Photoshop, Microsoft Office (будем честными: даже пытаясь протащить его через ISO, «мелкомягкие» рассчитывали, что он будет совместим в первую очередь с самим собой).

И для простоты добавим ещё одно требование, которое отбросит все три этих программы, но довольно реалистичное (ему отвечают Windows 10 и куча программ помельче).

программа разрабатывается по непрерывной схеме, так что нет денежных барьеров обновляться, а достаточно старые версии программы по факту неподдерживаемые.

Я долго искал программу, которая отвечает всем этим требованиям, и наконец нашёл: Inkscape. Несмотря на то, что её файлы основаны на стандарте SVG, половина всей информации лежит в расширениях SVG — пространствах имён «sodipodi» и «inkscape».

В первой части постараюсь обойтись без программирования, зато объясню парочку важных концепций.

Собственно, у нас есть такие возможные форматы для хранения информации.

Формат первый. XML

Из форматов, доступных из коробки, самый распиаренный — XML. Если правильно писать код разбора, часть задач по обратной совместимости решаются автоматически: старая программа пропустит все лишние тэги. Остаётся сделать, чтобы новая читала документы, созданные старой — и дело в шляпе.

[+] Много стандартного инструментария.
[+] Оптимальный выбор, если мы храним размеченный текст.
[±] Можно (хотя и тяжело) редактировать файл вручную.
[−] Разбор может занимать много времени — от 20 до 95% всего времени загрузки. Эту неоптимальность даже обозвали «налогом на угловые скобки». По опыту загрузки (не полной) XLSX собственными силами: раззиповка — 0,3 с, разбор XML — 1,1 с, остальное — 0,6 с.
[−] Программировать своими силами очень опасно, возможны незаметные ошибки.
[−] Зачастую избыточен.
[−] Если в программе есть огромные массивы из малюсеньких объектов (звуковые волны, картинки, матрицы чисел), их приходится сохранять не-XML’ными мерами. Посмотрите, например, как хранятся кривые в SVG:

Будьте готовы к тому, что XML будет громадный, подчас больше, чем ваш документ занимает в памяти. Хотя не стоит так бояться больших файлов: обещаю, мы не будем грузить такую громадину в память.

Каким образом? Я знаю четыре подхода к чтению XML: на callback’ах (SAX), на потоках (StAX), на сопрограммах и DOM. А также два подхода к записи XML: прямая запись тэг за тэгом и DOM.

Чтение на callback’ах даёт сложный и путаный код, напоминающий конечный автомат. DOM расходует памяти в разы больше, чем структура предметной области. Сопрограммы — сложное дело и есть не везде. Так что наш выбор — чтение на потоках, запись тэг за тэгом. В обоих случаях расходуется пренебрежимо мало памяти, так что автоматически выполняется моё обещание не грузить громадину.

На языках, где мы управляем памятью вручную (Си), у потокового парсера есть ещё одна полезная черта. Управление памятью действует как унитазный бачок — потихоньку заполняется, мгновенно сливается — потому в самых быстрых из них действует собственное управление памятью. К сожалению, не получается добиться столь впечатляющей скорости, как в DOM (прежде чем выйти из функции getThing, надо «подобрать концы»). Так что у меня лично получилось (на Си++) сделать потоковый парсер в 2,5 раза медленнее, чем у рекордсмена PugiXML. Но это уже замечательный результат: научился грузить огромный XLSX втрое быстрее, чем Excel.

Формат второй. XML-лайты

«XML-лайтами» я называю языки наподобие XML, в которых единицы смысла — это строки текстового файла (иногда также агрегаты из нескольких строк). Наиболее известный — YAML.

Много лет назад, не накопав хорошего XML-инструментария для Delphi, за полдня я придумал XML-лайт с тупым названием Multilevel. Правда, тогда по неопытности работал только с DOM-разбором.

[+] Достаточно быстры.
[+] Редактируются вручную.
[±] Думаю, можно подобрать подходящий формат для огромных массивов из малюсеньких объектов.
[±] Легко запрограммировать своими силами.
[−] Даже если формат известный, вроде YAML, велика вероятность, что найдутся только DOM-подобные механизмы.
[−] Малопригодны для размеченного текста (и то придётся специально продумывать подходящий формат).

Формат третий. Двоичные XML-подобные коды

XML — формат текстовый. Но ничего не стоит перевести его в двоичный вид. Вот наобум придуманный XML-подобный двоичный формат (порядок байтов для наглядности взят Motorola):

На XML бы это выглядело так.

Я не открываю Америку, формат BIFF из Microsoft Office существует лет тридцать. Компания облажалась в двух местах: 1) Формат не иерархический, что сильно мешает дробить блоки; 2) блок ограничен 64 килобайтами, что решается вторым, третьим и т.д. блоком CONTINUE.

Недавно для целей медиаконтейнера Matroška сделали язык EBML — тот же XML, но двоичный. Конкретно с ним не знаком.

[+] Крайне быстры.
[+] Тэги, скорее всего, будут достаточно коротки, чтобы размеченный текст отнял даже меньше места в файле, чем в памяти.
[±] Легко запрограммировать своими силами.
[±] Огромные массивы из малюсеньких объектов можно сохранять как есть, в двоичном виде.
[−] Ручному редактированию не подлежат, для отладки потребуется программа-дампер.

Прочие форматы (и их недостатки)

Эти форматы лучше даже не рассматривать.

Текстовый или двоичный формат без расширяемой иерархической структуры нечего и придумывать. Раз мы хотим расширяемость — программа скоро вылезет из него, как из детской кроватки.

UPD. Чем плоха рефлексия? Костылями при серьёзных изменениях структуры файла.

SQLite продвигает свой формат БД как формат документа. По-моему, из-за сложностей программирования с ним имеет смысл работать именно как с СУБД.

JSON несколько проще в программировании, чем XML, но всё равно сложен. Плюс затруднено потоковое считывание: JSON различает объекты и массивы, и синтаксис JS говорит, что от перестановки атрибутов результат не меняется.

Хотя JSON подсказывает нам одну важную идею. А именно…

Идея 1. Или последовательность, или коллекция

Нашу жизнь очень сильно упростят два важных требования.

Любой тэг должен быть или последовательностью тэгов/блоков, или коллекцией тэгов/блоков. Объясню, что это такое.

Последовательность — это когда каждый сын повторяется не более одного раза и знает своё место. При этом возможны необязательные или взаимоисключающие.
- В терминах регулярных выражений — что угодно без дублей и операции «повторить». Например, AB [C] (D | [E]F) G .
- Неизвестные тэги, замеченные в последовательности, пропускаются.
- Пример: тэг <html>будет последовательностью из <head> и <body> .
- Неизвестные тэги, замеченные в коллекции, пропускаются или вызывают ошибку по желанию программиста.
- Пример: тэг <body>будет коллекцией из (почти) всех возможных тэгов HTML. Тэг <tr> содержит только <td> и <th> .
Примечание. Я понимаю, что в HTML оба этих тэга, td и th, можно использовать как непарные, браузер разберётся. Но давайте будем считать, что имеем дело с XHTML и эти тэги парные.

А вот совершенно не подходит под нашу модель тэг table . В официальной документации он описан как [caption], [title], [summary], ( col* | colgroup* ), (( [thead], [tfoot], tbody+ ) | ( tr+ )) — не похоже ни на коллекцию, ни на последовательность. Я понимаю разработчиков: HTML-то пишется в первую очередь руками. Но в машиночитаемом формате лучше так не делать.

Делая коллекцию дочкой коллекции, надо чётко осознавать риски. Тэг table в одном из вариантов будет коллекцией тэгов tr . А он, в свою очередь, коллекция из td и th . Если вдруг, случись что, в tr появится какой-нибудь тэг tx , с большой вероятностью оборвётся совместимость.

Как бы мы переписали нашу несчастную таблицу под машинное сохранение?

Но при этом мы чётко понимаем, что внутри коллекции tbody находится коллекция tr. Но таблица — она двухмерная, и крайне мала вероятность, что внутри tr вставят что-то не являющееся клеткой таблицы — так что закрываем на это глаза.

А вот в нашем простом иерархически-двоичном формате так нельзя. Причина в том, что у тэга XML есть атрибуты, куда, если что, можно закинуть немножко информации. А у каталога двоичного формата нет ничего — потому в этот самый tr не впишешь никаких новых данных: ни стиля, ни соответствия электронного документа и бумажного источника… Потому приходится полностью исключать коллекции в коллекциях.

Выносите отдельные сущности, особенно необязательные, в тэг-контейнер. Заголовок к таблице можно описать двумя способами:

Второй лучше — больше места для расширения. Может, вы когда-нибудь станете оформлять части заголовка жирным и курсивом. А может, будут два заголовка (например, в начале таблицы и в продолжении, если её разорвало на две страницы). Кто знает?

Впрочем, <table /> вполне себе катит: ссылка на стиль — свойство, заголовок, висящий где-то на мониторе — сущность.

Идея 2. Extend, upgrade, break. Или расширить, модернизировать, порвать

Какую бы мы ни придумали конструкцию — когда-нибудь мы из неё вырастем. Пусть у нас редактор простейших уровней, например, для Super Mario. Изначально там был один «мир» (скажем, лес). Делаем так, чтобы были два, три и больше миров. Как это будет выглядеть в XML?

Новую программу можно научить открывать старый формат. Но старая программа не откроет нового. И тогда я предлагаю трёхстадийный «мягкий переход». Сколько длится каждая из стадий — зависит от того, насколько сложен формат, как вы заставляете пользователей обновлять программу и как вы готовы тестировать её на проектах старых версий.

(название намеренно сделано похожим на Microsoft’овское Embrace/Extend/Extinguish, да и суть та же).

Расширить: программа пишет старый формат, если в игре один мир, и в новый, если много.

Примерно через полгода-год происходит фаза Модернизировать: программа начинает писать только новый формат, всё ещё читая оба.

И наконец — может, через год-полтора, может, когда руки программиста снова дойдут до этого места и потребуется очередное расширить — даём приказ порвать: перестаём даже читать старый формат.

Идея 3. Работая с текстовыми файлами, используйте нейтральную локаль

«Странно», — подумал я, но девочка из ПФР оставила ман в сто страниц А4. Решив начать по-хорошему, я сел и стал его вдумчиво курить. Где-то на 40-й странице я наткнулся на указание сменить стандартный разделитель целой и дробной частей в винде на запятую, иначе программа не будет работать. Открыл, смотрю — ага, всё верно. Сменил на точку — программа ФОМС заработала, но перестала работать программа ПФР, выдавая всю ту же ошибку сохранения данных. Теперь пожилая женщина-кадровик обучена переключать разделитель, а я проникся небывалой нежностью к отечественным программистам.

Идея 4. Как синхронизировать версии программы у сотрудников, работающих над одним документом

Обычно это важно для внутренних утилит. Часто бывает, что несколько человек работают над одним документом разными версиями программы, и не все вовремя обновляют, отсюда мелкие потери данных. Предлагаю такой тэг.

Цифру partlyCompatibleWith поднимаем до текущей, когда делаем extend или break в чём-то важном. Можно её устанавливать умно в зависимости от того, сохраняли мы в старом формате или нет. Цифру fullyCompatibleWith поднимаем, когда добавляем любой тэг.

Если файл загружен программой версии меньше 25, вывести: «Настоятельно рекомендуем обновить программу. Есть вероятность, что важные данные потеряны».

Если файл загружен программой версии меньше 40, вывести: «Рекомендуем обновить программу. Есть вероятность, что какие-то данные потеряны.»

Если файл загружен какой-то очень новой программой, чей partlyCompatibleWith больше 42, тоже можно что-то вывести.

Если библиотека разбора под вашим контролем, можно поступить и так: если хоть один тэг был прочитан кодом загрузки не полностью, вывести предупреждение. Но делается это, повторяю, на уровне библиотеки разбора.

Также в новых версиях программы можно хранить чёрный список версий, которые часто падают или портят файлы — если замечено, что savedWith в чёрном списке, тоже что-то вывести.

Медиаконтейнер, мультимедиаконтейнер (англ. Media container ) — формат файла или потоковый формат (поток, в отличие от файла, не является предметом хранения), чьи спецификации определяют только способ представления данных (а не алгоритм ирования) в пределах одного файла. Медиаконтейнер определяет размер и структуру представляемых данных, вместе с тем он не определяет никакую ификацию самих данных. Медиаконтейнер фактически является метаформатом, так как он хранит данные и информацию о том, как данные будут сохраняться внутри файла. Как следствие, программа, которая способна корректно идентифицировать и открыть файл (прочитать поток), записанный в каком-либо формате, впоследствии может быть не способна деировать фактические данные, записанные внутри медиаконтейнера, так как или метаданные в медиаконтейнере являются недостаточными, или программное обеспечение неспособно деировать данные, заированные в медиаконтейнере.

В теории формат-контейнер способен хранить любой тип данных, однако на практике для каждого типа данных существуют отдельные группы контейнеров. Эти группы «настроены» для специфических требований и информации, которая будет сохраняться в них. Медиаконтейнеры являются типичным примером такой группы файловых контейнеров, которые предназначены для сохранения медиаинформации, которая условно делится на изображения, видео и аудио. В случае фильмов медиаконтейнер должен не только сохранять видео- и аудиопоток, но и метки для их синхронизации при воспроизведении. В медиаконтейнере может сохраняться несколько однотипных потоков, например фильм (видеопоток) с несколькими звуковыми дорожками (аудиопотоками) и субтитрами (текстовыми потоками).

Контейнер файла используется для идентификации и чередования различных типов данных. Более простые контейнерные форматы могут содержать различные типы звуковых данных, заированных определённым еком. Более сложные медиаконтейнеры могут поддерживать множественные аудио- и видеопотоки, текстовые субтитры, информацию о разделах (англ. chapter ), метаданные (теги), наряду с информацией для синхронизации воспроизведения различных потоков одновременно. В большинстве случаев заголовок (англ. header ) файла, большинство метаданных и синхронизационные данные определены форматом контейнера. Например, есть контейнеры, оптимизированные для видео низкого качества с низким битрейтом, а есть контейнеры, оптимизированные для больших файлов, содержащих множество потоков высокого качества.

Составные части контейнера файла имеют различные наименования. В RIFF и PNG их часто называют chunks (куски), в MPEG-TS их называют packets (пакеты), а в JPEG они называются «segments» (сегменты). Основной контент данных составных частей называется «данные» или «полезная нагрузка». В большинстве контейнерных форматов каждая составная часть в последовательности имеет свой заголовок (англ. header ), в то время как медиаконтейнер TIFF вместо этого сохраняет смещения, что приводит к трудностям в сохранении информации. Модульные составные части облегчают восстановление других составных частей в случае повреждения файла или при «выпадении» кадров или при bit slip ( англ. ) .

Некоторые медиаконтейнеры предназначены для сохранения только аудиоданных:
Некоторые медиаконтейнеры предназначены для сохранения только статических изображений:
Большинство медиаконтейнеров приспособлено для сохранения всех или почти всех типов медиаинформации, включая аудио, видео и текст. Самые популярные из них:

Есть также много других медиаконтейнеров, например NUT, MPEG-1, MXF, GXF, ratDVD, SVI, VOB и DivX Media Format.

В дополнение к «чистым» контейнерным форматам, которые определяют только «обёртку», а не алгоритм ирования, есть некоторые файловые форматы, которые определяют и слой хранения, и слой ирования, как часть модульного дизайна и для совместимости «снизу вверх». К таким медиаконтейнерам относятся JPEG File Interchange Format (JFIF) для JPEG-изображений и Portable Network Graphics (PNG). Такие полнофункциональные медиаконтейнеры (хотя понятие «медиаконтейнер» к ним не совсем применимо) называются «Single coding format» (рус. Единый формат ирования ).

Все различия между разными медиаконтейнерами происходят из пяти основ:
- Популярность. Насколько распространён и поддерживается данный контейнер.
- Размер файла. Показывает различие в файловом размере между двумя файлами, которые имеют одинаковый контент, но сохранены различными медиаконтейнерами.
- Поддержка расширенной функциональности ека. Старые медиаконтейнеры, такие как AVI, не поддерживают новые особенности еков, такие как B-кадры, переменный битрейт аудиопотока и переменную частоту кадров видеопотока. Контейнер может быть «взломан» для добавления поддержки, но это создаёт проблемы совместимости.
- Поддержка расширенного контента. Поддерживает ли медиаконтейнер разделы, субтитры, мета-теги и пользовательские данные.
- Поддержка потокового мультимедиа.
Remux (ремультиплексирование) — принятый в сфере видеоирования термин, означающий перекомпоновку содержимого медиаконтейнера. Его важной особенностью является отсутствие переировки (сохранение исходного качества) основных элементарных потоков (видео- и аудиопотока). Заменяется лишь медиаконтейнер, также могут добавляться или удаляться субтитры, меню, множественные аудиопотоки (дополнительные звуковые дорожки) и прочие второстепенные данные.

ПОДГОТОВКА К ВИДЕОМОНТАЖУ

Введение Прежде чем приступить к монтажу видеофильма на компьютере при помощи специальной программы-видеоредактора, необходимо: перенести отснятый материал на компьютер в виде файлов убедиться, что формат полученных файлов воспроизводится на компьютере и открывается выбранным вами редактором при необходимости конвертировать видео в поддерживаемый формат Данное занятие посвящено основам оцифровки видео, особенностям его хранения в файлах, форматам видеофайлов и основам работы с программой-конвертером.

Способы переноса видео на компьютер Способ переноса отснятого материала на компьютер зависит от того, цифровая и аналоговая у вас камера, и какой носитель информации в ней используется. Проще всего с современными цифровыми камерами, сохраняющими готовые видеофайлы на карте памяти или HDD. Файлы можно просто скопировать, подсоединив камеру к компьютеру при помощи интерфейсного кабеля. Можно также извлечь карту памяти и воспользоваться кардридером. Если цифровая камера пишет материал на кассету или диск, то перенос осуществляется при помощи прилагаемого к камере программного обеспечения через интерфейсный кабель. С диска видео на компьютер можно перенести также с помощью специальной программы – DVD-риппера. Более хлопотна процедура переноса материала с аналоговой камеры. Здесь потребуется специальное устройство – TV-тюнер и программное обеспечение. Последнее может прилагаться к тюнеру или устанавливаться отдельно (большинство программ для редактирования видео поддерживает и функцию захвата с камеры).

Программы для захвата видео Чаще всего прилагаются к устройству видеозахвата. Наиболее известны платы видеозахвата Pinnacle Studio. Кроме того, как уже говорилось, большинство видеоредакторов имеют модуль захвата видео. После того, как провода от видеокамеры или магнитофона присоединены к TV-тюнеру, можно запускать программу видеозахвата. Интерфейс таких программ различен, но всегда включает в себя как минимум панель управления и окно просмотра видео. В данном занятии настройки захвата видео показаны на примере программы LifeView TVR, которой укомплектован TV-тюнер FlyTV Prime. Интерфейс программы LifeView TVR Панель управления Окно просмотра видео

Настройки захвата видео Для захвата видео прежде всего необходимо указать, с какого устройства будет производиться воспроизведение видео, а с какого – звука (звуковой кабель можно подключить не к TV-тюнеру, а на вход звуковой карты, а можно и не подключать вовсе). Если источники сигналов выбраны правильно, в окне отображения видео видно то же, что и в видоискателе (на дисплее) камеры, а из колонок слышен звук. Текущие настройки отображаются на панели управления (см. рисунок). Начало записи Текущий источник видео Вызов настроек Кнопки выбора источника видео Текущий размер выходного файла Текущая длительность захваченного видео

Настройки сохранения видео При захвате видео самыми важными настройками являются формат записываемого файла и битрейт. Не забудьте также указать, где будет сохранен получившийся файл. Выбор формата зависит от того, для чего планируется использовать файл в дальнейшем, а также от качества исходного видео. Например, не имеет смысла сохранять в DVD-формате запись, снятую на камеру VHS-C - качество останется на уровне исходных 320 линий. Формат определяет разрешение конечного файла и используемый способ сжатия. Битрейт – скорость передачи информации. Чем она выше, тем качественнее сигнал и больше объем конечного файла. После выставления всех настроек можно нажимать кнопку «запись» и отслеживать сохранение захватываемого видео в виде файла

Формат видеофайла После переноса видео на компьютер мы получим набор видеофайлов определенного формата. Из курса информатики мы знаем, что формат файла определяется способом кодирования информации. О формате файла нам говорят 3 буквы (очень редко их 2 или 4) после точки в конце имени файла – так называемое расширение. При этом значок, которым обозначается файл, говорит не столько о его формате, сколько о том, какой программой он будет открываться. Часто файлы разных форматов обозначаются одинаковым значком – если за их открытие на данном компьютере отвечает одна программа Чаще всего, встречающиеся нам видеофайлы имеют расширения: Особенности этих файлов будут рассмотрены чуть дальше

Мультимедийный контейнер Видеофайл больше всех видов мультимедийных файлов предполагает совместное сохранение разных типов данных. Как минимум, это картинка и звук. Поэтому видеофайл обычно сохраняется в виде контейнера мультимедийных данных или медиаконтейнера. Медиаконтейнер — формат файла или потока, чьи спецификации определяют только способ сохранения данных (а не алгоритм кодирования) в пределах одного файла. Видео и звук в контейнере могут быть сохранены самостоятельно, с использованием различных алгоритмов сжатия. Контейнеров для хранения видео довольно много: 3GP, ASF, AVI, IFF, MKV, MP4, MOV, OGG, OGM, RealMedia, VOB, DivX и т.д., особенности некоторых из них будут рассмотрены чуть ниже. Видеофильм.AVI – заголовок файла Метаданные, параметры синхронизации дорожек Видеоряд, сохраненный с использованием одного из алгоритмов сжатия видео (например, MPEG2) Звуковая дорожка, сохраненная с использованием одного из алгоритмов сжатия звука (например, MP3) Пример структуры медиаконтейнера

Извлечение данных из медиаконтейнера Для разделения и извлечения из медиаконтейнера отдельных дорожек, необходима специальная программная библиотека – сплиттер. Извлеченные дорожки представляют собой звук и видео, закодированные также специальными (часто различными) программными библиотеками – кодерами (энкодерами). Для их раскодирования при воспроизведении требуется еще один вид программных библиотек – декодер. Как правило, кодер и декодер соединены в единый программный модуль - кодек. Отсутствие на ПК или ином воспроизводящем устройстве сплиттеров или кодеков, при помощи которых сохранялась информация в видеофайле, приведет к тому, что видеофайл будет воспроизводиться с ошибками, искажениями или только частично (например, звук есть – а изображения нет).

Наиболее распространенные форматы файлов и контейнеров с видео AVI (Audio Video Interchange – «чередование видео и аудио») – один из первых медиаконтейнеров, впервые использован Microsoft в 1992 г. Файлы в этом формате содержат сохраненные отдельно видео и аудио данные, сжатые с использованием разных комбинаций кодеков, что позволяет синхронно воспроизводить видео со звуком. MPEG–1 – формат сохранения видео на VCD (видео CD) MPEG–2 – в отличие от AVI, используется для "общего сжатия движущихся изображений и звука" и определяет формат видеопотока, который может быть представлен как группы кадров трех типов — независимо сжатые кадры (I-кадры), кадры, сжатые с использованием предсказания движения в одном направлении (P-кадры) и кадры, сжатые с использованием предсказания движения в двух направлениях (B-кадры). MPEG-4 – усовершенствованный вариант формата MPEG, обеспечивающий более сильное сжатие. Аудио потоки, видео и аудиовизуальные данные в этом формате могут быть как записаны на видеокамеру или микрофон, так и созданы с помощью компьютера и специального программного обеспечения. WMV - название системы видео кодирования, разработанной компанией Microsoft для хранения и трансляции видеоинформации во внутренних форматах Microsoft. Звук кодируется в формате WMA. Данные в форматах WMV и WMA могут содержаться в контейнере с расширением ASF.

Наиболее распространенные форматы файлов и контейнеров с видео (окончание) MOV - разработан фирмой Apple, изначально предназначался для использования на компьютерах Macintosh, потом был перенесен в ОС Windows. Степень сжатия довольно велика, но качество фильма не очень высоко. До недавнего прошлого воспроизводился только через Apple Quick Time Player, теперь поддерживается рядом проигрывателей. В этом формате сохраняют видеоролики и некоторые цифровые фотоаппараты. VOB (Video OBject) - контейнер, содержащий видеофильм в формате MPEG-2. Один из форматов для DVD. Для воспроизведения на компьютере, как правило, требуется специальный программный DVD-проигрыватель (например, Cyberlink Power DVD) FLV (Flash-Video) - медиаконтейнер, используемый для передачи видео через Интернет. Видео кодируется различными кодеками, звук обычно в МР3. Формат FLV предназначен для потокового видео (просматриваемого на интернет-странице), однако существует возможность использовать его для локального хранения и воспроизведения видео (например, при помощи Riva FLV-player). 3GP (3rd Generation Phone) - Видео и аудио для мобильных телефонов третьего поколения. Видео файлы в этом формате имеют сравнительно малый размер, но это сильно отражается на качестве. Для воспроизведения используются проигрыватели, входящие в составе программного обеспечения, поставляемого в комплекте с телефоном.

Сплиттеры и Кодеки Как уже было упомянуто, для извлечения мультимедийных данных из котейнеров и дальнейшего воспроизведения используются специальные программы – сплиттеры и кодеки. Сплиттеры существуют для каждого типа контейнеров, часто они встраиваются в мультимедийные проигрыватели. Кодеков же великое множество: ffdshow, indeo, mjpeg, DivX, DV Video Encoder, Helix, indeo, PCM, Cinepak, H263, H264 (MPEG4), Windows media, Xvid и т.д., и т.п… Для большинства применений выгоднее кодеки, сжимающие данные с потерями части информации - малозаметное ухудшение качества оправдывается значительным уменьшением объема файла. Существуют также кодеки, сжимающие без потерь (наиболее распространен MJPEG), которые можно использовать, когда видео планируется редактировать. Но в этом случае нужно быть готовым к тому, что 1 с. видео займет более 25 Мб. Рядовому пользователю, чтобы не заморачиваться с подбором нужного кодека, можно установить на компьютер готовый набор кодеков, так называемый кодек-пак (Kodec-Pack), например K-Lite. Правда, в этом случае возможны проблемы, связанные с тем, что в кодек-паке для одного формата видео присутствует несколько кодеков. Это может привести к проблемам с автоматическим выбором нужного при воспроизведении. Однако, в кодек-паках обычно имеются и средства настройки, позволяющие решать такие проблемы.

Конвертирование видеофайлов Если формат полученного или скачанного из интернета видеофайла не поддерживается на данном компьютере и файл не воспроизводится имеющимся проигрывателем или не открывается в редакторе, такой файл можно попытаться конвертировать – преобразовать в другой формат. Для этого используются специальные программы – конвертеры. Программ-конвертеров мультимедиа существует довольно много, как коммерческих, так и бесплатных. Некоторые специализируются только на переводе файлов из одного конкретного формата в другой (AVI-MPEG, MOV-AVI и т.п.). Некоторые содержат набор заготовок, для создания файлов, воспроизводящихся на конкретных типах устройств (например Quick Media Converter, специализирующийся на создании файлов для воспроизведения на сотовых телефонах и портативных мультимедийных проигрывателях). Естественно, есть и комплексные решения, предлагающие широкий набор поддерживаемых форматов. Они позволяют методом проб и ошибок выбрать оптимальные параметры создаваемого файла, в зависимости от того, для чего вы хотите его использовать.

Заключение Итак, для видеомонтажа необходимо: - перенести нужные видеофайлы с видеокамеры и скачать из интернета . - материал рассортировать, собрать в отдельной папке, дополнить изображениями. - ролики просмотреть, при необходимости конвертировать в формат, поддерживаемый используемым видеоредактором. Наступает момент открыть фрагменты фильма в редакторе, соединить их в нужной последовательности, дополнив музыкой, титрами, эффектами и видеопереходами.

Читайте также: