FAQ по созданию и редактированию цифрового видео

Для чего все это написано и как появилось на свет?

Я попытался суммировать переписку с читателями моего давнего обзора карты Matrox Rainbow Runner G series & Mystique G200, опубликованного на iXBT.com. Сначала переписка была посвящена только этой карте, но, поскольку я перестал ей пользоваться и перешел в поклонники чисто цифрового видео, то большинство вопросов в переписке затрагивали именно DV формат и разумные способы перехода на него.

Попутно мне пришлось пофилософствовать на темы цифрового видео вообще.

Должен предупредить, что все написанное в этом сборнике вопросов и ответов ни в коей мере не претендует на истину в последней инстанции. Я не являюсь профессионалом, добывающим средства на жизнь изготовлением видеороликов. Кроме того, я не вхожу ни в какие тайные общества бета-тестеров и все свои выводы делаю только на основе впечатлений о работе с купленными в магазине картами. Так как я потратил на них свои собственные деньги, которых редко бывает много, то всякая подобная покупка сопровождалась длительными раздумьями, поисками сведений и сравнениями. В результате этого анализа делался вывод. Мне показалось, что информация об основаниях выбора будет интересна многим читателям. Тем более, что финансовые возможности многих из нас заставляют хорошо думать перед покупками весьма дорогих "игрушек".

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

Вся представленная информация может не иметь никакого смысла для людей, занимающихся видеомонтажом профессионально. Поэтому заранее прошу не приводить в аргументах ссылки на параметры профессиональных устройств. Они большинству из нас просто не по карману.
Если вы занимаетесь видеомонтажом не для создания домашнего архива, многие из выводов могут тоже показаться спорными. Я руководствовался соображениями оптимального для меня соотношения затрат и результата. Найденный таким способом оптимум всегда основывается на многих личных особенностях и обстоятельствах.
Я попытаюсь написать и о некоторых основах видео вообще и так, как я это понимаю сам. В описаниях я постараюсь быть предельно доходчивым, иногда в ущерб 100% точности. Дело в том, что найти даже такие пояснения может быть довольно трудно, а без них делать видеомонтаж с приличным качеством часто бывает непросто.
Я также выскажу свои соображения по поводу создания предельно дешевой конфигурации для видеомонтажа. В последнее время произошли столь большие изменения в параметрах и цене винчестеров, что ставшие уже привычными представления заметно изменились.

В обновлении от конца 2001 года, которое вы сейчас и читаете, я решил оставить вводную часть без изменений. В целом, ситуация на рынке устройств для домашнего видеомонтажа на удивление мало изменилась. Самым серьезным изменением стало появление весьма дешевых IEEE1394 контроллеров, сделавших работу с DV видео доступной очень многим владельцам таких камер. Да и DV камер стало больше и, вероятно, и увеличилась их относительная доля у владельцев устройств видеосъемки.

Никаких серьезных изменений в подходах к видеомонтажу на компьютере такие события повлечь не могут. Массовый (надеюсь) переход на изготовление полноразмерного видео высокого качества делает представленные ниже сведения о полях в видеосигнале и приемах работы с ними только более актуальными.

Тем не менее, обзор все же сильно переделан. Я постарался убрать ссылки на конкретные устройства там, где это не принципиально или может ввести в заблуждение. Например, у меня нет никаких оснований утверждать, что именно фирма XXXX делает лучшие TB тюнеры, поэтому нет смысла называть имена, тем самым (возможно) незаслуженно не хваля конкурентов этой фирмы.

Еще одним серьезным изменением стало появление быстрых программных кодировщиков видео в форматах MJPEG, DV и MPEG2. Возможность компрессии в реальном времени потока данных полноразмерного оцифрованного видео в первые два формата заметно поменяла подход к дешевому решению для работы с аналоговыми источниками сигнала. В эту же главку я вынужден был вставить ремарки относительно недорогих IEEE1394 карт, потому что эти два варианта сейчас одинаковы по затратам.

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

Беседа с недовольным читателем

Не исключаю того, что мое письмо останется без ответа: странно представить, что все "чайники" после первых проб с Premier'ом сразу все поняли и не кинулись искать что-нибудь более вразумительное, нежели творческие эссе Холмского и Иванова. Наверно и Вам досталось. Ух, ты, наконец-то! FAQ! Ан нет. Радость опять не про нас. Странно, что Вас не спросили. а Вы не ответили, немного скромничая:

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

А какие регистры и порты и -

Не знаю, потому что здесь пока нет вопроса.

Главное - как, пережевывают алгоритмы кодеков и вообще, что у нас с глазами? Будут они, наконец, различать, то что софт и проц уже давно могут для 3-го тысячелетия?

Я был бы рад, если бы Вы сформулировали вопрос, а я постарался на него ответить. Вообще говоря, все, что сделано в этом обзоре, сделано для меня самого. Я просто изложил на бумаге то, что сам понимаю. Такое изложение помогает мне самому понять, чего еще я не знаю и не умею.

А вопрос очень прост: где найти начало знаний о практической реализации идеи домашнего, любительского видеомонтажа? На что, в лучшем случае, я могу рассчитывать, имея Sony Handycam Video 8 CCD- TR380E PAL, видеокарту ASUS AGP-V3400 TNT, 64 метра с celeron'ом 450 (o/c 300a) на шине 100Мгц, ну и винт 10,2? А смотреть на обычном видике? Ведь, согласитесь, зачастую имеем, что имеем.

Я не могу указать источник начальных знаний нормального, с моей точки зрения, качества. Я сам не очень популярный писатель: некоторые главки обзора явно предполагают наличие начальных сведений. Мне трудно разделить, что ЕСТЬ очевидное, и что требует ответов. Мешает физтеховское образование, 25 лет радиолюбительства и 14 лет работы физиком. Вы задавайте именно конкретные вопросы, а я постараюсь сочинить ответ. Пока Ваш вопрос мне кажется не вполне конкретным. Вернее, вы хотите, чтобы я написал руководство пользователя именно вашей системы. Так не получится, потому что систем много, общего у них тоже, а различия приводятся к общему на основе поиска именно этого общего. Читайте часть моего FAQ о дешевой системе видеомонтажа. Там, вообще говоря, про вашу систему и написано. Только вид в профиль. Будут вопросы-уточнения - задавайте, отвечу.

Это потом, ну когда совсем захочется и будут деньги (оторванные от семьи, которая просто не понимает...)

Моя тоже... Странно, не правда ли? :)

Ну, а главное - вышеназванные корифеи от Премьера все начинают очень популярно, но дальше...

Видео само по себе - некоторая наука. Начинал я с прочтения популярных книжек про телевизоры еще лет двадцать пять назад. Позже читал с пристрастием про цветные декодеры, в эпоху их установки в советские телеящики. Без понимания основ именно телевидения можно делать кино типа анимации, но для просмотра его на телевизоре и с качеством нормального ТВ нужны знания основ. Я пытался неявно привлечь к этому внимание. Приходится думать о строках, полях, компрессорах, прочей ерунде, учитывать особенности их работы.

Представьте себе, что вы никогда не видели современную, да еще японическую, бензопилу и читаете популярные записки о том. как классно и захватывающе вы будете валить лес (следуют описания природы, сортов топлива и марки стали для зубов, назначения кнопок и ручек, что они умеют), а потом резко советы типа - дышите лучше всего носом, не пользуйтесь халявным бензином и тд. Скажите, вы когда начнете пилить, не узнав как? И так шоб не плюнуть и только слышать(читать), что в Инете люди говорят. Что и говорить, технология это завсегда мое, а я вот тебе расскажу, как капиталисты научили. Какие книги переводим, да только про кнопочки :( Ну ладно книжки, но в FAQах?!

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

Кнопочки описывать в популярных книжках - это и правда халтура.

Я еще раз хочу повторить - весь этот FAQ родился как слегка систематизированная свалка моих ответов на задававшиеся мне вопросы. Будут новые вопросы - буду отвечать. Про бензопилу все правильно, но я начинал именно с Вашей конфигурации (названия несущественны). Появились деньги и умение отличать VHS от DV по качеству - купил то, о чем написал.

Я понимаю - мой спич не по адресу, потому и (см. начало). Но в Одессе говорят - спросите и вам обязательно ответят... : "Никого нет дома"
Прочитали и на том спасибо. И успехов Вам!

Еще раз - дайте себе труд сформулировать не вопрос типа "скажите, а на фига я все это купил и что теперь я с этим сделать могу?", а попробуйте сделать что-нибудь, запишите вопросы с конкретными затруднениями, и перешлите мне. Я отвечу.

Разумеется, все написанное выше не относится к корреспондентам, задающим обычные вопросы.

Video: Как хранить?

Как хранить видео после обработки и монтажа на компьютере (т.к. на CD-RW больше 15-20мин MPEG-2 не поместится, а пишущие DVD пока не доступны).

Хранить готовое видео я рекомендую на CD в формате MPEG2. По качеству, потери можно минимизировать выбором программы кодирования и его параметров. Я пробовал сравнивать на телевизоре клипы сделанные следующими способами:

исходный DV
DV => MPEG2 5300 kbps => DV (программно) => D8 камера
DV => MPEG2 5300 kbps => Hollywood+ MPEG2 decoder TVout (Svideo) => D8 камера

Если очень внимательно смотреть на 25" телевизор Sony (композитный вход) то, конечно, можно заметить разницу между вариантами 1 и 2(3). Если постараться сделать яркость/контраст/насыщенность одинаковыми - то довольно трудно. Типичные дефекты выглядят как повышенный шум видео на быстро меняющихся сценах.

Между вариантами 2 и 3 вообще нет разницы, кроме едва заметного окрашенного шума на темных местах для аналогового варианта. Таким образом, это видео можно впоследствии использовать и для новых видеоклипов почти без потери качества.

Сейчас появились на рынке относительно дешевые устройства записи на носителях, совместимых с DVD проигрывателями. Однако стоимость хранения минуты видео пока далека от той, которая уже установилась для CD. Можно надеяться на значительное удешевление DVD – подобной технологии хранения данных в будущем, но пока для домашнего видеоархива у CD нет альтернативы.

Среди множества вариаций MPEG стандартов я рекомендовал бы придерживаться именно MPEG2 или MPEG1, то есть форматов, специально разработанных, как потоковые. К их достоинствам по сравнению с AVI форматом (включая популярные MPEG4 кодеки) относятся в первую очередь:

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

Последнее обстоятельство делает пригодными для хранения MPEG потоков носители, не гарантирующие восстановление информации в полном объеме, например, магнитную ленту DV видеокамер. Уже сейчас предпринимаются попытки создания программ, позволяющих хранить подобного рода данные на DV носителях. Пока такие программы не очень надежны и постоянно модифицируются, но мне кажется, что возможность хранения 13-14 ГБ потоковых данных, уже реализованная в DV, в скором времени будет обязательно использована и для более эффективно сжатого видео.

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

Производители вынуждены предлагать варианты хранения только видеоданных, делая доступным лишь хранение MPEG данных на ленте. Например, JVC выпустила видеомагнитофон обратно совместимого формата DVHS для домашнего видео. DVHS кассета размером с обычную VHS – от 7 до 28 часов видео. См. ссылку. MPEG2 формат, прямое кодирование из аналогового и из DV. Bitrate - 4.7 or 14.1 mbps. Это много. Если аппаратный кодировщик от C-cube хотя бы средний по качеству (см. сравнения на www.tecoltd.com), то качество в коротком режиме будет просто неотличимо от DV. Уже присутствует на европейском рынке. Из описания я так и не понял – имеется ли возможность копировать в это устройство MPEG2 файл собственного изготовления. Наличие же шины IEEE1394 означает только возможность перекодирования DV потока в MPEG, но не хранение самого DV оригинала на кассете удобного формата. А жаль.

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

Если бы еще не Голливуд со своей борьбой за доходы от DVD дисков, всячески мешающий принятию каких-либо стандартов, уменьшающих эти доходы хоть на 0.001%, мы давно получили бы устройства хранения домашних видеоархивов за разумные деньги.

Идиотическим примером является ставшая уже историей маниакальная реализация в Matrox Rainbow Runner G-series защиты от копирования Macrovision, срабатывавшая от обычных кратковременных выпадений сигнала на VHS кассетах.

Таким образом, хранение видео на CD до сих пор остается единственным надежным выбором.

Как можно попытаться увеличить длительность видео, помещающегося на один диск?

Если источником видео являлась VHS или Video 8 лента, попробуйте ограничиться хранением видео с размером кадра 480х576 или даже 352х576 и попытайтесь уменьшить поток данных до минимального, приемлемого для вас. Не следует обольщаться и пытаться делать SVCD диски, строго следуя этому стандарту. Я не верю в то, что он позволяет избежать заметной потери качества видео при ограничении потока данных скоростью в 2700 кбит/сек. Постараюсь объяснить свою позицию отдельно в разделе, посвященном MPEG.

Для видео, оригиналом для которого являлись ленты Hi8/SVHS, тоже может подойти указанный выше размер кадра. Что же касается DV, то для него все зависит от ваших предпочтений. Я обычно оставляю размер кадра полным, но не могу с уверенностью утверждать, что это заметно обыкновенным зрителям моих произведений.

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

В заключение рассуждений об архивах мне хотелось бы предостеречь от увлечения рекордами по продолжительности фильма на CD. Чудес не бывает, и всякое продвижение в этом направлении неминуемо снижает качество видео. Рекорд по минутам на один CD – это не то же самое, что рекорд по FPS для игровых приложений. На мой взгляд, хранить видео нужно с качеством не худшим, чем VHS.

Попробую сформулировать от себя спецификации видео в цифровой форме, которое можно считать аналогом VHS:

Размер кадра не менее 352х576, при отсутствии deinterlace фильтрации любого типа
Частота кадров 25 Гц (разумеется)
Отдельные кадры не содержат видимых на глаз типичных искажений от цифровой компрессии. То есть, контуры предметов не должны иметь ореолов (заметных с обычного для телевизионных просмотров расстояния), а кадры с быстрым движением (и другие тоже) – квадратиков, порождаемых компрессором при слишком сильном сжатии информации.
Видео в целом не должно выглядеть размытым более, чем это бывает на VHS копиях c VHS записей (то есть не хуже, чем после линейного редактирования оригинала с помощью камеры и видеомагнитофона VHS)
Не должно быть видно типично цифровых дефектов, вносимых иногда "интеллектуальными" фильтрами, типа temporal smoothing/noise reduction (фильтры, пытающиеся уменьшить поток данных в сжатом видео за счет избирательного замещения части кадра фрагментами предыдущего), чрезмерной адаптивной фильтрации шумов (фильтры, пытающиеся избирательно размывать части кадра, в которых соседние пиксели и так мало отличаются друг от друга) и им подобных. Наличие "компьютерных" составляющих может быть намеренным эффектом, но рывки в движении и какая-то "мутность" видео в целом могут полностью испортить впечатление от сюжета.
Не должно быть видно повышенной зашумленности видео, что происходит при достаточно больших потоках данных, когда "квадратики" уже почти незаметны на отдельных кадрах, но все же присутствуют и проявляют себя как шумы при проигрывании видео.
Дефекты кодека, такие, как подергивания или сильные искажения части картинки (обычно на краях, где компрессор безуспешно борется с дефектами сигнала самой видеокамеры размером в одну-две строки и в результате портит до 32 строк).
Должны быть установлены правильные уровни черного и белого, контраст, насыщенность, и цветопередача. Следует избегать ограничения сигнала снизу или сверху при оцифровке, которые приводят либо к обращению в черное значительной части темных деталей, либо к "выбелению" ярких частей исходного видео. Последнее сильно проявляется на кадрах с ярко освещенными солнцем лужайками, и приводит к превращению травы в бледно-зелено-белую субстанцию.

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

По моим представлениям, добиться такого качества можно при средних потоках данных не менее 2500 кбит/сек. Более реалистичная цифра – 3-4 Мбит/сек, если видео было снято с руки и оператор часто смещал камеру при съемке. А кто снимает по-другому собственных детей, членов семьи и собак?

Все видео, что не вписывается в указанные 8 пунктов, следует считать компьютерным. Я не утверждаю, что его не нужно делать или показывать. Но следует ясно осознавать, что это не VHS – подобное видео. Интернет-ориентированное видео - отдельная тема. Действительно, передать по электронной почте видеофайл с параметрами VHS нереально, не говоря уже про вещание через Интернет или даже по локальной сети. Но эти задачи не совсем подходят для домашних режиссеров, поэтому им не будет уделяться много внимания ниже.

Примечание для любителей использования этого материала в русскоязычной прессе СНГ, включая диски с пиратскими копиями программ и некоторые Интернет-сайты продавцов карт для видеомонтажа: приведенные выше соображения, хотя и основаны на здравом смысле и могут быть выведены из прочтения "общедоступной литературы", в комбинации из 8 пунктов являются моим собственным вымыслом (некоторые юристы имеют неосторожность называть это копирайтом). При цитировании в обзорах, представляемых от имени другого автора, необходима ссылка на первоисточник и на мое собственное имя.

Video: Требования к компьютеру для видеомонтажа

Что оптимально для оборудования рабочего места для монтажа фильмов с качеством VHS? Цифровая камера + компьютер или только компьютер со специализированной картой для работы с аналоговым видео? Каковы требования к компьютеру (CPU, RAM, etc)??

Каков источник вашего видео – VHS или SVHS/Hi8?

Между SVHS и VHS источниками видео имеется очень большая разница в качестве, которая особенно важна для последующей цифровой обработки.

Вы знаете, что потеря качества при простом копировании с одной VHS кассету на другую весьма заметна. Вы не можете избежать этого при цифровой обработке, если результат будет скопирован на VHS. Если исходное видео снято S-video камерой (Hi8 или SVHS/C), то результат на обычной видеокассете будет по качеству соответствовать нулевой копии. Для оцифровки S-video сигнала следует обязательно использовать S-video соединение с картой оцифровки. В случае использования VHS камеры, можно получить заметно лучшие результаты при оцифровке ее "живого" сигнала, минуя видеокассету, но это, как правило, невозможно.

Давайте перечислять:

1. Для достаточно комфортной работы с видео вы можете использовать любой компьютер с не менее чем 128 МБ памяти и процессором быстрее 500 МГц. Я сознательно не говорю о ценах, потому что такая информация быстро устаревает. Чем больше скорость процессора – тем лучше. PIII/Celeron 933 или аналогичные AMD процессоры уже достаточно быстрые для сжатия полноразмерного видео в реальном времени современными программными компрессорами MJPEG и даже DV (см. Picvideo MJPEG codec или Mainconcept DV или MJPEG кодеки).

2. 128 МБ памяти можно считать необходимым минимумом, допускающим использование одной программы редактирования или сжатия видео. Для переключения между одновременно работающими программами памяти нужно много больше. Некоторые MPEG компрессоры могут использовать до 256 МБ оперативной памяти, многие модули спецэффектов также требуют больших объемов памяти. Кроме них, в работе с видео часто используют специализированные программы 3D титрования, редакторы изображений. Если вы хотите переключаться между этими приложениями без 10-20 секундных ожиданий перерисовки экрана, поставьте 256 или больше мегабайт памяти.

Следует сказать, что все известные мне проигрыватели видео, программы его изначальной оцифровки не требуют много памяти. Я всегда смеюсь, когда читаю предложение поставить 1 ГБ памяти, чтобы решить проблему работы программы, не использующей более 10 МБ.

3. Диски. Вам понадобится много дискового пространства. При существующих ценах на винчестеры имеет смысл выбирать UDMA модели с наименьшей ценой за ГБ. Все современные диски имеют скорость линейной записи, достаточную для работы со сжатым видео при потоках данных как минимум 10 МБ/сек. Большинство новых дисков может писать и несжатое видео (20 МБ/сек), но я не уверен, что это удобно в использовании. При выборе дисков, помимо цены, хорошо было бы узнать статистику их надежности и (очень важно!) совместимости с контроллерами UDMA, которых теперь развелось великое множество.

Приведу пример из личного опыта. В моем первоначальном обзоре я хвалил диски FUJITSU как надежные, достаточно быстрые и тихие. К сожалению, мои восторги теперь можно отнести только к уже устаревшей серии MPC. MPE, MPF и MPG диски имеют много проблем при работе с UDMA 66/100 контроллерами разных сортов. Они могут проявляться как отсутствие DMA режима и невозможность его включить, ограничение по скорости записи (при нормальной скорости чтения) на уровне 4-5 МБ/сек, прочими неприятностями. В моем домашнем и рабочем опыте все подобные проблемы не проявлялись с дисками Western Digital и Seagate. Они правильно опознавались и работали с контроллерами от CMD, Promise, HighPoint и встроенными DMA66 контроллерами VIA чипсетов для PIII процессоров.

Еще раз повторю: возможные проблемы совместимости дисков и контроллеров могут быть очень неприятными при работе с видео. В качестве защитной меры я могу даже рекомендовать использовать только 40-жильные IDE кабели, сознательно ограничив скорость работы контроллера UDMA 33 режимом. Мне, во всяком случае, это иногда помогало, а уменьшение скорости работы дисковой подсистемы не было заметно.

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

Разумным минимумом для видеодиска следует признать 40 ГБ. Во-первых, такого объема достаточно для записи двух кассет часовой продолжительности в формате DV или MJPEG. Во вторых, при этом размере уже полгода как наблюдается минимум стоимости одного ГБ хранения информации. Не думаю, что этот порог как-то изменится скоро. Скорость вращения шпинделя – дело вкуса. Я до сих пор предпочитаю 5400 – шума и тепла меньше. Цена не столь существенна, хотя диски 7200 стоят дороже. Выбирайте модели с наибольшей плотностью записи в битах на см длины трека записи. На сайтах производителей часто приводятся какие-то комбинации, получаемые умножением или делением этого параметра и плотности треков на единицу радиуса. Попытайтесь вычислить нужную вам величину самостоятельно. Дело в том, что скорости вращения и радиусы дисков всем известны, поэтому только количество битов на см длины трека имеет значение для линейной скорости записи. Что же касается времени поиска дорожки, то эта величина может быть важной при сложном редактировании, когда головки постоянно переключаются на считывание данных из многих исходных файлов. Я не думаю, что вы сразу начнете делать видео наложением 25 дорожек. Даже если это и так, то основное время при генерации видео потратится не на чтение диска, а на просчет самих эффектов наложения. Так что мне до сих пор не кажется, что уменьшение времени поиска 7200 дисков приводит только к трате лишних денег и дополнительным заботам по охлаждению. Тесты ZDNET по производительности для Adobe Premiere безусловно интересны и познавательны, но я не могу считать их главными при выборе диска.

Системный диск должен иметь достаточно большой системный раздел. Многие программы видеомонтажа занимают много места, а разного рода заготовки видео/аудио/картинок вполне разумно хранить на системном диске. Мне хватает 3 ГБ пространства для Windows 2000 операционной системы и всех программ работы с видео и изображениями. По-видимому, размер системного раздела должен быть больше, если вы еще и играете в игрушки или программируете. Размер физического диска для системных нужд – индивидуален. Я обхожусь немолодым диском в 10 ГБ, и делю его с сыном на Windows 2000 и Windows 98 части. Непременное требование к такому диску – тишина работы во всех мыслимых режимах.

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

Наконец, если вы покупаете все новое – купите два одинаковых больших диска и используйте часть системного диска для краткосрочного хранения видео. Места никогда много не бывает.

4. RAID контроллеры. Дополнительные контроллеры жестких дисков – скорее всего обязательный атрибут компьютера для видеомонтажа. Для полного укомплектования вам обязательно понадобится 3 канала UDMA – два для дисков и как минимум 1 для комбинированного DVD/CD/CDR-RW устройства. Уже такая, не самая удобная, конфигурация имеет проблемы с количеством независимых каналов IDE. Для надежной записи CD желательно не совмещать записывающее устройство с системным диском на одном кабеле. Соединение видео диска с CD устройством тоже блокирует возможность интенсивной работы с диском во время записи CD. Если же вы хотите иметь раздельные пишущие и читающие оптические диски устройства, то все каналы будут заняты. А любимый ZIP куда присоединить? Mobile Rack со старым добрым потрепанным 6 ГБ диском, который вы привыкли носить с собой? Наконец, еще один диск куда добавлять, если решите его купить? Итак, дополнительный контроллер на 4 устройства необходим. Какой именно – работающий. Он может быть встроен в материнскую плату или быть отдельной картой.

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

RAID. Трудно сказать, нужен ли он в варианте Raid 0. С одной стороны, такое подключение увеличивает и размер, и скорость работы одного логического тома. Но, если у вас возникнет проблема хотя бы с одним из физических дисков, то вы потеряете данные на всем томе. Объема и скорости современных дисков вполне достаточно для работы с DV или MJPEG видео, а для работы с несжатыми форматами существует много труднопреодолимых ограничений на размер файла avi или вообще файла на диске. Все же я бы не советовал использовать RAID 0 из-за потенциальных проблем с надежностью хранения данных. Мне не приходилось пользоваться аппаратными RAID 0 платами. Программная реализация RAID0 в Windows 2000 работала хорошо, но и особых преимуществ я не увидел. Действительно, два диска сразу стали с некоторым запасом способными писать несжатый поток видео, но невозможность их разъединить без перезаписи информации в другое место создавала больше неудобств, чем появившаяся возможность записать целых 100 секунд YUY2 видео подряд.

5. Файловая система. В целом, я не заметил разницы в скорости работы с файловыми системами FAT, FAT32 или NTFS. Про FAT16 можно забыть, а выбор между FAT32 и NTFS неочевиден.

FAT 32 для видео файлов работает немного быстрее. Так, мой старый Seagate medallist 6.5 GB в конце тома может записывать видео с потоком до 5 МБ/сек. Обычно этой скорости достаточно для записи и воспроизведения DV потока (3.7 МБ/сек), но вот под NTFS последние 500 МБ вызывают проблемы при записи.

Этот диск уже два года живет в mobile rack и почти ежедневно перемещается в пространстве. Со временем контакты разъема коробочки с диском стали ненадежными и время от времени диск включается и опознается BIOS, но работает ненадежно. FAT32 в таких условиях просто портится, и все данные теряются насовсем. NTFS как правило выживает, и более разумно реагирует на подобные сбои. В итоге для этого диска я выбрал NTFS.

В пользу NTFS говорит и ее корректная работа при сбоях приложений, интенсивно использующих диск. Надо сказать, что программы работы с видео не отличаются стабильностью. Весьма часто приложение падает, совершив чего-нибудь нелегальное. В системе, перегруженной мультимедийными железками, даже Windows 2000 может умереть из-за неотработанных драйверов устройств. FAT 32, как правило, оставляет при этом потерянные кластеры. Если учесть объем видеофайлов, то количество проблем на диске может быть изрядным. При старте системы инициируется проверка диска, которая может продолжаться довольно долго. В NTFS такого не может быть.

Поэтому выбор Windows 2000 и NTFS для системного раздела являются предпочтительными. Небольшие файлы в большом количестве также надежнее хранить на NTFS разделах.

С другой стороны, конфигурирование и устранение сбоев операционной системы на разделе NTFS может оказаться невозможным или трудным из-за того, что доступ к NTFS можно получить только присоединив диск к другому компьютеру с Windows 2000. Я не считаю способы доступа к NTFS тому из DOS применимыми, потому что их, как правило, под рукой не оказывается, да и длинные имена файлов не позволяют сделать многого.

Я все же конвертировал системный том в NTFS и не жалею об этом. FAT 32 остается на моем 40 ГБ видео диске. Любопытно, что Windows 2000 не умеет сама делать тома более 32 ГБ с файловой системой FAT32. Диагностика ошибки в Disk Manager непонятная, поэтому предупреждаю об этом на всякий случай.

6. Операционная система (ОС). Как уже понятно из предыдущего пункта, желательный вариант ОС – Windows 2000. Кроме поддержки NTFS и существенно лучшей защищенности от плодов работы разработчиков мультимедийных приложений ;), сейчас уже можно говорить о стабилизации ее поддержки всеми производителями дополнительных плат. Таким образом мы уже не ограничены в функциональных возможностях или скорости, и имеем более устойчивую к программным ошибкам среду для работы. Нелишней будет и поддержка двухпроцессорных конфигураций.

Windows NT следует признать устаревшей из-за отсутствия нормальной поддержки DMA режимов доступа к дискам и новых аппаратных средств.

Windows 9x или ME вполне может быть правильным выбором, но ее защищенность от ошибок в коде программ оставляет желать лучшего. Правда, алгоритмы работы с памятью, дисковым КЭШем и файлом подкачки у нее лучше приспособлены для видео. Во всяком случае, их можно самостоятельно настроить так, чтобы система не мешала работе с видео выполнением ненужных сервисных задач.

Некоторое время назад я использовал 9х и 2000 одновременно и разные вещи делал на разных системах. Но уже примерно год я не использую Win 9x совсем. Главной причиной явилось не мое увлечение двухпроцессорным вариантом компьютера, а трудности с конфигурированием множества карт в моем компьютере. Опытным путем выяснилось, что а) установка флажка PNP OS installed не решает проблемы работоспособности всех установленных плат; б) при ручном распределении ресурсов не удается распределить PCI IRQ для win2000 и win 9x одинаково и так, чтобы все работало; в) если это и удается, то обновление bios или изменение этой конфигурации все равно может все поломать на одной из систем.

В итоге сейчас моя Win 9x о-о-чень долго пытается загрузиться, и работает нормально только с аудио и видеокартами и модемом. Пробовать другие устройства лучше не стоит. Я даже почти уговорил сына перейти на использование только Win 2000 ;).

Итак, будьте осторожны при конфигурировании двух операционных систем.

7. Системная плата. Каюсь, но я все еще использую Intel BX/MX для работы с мультимедийными устройствами. Не могу утверждать, что только с ними не будет проблем. Например, моя ASUS CUBX плата так и не смогла включить DMA на DVD ROM или на CD/R-RW, если они подключаются как primary slave. Не получилось у меня и с увеличением RAM до 512 МБ. В некоторых разъемах DIMM разные модули PC133 размером в 128 и 256 M вообще не опознаются, а в других работают со сбоями даже на 100 МГц. Обновления Bios давно прекратились.

Это я рассказал к тому, что устаревшие системные платы уже не поддерживаются производителями и нам остается только надеяться, что их bios находится в доработанном состоянии.

В то же время, большинство нынешних мультимедийных плат разрабатывались и испытывались (скорее всего) на BX системах. К ним имеются нормально работающие драйверы системных устройств, поэтому их использование "до последнего процессора" имеет смысл.

Я не пробовал более новые Intel или VIA чипсеты на совместимость с моим набором железа:

AGP ATI rage 128 fury pro;
Realmagic Hollywood+ MPEG decoder;
Canopus DV Raptor DV video editing card
PCI network card (3Com EtherLink XL 10/100 PCI NIC (3C905-TX);
Sound blaster 128 PCI;
USR Sportster 33.6 modem ISA.

На CUBX все это работает, но разъем PCI, разделяемый с CMD DMA66 контроллером, и первый PCI разъем заполнить не удается.

У меня нет претензий к программной (без захвата) работе с видео на двухпроцессорной PIII системной плате от MSI на VIA чипсете. Ее дополнительный дисковый контроллер от Promise тоже корректно работает с не-Fujitsu дисками. Впрочем, нормально диски и CD устройства стали работать после примерно пятого обновления bios, что наводит на грустные мысли... Примерно столько же раз обновлялись и win2000 драйверы от VIA. Итого, потребовался почти год, чтобы стало возможным легко сконфигурировать дисковые системы для работы с видео. Изучение конференции пользователей Canopus DV Raptor показало, что именно эту плату MSI 6321 хвалят за беспроблемность работы с видео.

Компьютер на Athlon процессоре не попадал мне под руку.

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

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

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

8. Выбор процессора. В целом этот выбор определяется количеством денег, которые вы готовы потратить. На ваше решение может повлиять наличие у вас элементов предыдущей системы, с которыми не хочется расставаться. В моем случае, например, это PC133 SDRAM память и ISA модем. И то и другое сейчас работает хорошо, а вот будет ли PCI модем переваривать мою реликтовую 201- АТС и соответствующие провода?

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

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

Можно предположить, что на способность компьютера показывать видео на экране монитора тип системной платы не должен влиять. Все современные платы способны показывать более 60 кадров в секунду в играх при разрешении 800х600. Отображение картинки в играх, как и в видео, производится в режиме overlay YUV, и большинство операций по преобразованию в RGB и масштабированию кадра делаются аппаратурой видеокарты. Для видео необходима способность шины AGP передавать картинку 720х576х16 бит = 829440 байт. Максимальная частота кадров составляет 50 Гц (для NTSC видео поток данных будет точно таким же за счет меньшего размера кадра при максимум 60 Гц). Итого, аппаратура компьютера должна быть способной передать в видеопамять максимум 41.5 МБ/сек, что вполне вписывается даже в возможности PCI шины. В реальности, для PAL DV или MPEG видео в видеокарту достаточно передавать 12 бит на каждый пиксел, что дает минимальную необходимую пропускную способность шины в 31.5 МБ/сек. В этих расчетах принималась во внимание возможность изготавливать видео в варианте с 50 кадрами в секунду для исключения искажений от чересстрочной развертки видео. Для сохранения информации о движении можно аппаратно реализовать в видеокарте показ полей видео в размере полного кадра, но с частотой 50 Гц. Так уже делается в ATI DVD player (Cinemaster), хотя и неидеально. При реализации такого алгоритма в большинстве видеокарт требования к скорости шины уменьшаются вдвое.

Вывод таков – шины данных и подсистема памяти всех современных системных плат не могут быть перегружены при проигрывании видео. Конечно, можно провести соревнование по способности показывать видео с частотой кадров 155.678 Гц и вычислить абсолютного лидера, оторвавшегося от конкурентов на целый процент, но смысла в таких опытах будет немного. Наличие у видеокарты аппаратной поддержки IDCT (inverse discrete cosine transform) и вовсе делает проигрывание видео простой задачей для всех вариантов системных плат и типов памяти.

Другое дело - кодирование/декодирование сжатого видео. Во-первых, некоторые кодеки явно оптимизируются под мультимедийные расширения команд процессоров. Наиболее охотно это делается для процессоров Intel, поэтому минимальный вариант для них – Coppermine Celeron. Более ранние модели PII не поддерживаются некоторыми кодировщиками, например Cinemacraft MPEG Encoder. Для процессоров AMD оптимизации, как правило, тоже есть, но встречаются и проблемы, когда код на них не работает. Например, Cinemacraft MPEG encoder не может сжимать аудио на процессорах AMD. Впрочем, он его так некачественно сжимает, что невелика потеря... Итог – выбирайте SSE enabled Intel CPU или Duron/Athlon. P4 позиционируется как процессор для обработки потоковых данных, но пока я не видел преимуществ его использования именно при сжатии видео, что и является в некотором смысле потоковыми вычислениями. Дороговизна решения и (пока) сомнительная степень отработки bios плат для P4 не делают его для привлекательным для работы с видео.

Кстати, хотелось бы сравнить производительность того же Cinemacraft encoder на разных платформах. Этот кодировщик - один из самых лучших по качеству картинки при больших bitrate и к тому же самый быстрый. Поэтому параметры скорости разных процессоров и платформ в целом для него имеют практический смысл.

Другим интересным вариантом кодека является DIVX 4.0 MPEG 4, наконец-то отлично оптимизированный и существенно лучший по качеству, чем предыдущие div-всякие незаконнорожденные дети MPEG4 v3 кодека от Microsoft. Я охотно верю, что этот кодек был сделан с нуля, потому что его поведение заметно отличается от "оптимизаций" продукта Microsoft.

Скорость подсистемы памяти заметно влияет на быстроту выполнения типичных для видео задач. Ранние решения типа Xing MPEG encoder, LSX encoder version 1, 2, 2.5, как мне помнится, не реагировали заметно даже на отключение кэша второго уровня. Вообще говоря, это могло бы означать относительно слабую загрузку основной шины памяти при кодировании MPEG этими программами. Если это не так, то должна бы наблюдаться сильная зависимость скорости кодирования от скорости подсистемы основной памяти, чего не было заметно в те времена, когда процессоры были большие и не мешали менять коэффициент умножения ;). Времена, однако, меняются пропорционально зафиксированным в железе коэффициентам. Мои опыты по кодированию с помощью TMPEG encoder, Cinemacraft SP encoder, рекомпресии из DV в DV и в DivX 4.0x форматы на PIII процессорах с коэффициентами умножения от 5 до 8 показали, что число процессорных тактов, расходуемое на кодирование тестового фрагмента, увеличивается с ростом коэффициента умножения частоты FSB. Разница в производительности между множителем 5 (mobile PIII 600 c включенным Speed Step) и 8 (PIII 800) достигает 20%. Это означает, что повышение скорости ядра на 60% за счет увеличения множителя увеличивает скорость вычислений в видео только на 2/3 от этой величины. Скорость работы самой подсистемы памяти тоже влияет на время кодирования видео. Так, изменение параметров работы памяти latency с 3 на 2 увеличило скорость кодирования на 12%. В системе с VIA KX133a чипсетом помогал и перевод частоты шины памяти на +33 МГц по отношению к частоте FSB. Впрочем, выигрыш был не столь велик. Например, для PIII 800 c множителем 8 наиболее производительным оказался вариант включения 124х8 при установках работы памяти в turbo и CAS delay=2. Если бы модули памяти работали стабильно в режиме turbo на частоте 147 МГц, то можно было бы ожидать дополнительного прироста производительности на 5%. Вариант же 124х8 & 147 МГц на модулях памяти в режиме normal, Cas=3 оказался не менее стабильным, но чуть медленнее.

Итог: выбирайте процессор с максимальной частотой внешней шины и старайтесь купить модули памяти, работающие с минимальными значениями CAS delay на возможно более высокой частоте. Реальный выбор для PIII систем невелик – только 133 МГц варианты.

9. Один процессор или два? При прочих равных условиях двухпроцессорные решения лучше.

Во-первых, можно ожидать почти двукратного прироста скорости кодирования MPEG многими современными программами.

Во-вторых, если даже код и не оптимизирован для параллельных вычислений, системные задачи все равно будут исполняться вторым процессором, что даст до 5-7% прироста производительности при возможности использования оставшихся ресурсов для других задач. Например, вы можете продолжать редактирование видео, пока первая часть вашей работы кодируется в MPEG формат. Можно также параллельно кодировать два разных видеоклипа. По моим наблюдениям, качество реализации чувствительных к скорости работы памяти двухпроцессорных вычислений примерно одинаково у Intel 440BX и VIA KX133a решений: при одинаковых задачах на кодирование DivX 4.0 MPEG4 видео, исполняющихся параллельно, уменьшение скорости каждой из них будет приблизительно 25-30%. Таким образом, вы можете ускорить кодирование примерно в 1.5 раза за счет двух процессоров.

В третьих, второй процессор и двухпроцессорная системная плата увеличивают стоимость компьютера примерно на 10-15%, что существенно меньше, чем ожидаемый прирост производительности.

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

Video: Минимальные требования к компьютеру для видеомонтажа

Любой компьютер с MMX процессором, шиной PCI и объемом памяти более 64 МБ следует признать вполне достаточным для видеомонтажа, если вы никуда не торопитесь.

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

Единственное, на что следует обратить внимание - качество материнской платы. Тут я затрудняюсь что-либо посоветовать, потому что их слишком много. Главное требование - надежная работа DMA для дисков и Bus Mastering для шины PCI.

Вот, собственно, и все, что нужно от компьютера.

Если все покупается с самого начала, желателен вариант с наименьшим коэффициентом умножения при заданной тактовой частоте. Не нужно стремиться купить самый быстрый процессор - достаточно 800 МГц FCPGA Celeron. Меньшая скорость не позволит использовать программные MJPEG кодеки для компрессии в реальном времени и при полном размере кадра.

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

Мне кажется, что скорость работы шины памяти желательно иметь 133 МГц. Отличия в скорости компрессии и, особенно, декомпрессии от частоты шины памяти для процессоров с большими коэффициентами умножения могут быть довольно велики. Впрочем, они не так важны для возможности работать с видео вообще.

Меньше 128 МБ памяти использовать не советую. Кроме того, крайне нежелательно, чтобы во время захвата видео система вдруг решила пообщаться с файлом подкачки windows 9х.

Для уменьшения такой вероятности, в Windows 9x следует ограничить размер файлового кэша.

В секцию Vcache файла system.ini вписываются строчки:

minfilecache=8096
maxfilecache=8096
minpagingfilesize=64000

Таким образом, системе не разрешается заниматься изменением размера файлового кэша, вся оставшаяся память освобождается от опасности быть занятой этой бесполезной при монтаже информацией. Кроме того, система сразу имеет 64 МБ виртуальной памяти и не имеет нужды изменять размер файла подкачки при работе. Это занятие может сильно отвлекать от захвата видео.

Разумеется, такой трюк не пройдет с Windows NT или 2000. Не советую использовать всяческие утилиты по управлению распределением памяти в NT системах. Не помогают они. Проще добавить памяти. У меня нормально все работает даже на 128 МБ, хотя лучше бы использовать не менее 192.

Наконец, самый минимум, требуемый от компьютера - P166 MMX, но с хорошей материнской платой, поддерживающей SDRAM и PCI bus mastering. Вот уж без этих двух вещей о видеомонтаже лучше и не думать. И именно ММХ.

Video: Самое дешевое решение

Если предположить, что компьютер у вас уже есть, что можно сделать с ним для редактирования видео?

Я исхожу из предположения, что источником сигнала для вас является аналоговая видеокамера. Если вы купили DV камеру, ваши затраты на до-оборудование компьютера будут другими и рекомендации, изложенные в этом разделе, вам не полностью подойдут. Немного поразмышляв, я решил вставить ремарки про дешевое DV решение прямо в текст, следующий ниже. Дело в том, что принципы работы с видео не меняются от того, каким способом это видео попадает в компьютер. Также, вам будет легче сравнить, что же лучше.

Оборудование

Первый шаг - купить большой и пригодный для работы с видео диск. Из тех, что я сам пробовал, мне всегда нравились диски Seagate. 40Гб меньше чем за 100$ - это экономно. Современные и более ранние модели Seagate умеют отлично писать непрерывные потоки данных. Модели других производителей следовало бы испытать на пригодность к работе именно в условиях описываемой ниже дешевой системы видеомонтажа.

Второй шаг. Аналоговая карта видеозахвата (или недорогая IEEE1394 карта, если у вас DV видеокамера). Я рекомендую PCI TB тюнеры, в которых используются микросхемы BT848 или BT 878. Цена такой карты может быть меньше 40$ (для DV – примерно такая же, но производитель микросхем – Texas Instruments). Все такие карты соответствуют reference design плате производителя микросхем и умеют:

Показывать на мониторе и захватывать аналоговое (DV) видео со скоростью потока данных, ограничиваемым только устройством записи (3.5 МБ/сек для DV). Я проверял эти их способности на материнских платах Pentium и Pentium II (не думаю, что соврал для DV. С ним вообще все проще, но вот с показом видео на экране могут быть проблемы – оно ведь декодируется из DV процессором!). Даже Iwill на I440FX чипсете работала отлично, не ограничивая пропускную способность канала передачи данных по шине PCI.
Захватывать видео с произвольными размерами кадра (IEEE1394: копировать DV поток данных с ленты на диск. Размер кадра, разумеется, остается полным). Делается это, правда, через редактирование registry, но работает отлично. Запускаете поиск по Registry на слово BT848 (878), в найденной ветви находите RectHeight (высота) и RectWidth (ширина), меняете значения, и запускаете программу захвата. Только в самой программе не надо ничего менять, иначе она самостоятельно выставит одно из стандартных разрешений. В программе VirtualDub можно произвольным образом устанавливать и размеры кадра, и формат оцифровки, не прибегая к редактированию системного реестра (понятие оцифровки неприменимо к DV. Все уже и так оцифровано. Речь идет только о переносе данных с ленты на диск).
Захватывать видео как через композитный вход, так и через S-video. Последнее важно для Hi-8 видеокамер (для DV все это неприменимо. Можно написать, что копирование данных возможно с любых устройств, поддерживающих IEEE1394 стандарт. Но вот аналоговое видео такие карты НЕ могут никак захватить).

Третий шаг. Если вам хочется выводить результат своего труда на экран телевизора или записать на видеокассету, то, на мой взгляд, вам придется купить аппаратный MPEG2 декодер (для DV всегда есть возможность скопировать итоговое видео на DV ленту, или показать видео с диска с помощью видеокамеры, но решение, позволяющее показывать архив на CD, все равно нужно). Его цена сегодня примерно $61. Дело в том, что у большинства видеокарт, имеющих ТВ выход, работает он не так, как нам надо. Даже если вам удастся захватить видео в полный размер (для DV это истинно так, и никак по-другому), его будет почти невозможно правильно показать через видеовыход обычной карты. Для соответствия строк цифрового видео и строк на экране телевизора видеокарта должна уметь переключиться в режим 576 строк и растянуть видео на всю его высоту и ширину.

Ниже будет объяснено, почему захват видео с полной шириной кадра нецелесообразен (для DV у вас нет выбора: размер кадра всегда полный). К тому же, качество выхода видеокарты на ТВ часто просто не выдерживает никакой критики.

Что же касается MPEG2 карты, то она специально была сделана для показа видео, поэтому не только работает правильно и обеспечивает высокое качество, но еще умеет растягивать кадры по ширине, даже не спрашивая вашего согласия.

Ну вот, система готова. Цена ее доработки для редактирования видео составила $200, из которых собственно оборудование для видеозахвата стоит $100.

Все вместе стоит дороговато? Начните с системного диска. Но это неправильно. Если же все-таки диск покупать, то нет смысла экономить 10$ на 10-20 ГБ дополнительного размера - посмотрите на цены и поймете.

Видео для просмотра на компьютере или VideoCD

Захват нужно делать в формате BTUV с размером кадра 352х288, 25 Гц (для DV размер кадра всегда полный). Почему 352 - так велит стандарт VideoCD. Можно и больше, но тогда (теоретически) могут быть проблемы с воспроизведением этого кино MPEG картой. Для Hollywood+ это не так, поэтому вам подойдет и нормальный по пропорциям размер в 384 пиксела. Не забудьте только сжать итоговое видео по горизонтали до 352 пикселов, если вы хотите сделать настоящий VideoCD для проигрывания в бытовых VideoCD плеерах.

Почему 288 строк - их ровно столько активных в поле видеосигнала PAL или SECAM (DV поток данных всегда содержит оба поля). Выбрать меньше можно, но это потеря качества (неприменимо для DV). Выбрать больше хочется, но нужно либо все строки, либо только половину захватывать. Все строки в режиме 352х576 - это в нашей системе лучше подходит для MPEG2 (у DV всегда размер кадра 720х576, но уменьшить всегда можно будет потом).

Для создания видео с целью пересылки по электронной почте или для Web сайтов, презентаций и подобных нужд, можно устанавливать любой размер кадра при высоте не более 288 строк и с соблюдением пропорций 4:3 (для DV все эти рассуждения применимы тоже, но не на стадии захвата, а на стадии изготовления итогового видео)

Итак, вы получаете видео в формате, в котором каждый пиксел имеет индивидуальное значение яркости и группа из четырех пикселей на строке имеет одинаковый цвет. Это только кажется плохой оцифровкой: мне не удалось увидеть большее разрешение по компонентам цветности на выходе VHS магнитофона. Даже для Digital8 видеокамеры разрешение по компонентам цветности оказывается на аналоговом выходе не лучше. Если хотите, попробуйте захватывать в RGB 24 и сравните картинки. За счет правильного выбора формата экономится половина места на диске по сравнению с RGB (DV формат имеет другое представление, но число битов на пиксел перед DV компрессией у него такое же).

Видео записывается со скоростью 3.8 МБ/сек (Для DV цифра очень близка к этой, но при полноразмерном видео). В один файл размером 2ГБ поместится примерно 9 минут видео, если учесть еще и звук. Почему размер Avi не может быть больше 2 Гб - так решил Microsoft. В файле записывается длина данных в виде 32 бит целого со знаком. Больше 2ГБ таким способом записать нельзя (для файлов DV video, создаваемых OHCI compliant IEEE1394 устройствами, ограничение на размер отсутствует, если нет ограничений в самой файловой системе. Например, для FAT32 такое ограничение составляет 4ГБ).

Хотите иметь большую длительность записи? Придется поэкспериментировать. Можно использовать один из быстрых программных компрессоров. Morgan Multimedia, Picvideo MJPEG Codec или Mainconcept MJPEG кодеки, как правило, могут в реальном времени производить видео очень хорошего качества при скорости потока 1.5-2 МБ/сек, если у вас 450 МГц или более быстрый процессор. Можно попытать счастья с Indeo 5.10 quick compressor. Поставьте 100% качество и укажите, что каждый кадр должен быть ключевым. Качество будет похуже, чем у MJPEG, но и размер файла меньше - 1000-1200 КБ/сек. Можно захватывать видео и с помощью DivX 4.0 кодека. Наилучшим с точки зрения качества при заметном сокращении размера можно считать кодек Huffyuv 2.1.1, сжимающий без потерь. Коэффициент сжатия не превышает двух, но при этом сохраняется вся информация в кадрах (для DV все эти рассуждения не имеют смысла).

Опять мало? Остается два пути: использовать какой-нибудь быстрый компрессор с большим коэффициентом сжатия, или найти способ записывать много файлов по 2 Гб подряд без пропусков кадров на стыках.

Для первого способа нужен быстрый процессор и DivX 4.0 кодек или Windows Media Encoder. (DV: такие решения тоже есть, например, тот же Windows media encoder) Качество видео примерно соответствует MPEG1, как правило, удается сжимать в реальном времени. Длительность записи определяется суммой 200 кб/сек (или меньше) для видеопотока и максимум 16 кб/сек для 16 bit 44.1 MPEG 2 layer3 (или wma) аудио и составляет более двух часов. Имейте в виду, что качество такого видео будет неважным, поэтому такой "магнитофон" следует использовать только для разовых просмотров, или если видео не предполагается конвертировать в другой формат.

Для второго способа решение существует, но задумано оно было только для захвата без программного сжатия. Для нашего примера с 4МБ/сек форматом видео, и местом на диске для восьми файлов, выходит примерно 72 минуты. Не так плохо для начала.

Итак, идем по адресу: www.nct.ch/multimedia/avi_io/index.html, и загружаем программу AVI_IO (DV формат тоже поддерживается этой программой). С ее помощью можно захватывать видео в несколько файлов размером до 4 Гб. За полную версию нужно заплатить денег, но и пробная версия дает возможность захватывать до 54 минут видео. Если применить YUV9 формат, то с некоторой потерей качества можно уменьшить поток данных до 3 МБ/сек записать в один прием до 66 минут видео (DV: неприменимо). VirtualDub и программы Бориса Прохорова тоже умеют писать видео в несколько файлов (DV: неприменимо).

Что делать дальше? Редактировать (применимо только для avi видео, wm* файлы редактировать нечем) и сжимать в MPEG1 (или DivX 4.0, если вам не нужно выводить видео на телеэкран). Советы, как это делать, можно посмотреть в других разделах этого документа (DV: обычно все кодировщики умеют делать MPEG1 из DV type2, а если у вас type 1, то потребуется конвертор или мелкие хитрости, о которых будет сказано ниже). MPEG1 видео должно хорошо воспроизводиться вашей MPEG картой на телевизоре, и также хорошо будет показываться встроенным программным декодером Windows на мониторе любого компьютера. Можете поэкспериментировать с другими компрессорами, но тогда у вас не будет возможности смотреть видео на телевизоре с помощью Hollywood+ декодера.

Интересное наблюдение. По не вполне понятным мне причинам, Hollywood+ декодер показывает на экране телевизора видео в формате VideoCD заметно лучше, чем оно воспринимается на экране монитора. По-видимому, меньшее разрешение телеэкрана и несколько лучший алгоритм масштабирования в аппаратуре декодера сглаживают артефакты компрессии. Примерно такой же эффект наблюдается и при проигрывании VideoCD на mp3 плеере Napa 310. Поэтому я могу с некоторыми оговорками рекомендовать этот формат для хранения домашнего видео, если он вас устроит (DV: формат в принципе содержит меньше шумов, поэтому сжатие DV оригинала обычно приводит к более качественным результатам).

В принципе, видео с размером (по площади) в ? кадра нормально показывается на телевизоре и видеокартами с ТВ выходом. Если у вас есть такая карта, то можете смело рассчитывать на приемлемое качество показа любых видеороликов с высотой кадра не более 288 пикселов.

Настоящее Видео

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

Вот тут и придется задуматься о полях видеокадров. При захвате с половинной высотой кадра вы получили в видеофайле только половину исходных "фотографий" из числа присутствующих в видео сигнале. Вторая половина была потеряна. Поэтому ваш глаз получил только половину информации о движении в сцене, и все происходящее выглядит как-то с подергиваниями или неплавно двигающимся. К сожалению, преодолеть это можно только увеличением высоты кадра при захвате до полных 576 строк, что удваивает объем данных (DV: неприменимо, потому что видео и так записывается с полной высотой кадра).

Кроме того, вам будет труднее использовать программную MJPEG компрессию при захвате видео: может не хватить производительности процессора. Впрочем, последние версии MJPEG кодеков от picvideo или Mainconcept достаточно хорошо оптимизированы и должны нормально работать с кадрами 352х576 на PIII процессорах быстрее 600 МГц (DV: у вас таких проблем нет. Хватит и 300 МГц).

Поток данных возрастет до 6-8 МБ/сек для случая несжатого видео в BTUV формате (DV: а у вас всегда 3.6 МБ/сек). Скорости записи обычного современного диска тоже должно хватить по емкости и скорости работы (DV: изначально не было причины беспокоиться).

Захват получается не слишком длинным? Стоит по демонстрационным версиям программ захвата во несколько файлов понять, какая работает для вас лучше и приобрести коммерческую версию (DV: для видео type1 достаточно сменить файловую систему на NTFS. Для Canopus DV Raptor все это и так решено за счет записи в reference avi файлы).

С другой стороны, если вы делаете фильм для семейного архива, то нет смысла делать его длиннее 10-15 минут. Более длинные фильмы смотреть сможете только вы сами - все друзья быстро устанут.

Итак, 352х576. Что с таким размером кадра можно сделать? Во-первых, можно смешать оба поля в один кадр размером 352х288 в выходном видео (DV: то же самое, если вам нужно сделать VideoCD). При таком смешивании в какой-то мере имитируется смазанность (motion blur) картинки на кадрах кинофильма, что и позволяет получить впечатление более плавного движения в кино. Точной имитации не получается. Для улучшения восприятия можно рекомендовать тщательно следить за быстрыми поворотами камеры при съемке. Отдельные предметы, не занимающие много площади кадра, двигаются довольно плавно и в варианте без смешивания полей. А быстрые повороты камеры при съемке дают смещение всего фона и неустранимые мерцания двигающихся в кадре вертикальных границ предметов. Кажется, в кино об этом знают, и таких перемещений камеры в нем мало. Мы же делаем так очень часто. Именно поэтому мне кажется, что рекомендации делать видео с высотой кадра в 288 строк в качестве эквивалента VHS формату неправильны. По качеству неподвижного кадра действительно выходит, что оно вполне соответствует VHS, но по передаче движения - только при кодировании кинофильмов.

Для выходного размера 352х288 можно использовать все схемы компрессии, которые вы уже опробовали в разделе "компьютерного" видео. Пора переходить к более совершенным методам компрессии.

Просмотр видео с полной передачей информации о движении

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

Имитация режима чересстрочной развертки в окне overlay, обычно используемом при показе видео на мониторе, также невозможна. Дело в том, что при чересстрочной развертке каждая линия должна быть в два раза ярче, чем при прогрессивной. Если токи лучей монитора настроены на прогрессивную развертку, то показ в окне видео одновременно только половины строк кадра приведет к потере половины яркости.

Правда, возможно показывать каждое поле видео в виде целого кадра. Для этого:

исходный полный кадр разделяется на поля с четными и нечетными строками,
верхнее (с верхней строкой кадра)поле масштабируется до полного размера и его картинка смещается на полстроки вниз (интерполяцией)
нижнее поле масштабируется до полного размера и его картинка смещается на полстроки вверх (интерполяцией)
оба кадра показываются с интервалом в 1/50 секунды.

Такой способ устранения эффекта "расчески" получил название BOB deinterlacing. Впрочем, выше приведен наиболее честный вариант его реализации, не найденный пока в проигрывателях видео в чистом виде. Четкость по вертикали при таком способе теряется, но это почти незаметно на глаз. Кроме потери четкости, картинки неподвижных кадров немного дрожат из-за остающихся погрешностей интерполяции при смещении изображений полей на половину строки. Впрочем, таким способом можно добиться весьма хороших результатов для видео телевизионного происхождения.

Следующей трудностью является выбор формата сжатия видео, который вообще имеет представление о наличии полей в видео. Дело даже не в том, чтобы включить BOB режим только тогда, когда это нужно, но и в умении выдать поля видео в правильном порядке. Разные карты оцифровки видео могут использовать разную очередность полей для компоновки их в полный кадр. Поэтому в сжатом видео либо должен присутствовать флаг очередности полей, либо она должна быть такой, чтобы обеспечить правильный показ декодированного видео на телеэкране (DV: очередность полей фиксирована как "сначала нижнее", но проблема показа на мониторе остается).

Способами сжатия видео, в которых есть информация о полях, являются MJPEG компрессоры, DV кодеки, и MPEG2 формат. Причем, только MPEG2 формат явным образом содержит флаг очередности полей, который должен менять поведение декодера. Остальные форматы только учитывают наличие полей при кодировании видео, но никак не передают информацию об их очередности декодеру. Предполагается, что соответствующий аппаратный декодер уже знает правильную очередность полей (DV и карты с аппаратной MJPEG компрессией). Иногда (если источником видео служила не та же самая карта) такое "знание" оказывается неверным, что приводит к ошибкам при показе видео на телевизоре. То же касается и MPEG1 формата. В его потоке не предусмотрена передача информации о полях. MPEG 1/2 декодеры с выводом картинки на телевизор все равно передают видео по полям. Для MPEG1 декодер всегда использует определенную очередность вывода строк кадра (полей) на экран телевизора, что делает MPEG1, в принципе, пригодным для показа видео с полной высотой кадра, если вы эту очередность правильно угадали.

Для нашего случая использования в качестве видеовыхода MPEG декодера никакого другого выхода нет – MPEG1 или MPEG2 форматы (DV: проблема не существует, если вы используете для показа видео саму видеокамеру, но остается для MPEG видео).

Отступление в защиту MPEG1

Вообще говоря, стандарт MPEG1 допускает размеры кадра до 4096х4096. Фундаментальное различие между MPEG1 и 2 состоит в способности последнего корректно сжимать видео с чересстрочной разверткой. Все остальные отличия не столь важны, поскольку относятся к установлению нескольких уровней и профилей, заменяющих собой единственный constrained (он же применяемый в VideoCD) набор для MPEG1. MPEG2 поток может содержать в себе MPEG1 видеоданные, по размеру кадра и скорости потока данных вписывающиеся в, скажем, в main level / main profile MPEG2 характеристики (именно такая комбинация профилей/уровней используется в DVD и цифровом вещании), и будет правильным MPEG2 потоком.

Для поддержки понятия полей в MPEG2 введен флаг очередности полей видео и разрешено кодирование по полям, или специальное кодирование всего кадра блоками через строку. В любом случае, при таком кодировании каждый блок 8х8 пикселей содержит только точки из одного поля. Предсказание движения тоже усложнилось, так как появилась возможность сравнивать и соседние поля видео, и соседние кадры. Кроме того, в алгоритм компрессии добавлен вариант, лучше приспособленный для кодирования видео с полями. В целом, как пишут первоисточники, при одинаковой потере качества при сжатии за счет MPEG2 дополнений можно ожидать экономию 10% размера файла. Так ли это на самом деле – вопрос спорный и ответ на него зависит от конкретной реализации алгоритмов.

Я постараюсь привести свои собственные наблюдения на эту тему в других частях этой публикации.

Можно попробовать использовать MPEG1 компрессию и для видео с полями. При этом, как может показаться, эффект "расчески" в кадрах видео должен приводить к ухудшению качества картинки после компрессии. Мои опыты показали, что это не совсем так. MPEG1 компрессор действительно не подозревает о том, что кадр видео составлен из двух картинок. Поэтому ему приходится сжимать "расческу". В то же время, алгоритм предсказания движения не перестает работать, а сама по себе "расческа" не так уж много прибавляет к числу битов в сжатом блоке данных.

Любопытно, что некоторые, заявленные как MPEG2, кодировщики не умеют при сжатии использовать ничего, отличного от MPEG1, кроме флага очередности полей. К таким относится, например, LSX MPEG encoder. А ведь он не считается плохим по качеству.

Безусловным достоинством MPEG1 формата является возможность просмотра видео на любом компьютере. Встроенный в windows декодер MPEG1 работает весьма качественно. Некоторые программы, например, Vitrualdub, позволяют перекодировать MPEG1 в avi. Для MPEG2 придется использовать специальный декодер. Разумеется, для владельцев Hollywood+ проблемы посмотра MPEG2 не существует, но, к примеру, его проблематично использовать для проигрывания роликов в презентациях. Итак, если вам важна универсальность формата хранения видео, есть смысл попытаться не отказываться от MPEG1 сразу.

Мои опыты с проигрыванием MPEG1 видео на компьютере привели к следующим выводам:

Разница в качестве самого видео, сжатого хорошим MPEG1 и хорошим MPEG2 кодировщиками, при одинаковых потоках данных пренебрежимо мала, если ее вообще возможно обнаружить. Причем, этот вывод справедлив и для программного декодера windows, и для Hollywood+.
Существуют добротные кодировщики, поддерживающие только MPEG1 стандарт, например, от Panasonic.
Очередность полей видео при кодировании из DV или захваченного аналогового видео (по крайней мере, для моей карты Avermedia TV phone) в MPEG1 остается правильной. В принципе, это означает, что принятый в H+ порядок показа полей из полного кадра MPEG1 соответствует способу объединения полей в один полный кадр. Ведь никакого способа указать другой порядок полей в потоке MPEG1 данных просто нет. Hollywood + прекрасно показывает MPEG1 видео с полной высотой кадра и плавность движений полностью сохраняется.
При проигрывании MPEG1 видео на моем экземпляре no-name H+ нельзя использовать ширину кадра более 464 пикселов, если применяется используемый по умолчанию вариант кодирования с двумя B кадрами подряд. Установка только одного B кадра подряд снимает эту проблему и при полной ширине кадра (720 пикселов). Качество кодирования от этого сильно не ухудшается.
Разумеется, обычный медиаплеер Windows не умеет самостоятельно растягивать кадр MPEG1 уменьшенной ширины до нормальных пропорций картинки. Преодолевать это можно либо с помощью бесплатных плееров, использующих внутри windows media player control, либо созданием собственного варианта такого проигрывателя в Visual Basic. Не могу понять упорства, с которым Microsoft скрывает некоторые полезные свойства собственного произведения внутри кода. Например, в стандартном медиаплеере нельзя показать номер кадра видео, и нельзя двигаться шагами по одному кадру. H+ умеет показывать видео в полный телевизионный экран.
Пресловутая "расческа" всегда будет присутствовать при просмотре видео с полной высотой кадра на мониторе (я принципиально не рассматриваю перекодировку кинофильмов из DVD в более компактный вариант MPEG). Если видео нужно вставить в презентацию, можно использовать 50% уменьшение высоты кадра. К сожалению, никакой возможности избавиться от этого эффекта пока нет. Вернее, она может быть только такой же, как и bob deinterlacing в программных MPEG2 проигрывателях. Само по себе это ухищрение было возможно всегда, но применили его почему-то пока только для них.

Вывод: не бойтесь распространенных заблуждений о непригодности MPEG1 формата для хранения видео с полной информацией о движении. Выбор между MPEG1 и 2 зависит в целом от ваших предпочтений.

Предостережение: не смешивайте поля

Многие программы обработки видео не подозревают о полях. В частности, некоторые фильтры, применяемые в компрессорах для предобработки перед сжатием или даже после распаковки кадров, работают по целым кадрам. В качестве примера можно привести MPEG4 кодеки от Microsoft и все производные от них. В этих компрессорах делается попытка применить blur фильтрацию, если кодек заведомо знает, что ограничения по потоку данных приведут к сильно заметным искажениям видео. В отличие от большинства программ видеомонтажа, фильтрация применяется не раздельно к картинкам каждого поля ( если программе заранее сообщили о наличии полей в видео), а к кадрам. В результате между полями возникает смешивание, которое приводит к потере почти всей той половины информации о движении, которая и содержалась в картинках полей, а не кадров. При просмотре такого видео на телеэкране движения перестанут быть плавными. Некоторые MPEG1 кодировщики содержат подобные фильтры, иногда адаптивные, и их включение тоже приведет к потере плавности движений. Например, кодировщик от Panasonic не должен работать с включенными встроенными фильтрами. Подобные фильтры имеются и в LSX MPEG encoder, причем в варианте MPEG2 они принудительно скрываются от пользователя.

Если вы забудете указать правильную очередность полей в Adobe Premiere, то все его blur и подобные фильтры также приведут к потере плавности движения.

Не следует относить эти проблемы на счет собственно MPEG1 формата. Аккуратное следование идее полей в видео должно предохранить от его неправильного приготовления. В то же время, хороший кодировщик вполне может использовать адаптивную фильтрацию для уменьшения потока данных в ситуациях, когда это может привести к улучшению воспринимаемого качества картинки. К несчастью, эти фильтры больше всего нужны при быстрой смене содержимого кадров, и их работа по смешиванию полей наиболее заметна. Если вы увидели явные искажения плавности движений, не используйте такой кодировщик в варианте MPEG1. Переключитесь на MPEG2 и внимательно установите все ориентированные на interlaced видео параметры кодирования.

Итак, после редактирования видео формата avi вам следует компрессировать его в формат MPEG1 или 2. Более подробно о выборе самих компрессоров написано в других разделах данного обзора.

Изготовление длинных фильмов

Затруднение, с которым вы можете столкнуться (кроме очень большого времени кодирования) - как приготовить итоговый avi для сжатия в MPEG? Кажется, формат, в котором вы захватывали видео, не всегда удастся использовать для сохранения готового фильма (так иногда бывает, если аналоговая карта записывает видео в формате, для которого отсутствует программный кодировщик). Можете использовать в качестве промежуточной стадии программный MJPEG кодек (DV: ни в коем случае не используйте ничего, кроме DV). Не забудьте включить у него поддержку interleave, иначе он будет использовать при сжатии только одно поле кадра. Можно использовать и DV кодек, если захват был произведен с размером кадра строго 720х576. Если вы пользуетесь Adobe Premiere 5.1х, то можете сделать MPEG2 прямо из него с помощью bbMPEG plugin. Кроме этого решения, можно использовать plugin версии нескольких других кодировщиков. Впрочем, мне такой путь не нравится.

Во-первых, заранее неизвестно, какой MPEG2 кодировщик будет работать лучше. Во-вторых, не все кодировщики имеют plugin версии. В-третьих, многие plugin варианты урезаны в возможностях по сравнению с полными версиями.

На мой взгляд, лучше всего подойдет использование avisynth premiere plugin, который превратит Premiere в сервер кадров видео для почти всех известных программ его дальнейшей обработки. Во всяком случае, все используемые мной программы компрессии такой сервер понимают. Помимо экономии места на диске, улучшается и качество компрессии за счет исключения промежуточной стадии сжатия (даже для DV формата).

Параметры итогового видео

Для половинной ширины кадра подойдет скорость потока MPEG примерно 2.5-4 mbps (DV: вы тоже можете использовать половинную ширину кадра для кодирования в MPEG. Отнеситесь внимательно к тому, как работают алгоритмы изменения размера кадра, чтобы не допустить смешивания полей внутри кадра видео. Это справедливо и для других форматов, если вы изменяете ширину кадра). Вообще говоря, для быстрого приготовления MPEG с целью вывода на видеомагнитофон можно приготовить специальную версию итогового видео с максимально большим потоком данных. Например, вариант 15 Мбит/с и только I кадры в GOP последовательности позволит сжать видео много быстрее в MJPEG-подобном виде (без межкадровой компрессии, которая в разы медленнее) и проиграть его с наивысшим качеством для записи на ленту (DV: для вас эта рекомендация не имеет смысла. Используйте DV формат и вывод на ленту через видеокамеру непосредственно из timeline редактора). По скорости кодирования такой вариант с использованием сервера кадров avisynth сопоставим с любым программным компрессором MJPEG. Для хранения видео на CD используйте полноценное сжатие MPEG с указанной выше скоростью потока.

В конце концов вы получите MPEG2 файл, который будет показываться на экране телевизора практически так же, как и исходное видео. Вас не устраивает разрешение 352 точки на ширину кадра? Это справедливо для Hi8 или SVHS видеокамер. Если вы записываете видео на обычный VHS, то не увидите улучшения качества записанного на ленту видео от увеличения ширины кадра при оцифровке. Если же у вас есть комплект из SVHS камеры и SVHS магнитофона, то не лучше ли потратить побольше денег на карту захвата с аппаратной DV компрессией (недорогой вариант производится Dazzle), или на более производительный процессор, позволяющий сжимать видео в DV формате программно? Другой вариант, сторонником которого я не перестал быть – использование Digital8 видеокамеры как устройства оцифровки и хранения видео.

Попробуйте захватывать видео в режимах с шириной кадра > 352 (DV: неприменимо; все остальные: не более 720, и обязательно кратно 16). Постепенно увеличивая этот размер, найдите предельную скорость потока видеоданных, которая вас устраивает. Для хранения MPEG видео, на мой взгляд, следует все же придерживаться системы в установке ширины кадра. Известно, что используемыми в DVD вариантами являются ширины кадров в 352, 480 и 720 пикселов. Я советовал бы придерживаться этих значений в надежде когда-нибудь дожить до DVD RAM бытовых устройств, понимающих просто MPEG1/2, а не только его .VOB разновидность.

Что получилось в итоге

Подведем итог. За $100 затрат на видеооборудование и неизбежных $100 за накопитель вы получили возможность редактировать видео с качеством не хуже, чем может обеспечить полупрофессиональная MJPEG видеокарта (DV: принципиально без потерь качества на преобразования из аналоговой формы в цифровую и обратно). Кроме того, вы можете теперь выводить видео на телевизор, и даже записать на VHS магнитофон с хорошим качеством (DV: с качеством, соответствующим качеству любого носителя, от VHS до DV). Правда, времени потратить и мелких хитростей для этого применить придется много. Но цель достигнута! Заметьте, карта MPEG2 вам тоже будет нужна не сразу. На начальном этапе можно будет смотреть MPEG и на мониторе с помощью какого-нибудь программного DVD плеера.

Video: Существуют ли доступные форматы c более высоким качеством?

Существуют ли какие-то другие, более-менее доступные форматы, кроме DV, c более высоким качеством - т.к. даже 500 линий не всегда устраивают по четкости(вопрос скорее на будущее).

Э-Э-Э, а смотреть-то на чем? У меня дома и S-video входов-то у телевизоров нет. На мониторе с близкого расстояния можно помечтать о >720 пикселах, но стоит отойти подальше, и...

Вообще эти линии просто обман. Определение гласит, что разрешение в линиях есть число индивидуальных элементов изображения по горизонтали, измеренное на части строки, по длине равной высоте экрана. Отсюда и получается 500 пикселов-линий из 720 для DV.

На экране 29" телевизора Philips у меня на работе я сосчитал 600 вертикальных полосок маски. Одна на миллиметр. ВСЕ! Больше он не покажет никогда! Чтобы он и эти нормально показал, нужно на кинескоп подать ровно 600 пикселов цифрового сигнала, по одному точно на линию маски, иначе будет муар. В аналоговом виде эта трубка больше 400 линий и не покажет.

Самые продвинутые бытовые аппараты, наверное, приближаются к DV. Но делать даже больше 400 линий все равно при массовом выпуске нецелесообразно - цена кинескопа и видеоусилителя растет, а увидеть разницу пока не на чем. Нет источников сигнала. Да и стандарт в самом строгом черно-белом виде не предусматривает пока больше 500 линий. Честные 100 Гц развертки дали бы более заметное улучшение воспринимаемого качества видео, чем увеличение разрешения.

Я получил на аналоговом выходе Digital8 камеры Sony TRV DCR 110E примерно 400-420 линий при съемке напечатанной на бумаге испытательной таблицы. Это уже ограничение матрицы внутри видеокамеры. 500 линий гарантируются только по IEEE1394 каналу и только в цифровом виде. Оптическая часть имеет меньшее разрешение. Заметить это на телевизоре нельзя. На экране монитора можно, но только при сравнении тестовых картинок. Реальные сцены выглядят четкими и при честных 400 пикселах на строку.

К тому же, в типичных любительских ситуациях не получается и такая точность фокусировки. Если освещение неяркое, автофокусировка дает ошибку, хотя для Digital8 она и небольшая. При съемке с руки при быстрых перемещениях автофокус тоже отрабатывает с некоторой ошибкой. Если снимать в режиме ручного фокуса, то на ЭТОМ видоискателе выставить его точно довольно трудно, если спешить.

Думается мне, что > 500 линий для любителя не нужно. Если же камера используется в студии, то это уже другой ценовой диапазон, для работы с техникой за $20000 можно и оператора натренировать, и свет поставить, и фокус заранее настроить по большому монитору. Для наших же игрушек это просто нереально.

Компоненты цветности на S-video выходе D8 имеют в лучшем случае 1.3 МГц полосу частот. Вещательный стандарт предусматривает до 1.5 МГц. У реальных Sony и Panasonic телевизоров 6 летней давности на экране при композитном сигнале выходит еще меньше.

Насколько я знаю, все серьезные проекты high definition TV пока не имеют перспективы в бытовой электронике. Мне бы вот хоть одну московскую ДМВ программу дома посмотреть...

Кажется, и в студиях пока довольны 720 пикселами на полную строку. Там даже не везде на цифру перешли.

Не думаю, что что-либо серьезно изменилось к 2001 году, по крайней мере в нашей стране.

Video: Двухпроцессорные конфигурации

Имеет ли смысл для ускорения преобразования AVI-файла из MJPEG (DC30+) в Cinepak в Adobe Premiere 5.1a использовать двухпроцессорную конфигурацию машины? Насколько быстрее следует ожидать процесс такого преобразования для разрешений 720x576, 25 fps, работая в Windows NT (2000), по сравнению с системой с одним процессором?

Ускоряться будет только компрессия, алгоритм которой явно поддерживает параллельную работу процессоров. Я не думаю, что Cinepak кодек это умеет. Из новых кодеков я знаю, что параллелизм поддерживается для microsoft MPEG4, www.microsoft.com/windowsmedia, LSX MPEG encoder, TMPEG encoder, Cinemacraft encoder, Panasonic MPEG1 encoder, и, может быть, некоторые другие.

Обычно производитель этим сильно гордится и на своем сайте об этом радостно сообщает.

Если говорить о кодеках вообще, то я рекомендую MPEG4 в варианте DivX 4.0x. Он очень хорошо сжимает видео и доступен бесплатно. В этой версии заметно снижены требования к процессору на стадии проигрывания видео. Впрочем, для видео с потоком менее 600 кбит/сек достаточно и P166mmx.

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

Из общеупотребительных кодеков indeo 5.10 работает намного быстрее и обеспечивает лучшее качество при таком же потоке данных.

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

Иногда длительное кодирование видео невозможно ночью из-за шума системного блока (жена не понимает) или вероятных проблем с энергоснабжением. В таких случаях покупка "кодирующего" компьютера с максимально тихим исполнением, источником бесперебойного питания и сетевой картой для связи с уже имеющимся компьютером выглядит оправданной. В качестве такого компьютера идеально подходит ... ноутбук. Правда, это не самое дешевое решение. Расположение кодирующего системного блока где-нибудь на кухне выглядит более дешевым вариантом. Управлять им можно встроенным в windows 2000 NetMeeting, устранив таким образом необходимость в мониторе.

Другим вариантом является перенос файлов для кодирования на другой компьютер, который по своему расположению не может быть источником проблем, например, на ваш рабочий компьютер, который ночью все равно работает. Тогда для организации кодирования достаточно купить пару mobile rack и жесткий диск объема, достаточного для транспортировки видео "в сумке"

Размер кадра выходного видео меня смущает. Для компьютера вам нужно оставить только одно поле (288 строк) из двух полей видео, поэтому нормальный выходной размер будет 384х288 для исходного PAL видео. Остальное - лишнее. Размер на экране можно сделать каким надо уже при проигрывании.

Video: Как построить магнитофон

Как решить такую проблему: нужно записывать видео-сюжеты с программируемого компьтерного ТВ-тюнера с разрешением лучше, чем 320х240.
Все, что я смог найти у производителей - это Life View LR-025, но там маленькое разрешение. Нет ли отработанной комбинации тюнера и оцифровщика видео-последовательностей с лучшим разрешением, которая могла бы работать в автоматическом режиме?

Задача с виду довольно простая, но не все так замечательно.

1. Размер таких файлов. Для avi формата он не должен превышать 2 Г. Это примерно 2.5 часа видео с потоком в 200 КБайт/сек. Можно и побольше поток данных поставить, но за счет сокращения длительности видео. Ограничение преодолевается автоматическим созданием новых файлов видео при захвате. Единственный кодек, приемлемо работающий при таких малых потоках данных – DivX 4.0х. Можете попытаться использовать Windows Media encoder, но я не знаю, насколько он хорош на деле. Мои попытки применить эту программу обычно заканчивались после того, как я видел, что кодировщик начинает сознательно пропускать кадры, считая, что оставшихся должно хватить. В принципе, такой подход должен приемлемо работать для видео, передаваемого через Интернет, но для записи видео с целью его просмотра на самом записывающем компьютере такое решение не кажется мне идеальным.

2. Рассинхронизация изображения и звука. Для avi формата это почти неизбежно, особенно на длинных файлах. Выход представляется а новом формате windows media, но такие файлы нечем редактировать. Действительно, эта программа может порождать видео с размером файла, ограничиваемым только доступным пространством на диске. См. www.microsoft.com/windowsmedia.

3. DivX 4.0 кодек может в реальном времени сжимать в avi файл видео с размером кадра до 384х288х25 Гц на моем домашнем PIII 933. Скорость потока данных (качество картинки) можно выбирать любой, но на деле средняя скорость потока данных редко превышает 200 кбайт/сек. Судя по загрузке процессора, не следует рассчитывать на существенно большие размеры кадра.

4. Microsoft WindowsMedia видео кодеки хорошо ускоряются в двухпроцессорных конфигурациях. Говорят что таким образом можно получить в реальном времени до 640х480х30Гц (для PAL, вероятно, следует читать 640х576х25Гц ) на dual PIII 800, под NT или 2000, разумеется. Качество полноразмерного видео в моих опытах при одинаковых с MPEG1/2 потоках данных было несравненно хуже, поэтому добавить мне нечего.

5. При размерах > 288 строк возникает проблема с полями видеосигнала. Дело в том, что видео передается с чересстрочной разверткой, 50 полей в секунду. Каждое поле - картинка содержащая половину строк, либо четные, либо нечетные. В одном поле 288 активных строк для PAL / SECAM и 240 для NTSC. Компьютерное видео работает с кадрами на экране монитора, а не с полями (кроме MJPEG компрессоров, которые понимают и поля, но выводят на монитор целиком кадры). Каждое поле - отдельная картинка, отснятая на 1/50 секунды раньше или позже соседней. В телевидении эти поля и отображаются на экране последовательно, что позволяет, за счет особенностей нашего глаза, получить хорошую плавность движений. В компьютере мы можем либо игнорировать одно поле совсем, либо смотреть на 25 кадров в секунду с совмещенными на них полями. Движущиеся объекты будут иметь зазубренные контуры. Если выходной размер меньше полной высоты кадра, то ВСЕ карты видеозахвата берут одно поле и добавляют к нему отдельные строки из другого. Такая картинка непригодна для просмотра. Поэтому, либо нужно оцифровывать в режиме 640х288 (одно поле) и потом растягивать по вертикали до 480, либо смириться с размером 384х288. Последнее, впрочем, лучше, потому что такое кино довольно легко оцифровывать с компрессией в реальном времени. Если при просмотре в полный экран применяется обычная современная видеокарта с аппаратной фильтрацией при растяжениях, то качество картинки будет мало отличаться от исходного 640x480. Если честно - будет, но не так уж сильно, зато поток данных будет заметно меньше.

6. Единственное что можно посоветовать – захват в режиме 384x288x25 любой картой на базе BT848 или BT878 микросхем, с тюнером или без. Работают они хорошо, а можно ли их запрограммировать - карты подчиняется всем законам video for windows, поэтому можно. Без программной компрессии видео использовать их тоже можно, но это минимум 3 MБ/сек данных. Из программных компрессоров в реальном времени работают при размере 384х288:

Indeo 5.10 - >266 PII (должен быть в системе - элемент IE4)
Morgan, PicVideo или Mainconcept MJPEG - >400 PII
MPEG4 v2 и v3 (Microsoft)>450 PII
DivX 4.0 – > PIII 700. Незаконнорожденных детей MPEG4 V.3 кодека от Microsoft использовать не рекомендую: ничем они не лучше DivX четвертой версии, и скоро должны отмереть.

Первые два дают большой поток данных на выходе (приемлемое качество будет при > 1 MБ/сек). Последние при компрессии в реальном времени по качеству соответствуют MPEG1 в video CD варианте или немного получше. Но и экономнее к диску относятся.

Video: Ох уж эти поля!

Наверное все, также как и я, при захвате video, пользуются программой Vidcap 32. Редактируют в разных редакторах, я пользуюсь "Premiere 5".
При загрузке в Field setting необходимо указать No Fields, Upper Field First, Lower Field First, после пробы всех трех вариантов, не выявив каких-нибудь отличий, остановился на Upper Field First, просто потому что в окошке оно первое. А недавно я установил Plugins "Panopticum Lens V1.0",это такие симпатичные многоугольные линзочки. После экспорта видео ровно половина изображения была черная, нижняя половина весело смотрелась через остатки линзочки, стоило мне изменить Upper Field на Lower Field First, уже нижняя половина изображения была черная, только после установки No Fields-получилось полноэкранное изображение.
Не говорит ли это о том что Vidcap 32 захватывает полные кадры, а редактор уже искусственно разделяет изображение? Как еще можно проверить какое поле захватывается первым?

Как мне кажется, в этом plugin некорректно сделана работа с полями. Я тоже получил такой эффект. Тут ничего не поделаешь, корректно эти эффекты работают только в режиме full frame или no frames.

Поля и их очередность важны, если видео делается для просмотра на телевизоре. Дело в том, что в ТВ сигнале передается последовательность полей, содержащих четные и нечетные строки кадра. Какое поле идет первым, для телевидения вопрос риторический (по крайней мере для наблюдателя: мы, даже с помощью прибора, можем обнаружить только чередование полей, поля равноправны), а вот для компьютера - нет. Два соседних поля объединяются в один полный кадр, который и записывается внутрь avi файла. Чтобы правильно потом этот кадр показать на телевизоре, декомпрессор должен знать, какое именно поле в этом полном кадре представляет собой картинку, отснятую раньше. Если upper first, то поле со строками 0, 2,... снято раньше и должно быть показано или обработано тоже раньше. Если наоборот, то последовательность показа полей на экране телевизора должна быть обратной. Если установлен режим "полный кадр", то весь кадр при расчете эффекта рассматривается как единая картинка.

MJPEG карта захвата с аппаратной компрессией знает, в какой последовательности надо показывать кадры захваченного ею видео. Поэтому, при простом редактировании без эффектов и переходов, видео будет выглядеть одинаково для всех способов обработки (ее просто нет!) полей. Вот и результат выглядит одинаковым.

А если применены переходы или эффекты, то ситуация меняется. Предположим, что в сцене есть быстрое движение или эффект быстро изменяет картинку во времени. Если последовательность полей задана правильно, то над полем, которое следует показать первым, преобразование будет сделано с параметром времени тоже более ранним, а над вторым полем с более поздним, как это и нужно. Если же порядок полей указан неверно, то на первое поле будет наложено преобразование, соответствующее более поздней стадии эффекта, и это может привести к ухудшению итога. Например, вы делаете плавное изменение яркости до нуля на 2 % за поле (1 секунда всего). При правильном чередовании полей яркость будет последовательно меняться как 100, 98, 96,..., а для неправильного такая же последовательность будет наложена на поля, которые будут на выходе иметь номера 2,1,4,3,6,5...

Поэтому на выходе получится вот такое изменение яркости: 98,100,94,96,90,92,... А это приводит к заметному мерцанию при спаде яркости.

Если будет установлен режим no fields, то эффект будет наложен на весь кадр, и с шагом в 25 кадров в секунду. Получится 100, 100, 96, 96,... на выходе. Затухание яркости будет менее плавным, что можно заметить. Еще хуже получится при движении, например титров. Если текст наложен с правильным чередованием полей, он движется по экрану плавно. Если последовательность полей неправильная, то текст при движении дергается, потому что фазы его смещения идут не как 1,2,3,4 а как 2,1,4,3. При обработке по полным кадрам текст смещается на один шаг за весь кадр и его движение выходит не плавным, текст дрожит.

Если такое видео смотреть на мониторе, то все всегда будет в порядке. Дело в том, что на монитор ВСЕГДА выводится весь кадр. Вы не сможете понять, что последовательность полей неправильная, просто потому что полей-то и нет. А на телевизоре все будет видно.

Если вам не нужно делать кино для телевизора, то обо все этом можно забыть, поставить no fields и жить спокойно.

Упомянутые вами эффекты с полями просто не умеют работать - ошибка разработки.

С полями вообще все довольно сложно, в том смысле, что правильный учет наличия полей накладывает специфические ограничения при редактировании видео. Можете почитать у Adobe на сайте.

Устанавливая высоту кадра, вы заставляете карту захвата проделывать простое масштабирование из полной высоты в 576 пикселов в заданную вами высоту. Если при захвате установлена высота в половину полной высоты кадра, то захват производится только для одного поля, потому что все строки другого поля игнорируются алгоритмом изменения размера по принципу "ближайшего пиксела". Если число строк в захватываемом кадре больше, чем в одном поле, ближайшими пикселами строки в выходном кадре будут попеременно группы строк из разных полей. При полном числе строк весь кадр содержит два поля вместе. Так работают все карты захвата аналогового видео. Следует добавить, что эти карты способны переключаться на работу с одним полем видео, если высота кадра равна или меньше высоты поля. Такое переключение просто необходимо для корректной работы при малых разрешениях (видеоконференции до массового внедрения USB видеокамер).

В качестве иллюстрации прилагаю три файла, показывающие результат просчета видео эффекта (изменение размера картинки от нуля до полного кадра) в режиме без полей (файл no_fields.avi), с правильным (файл Correct_order.avi), и неправильным (inv_order.avi) чередованием полей видео. Для имитации на мониторе того, что должно быть видно на телеэкране, я сделал три ролика в указанных режимах, а затем перевел видео, просчитанное с полями, в 50 Гц видео путем BOB deinterlacing (см. выше как это делается). Надеюсь, примеры достаточно наглядны.

Video: Короткие вопросы-ответы

Не слышно ли у Вас в Москве, по каким ценам можно купить D-VHS видики или пока еще все это слишком заоблачно?

Я пока знаю только JVC HR-DSR100 (cо спутниковым DBS тюнером). В продаже пока не встречал (он описан на www.soniko.ru/video/reviews/hrdsr100.htm).

Кажется, цена DVHS примерно $2500. Пыль осядет, посмотрим, что из этого получится.

Как Вы подключаете MPEG-2/DVD плату к телевизору и видику - у нее же только S-Video выход ?

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

Вообще говоря, надо найти в S-video разъеме ногу, на которой есть сигнал яркости, напротив ее - нога с сигналом цветности. Если их тупо соединить, то обычный телевизор показывает такой сигнал в цвете. Не уверен что простое соединение правильно, скорее всего надо как-то эти ножки развязывать - например соединять через сопротивления ом в 50-75. При кратковременном соединении ничего у меня не погорело, качество видео обычное, как из переходника. Может быть, такие развязочки и так уже внутри платы встроены, и можно просто соединять два выхода вместе - и все. Параметры сигналов на S-video отличаются, может быть, только амплитудой компоненты цветности, остальное - одинаково.

Весь смысл S-video в том, что два сигнала ходят по разным путям, и поэтому у телевизора нет нужны их разделять фильтрами и терять на этом часть разрешения в канале яркости. А сами компоненты сигнала одинаковые.

Я нацифровал с помощью miroDC30 видеофрагментов. Могу ли я теперь с ними работать в Премьере 5.1 без самой Миры? Нужен какой-то декодер? или без платы не обойтись?

Программные кодеки от Morgan, PicVideo и MainConcept работают с файлами от Миро в том числе. Для надежности стоит проверить совместимость, сделав пробные видео фрагменты. Конечно, программный кодек может не показывать полноразмерные кадры с полной скоростью, но редактировать с ним можно. См. ту часть моего обзора, где есть ссылка на то, как правильно менять тип кодека в заголовке файла, чтобы файлы использовали не мировский, а этот кодек.

В продаже появились USB карты оцифровки аналогового видео и даже USB видеотюнеры. Как вы думаете, можно ли использовать их для нелинейного видеомонтажа?

Нет. Для полноценного нелинейного видеомонтажа такие карты не подходят. Скорость передачи данных по интерфейсу USB 1.0 не превышает 12 мбит/сек. Даже при оцифровке в эффективные 12 бит на пиксел, при 25 кадрах в секунду теоретический предел размера кадра таких карт составляет примерно 230х170 пикселов. Таким образом, даже видео VCD стандарта с помощью таких карт не сделать. Назначение подобных устройств – видеоконференции или просмотр телепрограмм в маленьком окне с частотой его обновления 10-15 Гц.

Video: Еще о полях в видео сигнале

У меня сейчас установлен вариант с bt848. Во всех разрешениях, кроме максимального, захватывается только одно полуполе. Поэтому, если не считать движения рывками (все по статье) - все ок. В максимальном разрешении оба полукадра ложатся на один и при мало-мальском движении все режется по строкам полукадров. Я из статьи все-таки не понял, как можно сделать видео с обоими полукадрами. Да! И надо ли это? Есть ли обходные маневры?

На любом PC так и должно быть. Если вы это видео сожмете в MPEG2, с сохранением полей, то на телевизоре все будет показываться правильно. На PC всегда будет расслоение по полям. Так видеокарты устроены. Я имел в виду, что карта МОЖЕТ захватывать при полной высоте оба поля, и их можно потом использовать для приготовления видео, правильно показываемого на телевизоре. Это заранее не было очевидно.

При наличии Digital 8 и 1394 карты (камера есть, карты пока нет). Остается ли проблема с полукадрами?

Именно, при просмотре DV на PC с помощью любого программного декодера, и при выводе его в окно оцифровкой аналогового выхода самой камеры, на экране РС все будет выглядеть с зазубринами. На телевизоре, поскольку он показывает поля не оба сразу, а последовательно (сначала сканируются четные, а потом нечетные строки экрана: именно так, а не все в один прием, как на компьютерном мониторе) все будет в порядке. За это наши глаза отвечают.

Video: TV тюнер vs MPJEG карта. Немного теории

Означает ли, что карта TB-тюнер захватывает и выводит видеоизображение не хуже карт с аппаратной MJPEG компрессией ?

И да, и нет. ТВ тюнеры умеют захватывать видео только без аппаратной компрессии. Это означает, что любой формат захвата относится к категории некомпрессированных - отличаются они только количеством бит на пиксел. В RGB16, 24 и 32 их 16, 24 и 32 соответственно, в YUY2, YUV9, YUV12, BTUV - 16, 9, 12 и 12 соответственно. Эти форматы по-разному кодируют цвет.

Так, в RGB 32 и 24 каждая точка передается как RGB, по 8 бит на каждый канал. Еще 8 бит в самом расточительном формате резервируется для информации о прозрачности кадра. Каждый кадр является просто bmp изображением.

RGB16 или 15 и 256 (8bit) - это представление каждого пиксела номером цвета в палитре цветов, имеющей соответственное число этих самых цветов. Использовать их неразумно, если, конечно, нет желания получить видео именно с 256 цветами.

В этих форматах каждый пиксел имеет индивидуальный цвет, то есть четкость по цветовым составляющим такая же, как и по составляющей яркости. В то же время, в телевидении так делать не принято. Информация о яркости передается с максимальным числом деталей, а вот о цвете - примерно вчетверо менее подробная. Поэтому в компьютере тоже нет необходимости держать картинку с индивидуальными цветами каждого пиксела. Видеосигнал на самом деле состоит из трех разных сигналов, но не по каналам RGB, а содержит один сигнал яркости i, и два сигнала R-Y (u) и B-Y (v), называемых цветоразностными. Вот формулы пересчета, действующие для компьютера, и, как я убедился, работающие для телевизора тоже:

i=((76*r)+(150*g)+(29*b))/256
u=((–19*r)+(–37*g)+(56*b))/256
v=((78*r)+(–65*g)+(–13*b))/256

В этих формулах учитывается восьмибитное представление каждого канала цвета в видеокарте как целого 0…255

Например, если поставить фон как серый с RGB = 150,150,150, и поместить на нем зеленый (0,255,0) квадрат, то как на мониторе, так и на телевизоре такой квадрат при переводе в монохроматический (остается компонента яркости, на телевизоре можно просто убрать насыщенность до нуля) пропадет. На сером поле любой яркости u и v, всегда равны нулю, а на окрашенных участках - нет. Поэтому u и v называются цветоразностными сигналами, и передают они информацию о цветовой окраске предмета.

Форматы с таким способом передачи информации были придуманы и для цифрового видео:

YUY2 (UYV2) или 4:2:2 - строка разбивается на пары пикселов, каждый пиксел в паре имеет свое значение яркости, но вот информация о цветоразностных компонентах у них одинаковая. Это универсальный профессиональный формат, подходящий ко всем системам телевидения. Именно этот формат является первичным при оцифровке видео аналоговыми картами - сигнал яркости (Y), передаваемый в широкой полосе частот, подвергается выборкам с частотой ~ 13.2 МГц, а декодированные цветоразностные сигналы u и v, имеющие изначально более узкую полосу частот, оцифровываются с вдвое меньшей частотой выборок. Видеоданные именно с таким представлением о цвете точек и поступают на вход схемы компрессии внутри MJPEG карт. Каждая компонента образует как бы кадр - 704х576 для яркости, и 352х576 для каждого цветоразностного. Эти три кадра, по 8 бит инфомации на точку, и сжимаются потом по отдельности.

Простые карты типа ТВ тюнеров тоже производят такие кадры, но не сжимают их никак. Число бит на пиксел в таких форматах есть число бит, необходимое для передачи информации о нескольких образующих группу точках, деленное на число точек в группе. Для YUY2 (это код, записываемый в заголовок avi файла многими картами оцифровки без сжатия) точек две, для их описания требуется 8+8 бит для яркости, и по 8 бит для каждой цветоразностной составляющей - всего 32 бита для пары точек, или 16 бит на точку. Заметьте, это не то же самое, что RGB 16 - каждая точка может иметь любой цвет из 16 млн, а не 64 тыс цветов. Поэтому такой формат лучше передает медленные смены тона - не возникают линии перехода от одного цвета к другому. Если видеокарта умеет такой формат внутри себя еще и фильтровать, то ступеньки в цветовых составляющих (возникающие из-за назначения одинаковых U V паре точек), сглаживаются и на экране каждый пиксел имеет индивидуальные RGB значения. А умеют так делать все современные видеокарты, потому что именно такое представление цветов используется и в играх.

Таким образом, на выходе простой карты захвата получается то, что есть на входе компрессора в MJPEG картах. Размер такого видео больше в степень MJPEG компрессии раз, но и качество самое высокое, которое можно получить. MJPEG карта не всегда разрешает записывать несжатое видео в этом формате на диск, а зря, потому что преобразование в RGB (по приведенным выше формулам), не только ухудшает качество, но и съедает много процессорной мощности. Я об этом давно уже писал в конференции пользователей Матрокс, но был осмеян за то, что вообще захотел отказаться от аппаратной компрессии. Интересно, что полгода спустя у продуктов Матрокс была обнаружена недокументированная возможность записывать видео в YUY2 формате, и ей начали активно пользоваться. Но в операционной системе Windows 2000 она так и не появилась. Новые комбинированные решения от Матрокс уже не используют аппаратной компрессии – даже его маркетологи, наконец, осознали, что проблем с аппаратным кодеком больше, чем с только программными решениями.

В формате 352(384)x288 поток данных без дополнительного сжатия будет примерно 6 МБ/сек, что вполне по силам всем современным дискам, а проблемы с размером файла можно решать не путем его компрессии, в увеличением объема диска. Так можно и нужно делать сейчас - дешевле и надежнее.

Кстати, если вы хотите использовать программный компрессор, используйте именно этот формат оцифровки видео, потому что он является native (родным, или исходным) форматом почти всех компрессоров, и при кодировании исключается бессмысленная стадия программного преобразования RGB в YUV. Для примера приведу выписку из журнала кодировщика MPEG, в котором время конверсии RGB=>YUV сосчитано:

biCompression   = DIVX

trying yuy2.

YUY2 format was not accepted

>> File reading                  0.181    1.208 %

 >> Decoding                      6.527   43.510 %

 >> RGB -> YUY2                   1.789   11.927 %

---------------------------------------------------

 >> MPEG encoding                 6.503   43.355 %

Как видите, перекодирование может занимать значительную долю времени. Не забудьте, что DIVX кодек хранит видео в YUV 4:2:0 формате. Поэтому в строке Decoding также часть времени занята на перекодирование из YUV в RGB, и, скорее всего, этот процесс занимает не меньше времени. По неизвестным причинам, прямое использование YUV формата не удалось – компрессоры не "договорились" о формате общения. В принципе, следовало бы сообщить этот факт как недостаток DIVX кодека, потому что всякий уважающий себя кодек должен уметь выдавать кадры в YUY2 формате, являющемся наиболее распространенным, и для которого лучше организована аппаратная фильтрация и масштабирование во многих видеокартах. Кажется, написав эту фразу я понял, почему Divx видео на моей карте какое-то неидеальное. Неродной формат, однако...

BTYV (это способ реализации 4:1:1 оцифровки в картах на микросхемах BT 848/878) - это цифровой эквивалент NTSC. В этом формате четыре пиксела в строке группируются, и всей группе назначаются одинаковые значения UV. Число бит на пиксел - 12: 8х4 для яркости, и еще 16 для цветоразностных сигналов, всего на четыре точки нужно 48 бит. В вещательном NTSC ширина полосы частот цветоразностных сигналов примерно вчетверо меньше, чем для яркостного сигнала, поэтому такая схема позволяет оцифровывать NTSC без потерь. На глаз такое уменьшение цветового разрешения по горизонтали незаметно, чем иногда пользуются и JPEG-подобные схемы. Недостатком такого способа кодирования для профессионального применения является плохая резкость границ цветов. Если информация о цвете (один или оба цветоразностных сигнала) используется для объявления части картинки прозрачной, то граница области прозрачности имеет неопределенность в 4 пиксела. Например, в студии диктор сидит на фоне синего экрана. На дикторе нет синих деталей одежды. Лицо его тоже не синее. Тогда можно объявить все части кадра, имеющие синий цвет, прозрачными и, поместив такой кадр на кадр с пейзажем, получить картинку диктора, сидящего на любом фоне. Для правильности картинки нужно, чтобы границы синего и не-синего были максимально резкими, а это при назначении группе из 4 точек одинакового цвета сделать трудно. Поэтому в студиях используются более точные форматы, например YUV2, описанный выше. Впрочем, не все так плохо и для BTYV или 4:1:1 формата. Если такое наложение делается с минимальной фильтрацией и смягчением переходов, то получить нормальный результат не так и трудно.

Многие программные кодеки могут принимать этот формат в качестве входного. Поэтому, при использовании программной компрессии в реальном времени, попробуйте выставить этот формат у карты оцифровки видео, что должно уменьшить загрузку процессора в сравнении с RGB или YUY2.

YUV12 или 4:2:0 - Это формат, выдуманный для MPEG компрессии и для DV в стандарте PAL. Когда стали придумывать, как делать DV, для PAL хотели погнаться за двумя зайцами - увеличить цветовую четкость по горизонтали (как это и есть в аналоговом стандарте), но сохранить число бит на пиксел. Вспомнили (совершенно некстати), что приемник PAL, по идее самого формата, смешивает цветоразностные компоненты из двух соседних строк в поле - на экране показывается полусумма цветоразностных сигналов текущей строки и сигнала предшествующей строки, прошедшего линию задержки. Такое решение было придумано для устранения искажений, типичных для аналоговых трактов телевизоров первых поколений. Оно снижает разрешение по горизонтали, но не вдвое. Резкий вертикальный перепад цвета становится менее резким - одна строка содержит половину предыдущей цветовой компоненты. Это не очень хорошо, но приемлемо. Надо сказать, что на входе телевизора четкость по вертикали сохраняется полной, только внутри него она уменьшается. Поэтому всегда есть хотя бы теоретическая возможность за счет использования дорогих технических решений получить и на выходе полное разрешение.

При переходе к цифре решили, что можно для двух соседних строк объединить значения цветоразностных сигналов. Таким образом, в этом формате пикселы группируются по квадратикам 2х2, и им назначаются одинаковые цвета. Число бит на пиксел опять 12, но теперь в обоих направлениях четкость одинакова. Все это хорошо, но в телевидении используется чересстрочная развертка: каждый кадр - это две картинки по 288 строк, и именно по этим строкам и происходит объединение компонент цветности. Для аналогового видео, таким образом, четкость по вертикали определяется усреднением отдельно четных строк и отдельно нечетных строк, а для цифры - назначением им одинаковых цветов (вернее, окрасок). Реальная четкость получается вчетверо меньше числа строк в кадре. Для NTSC, в которой ничего не усредняется по вертикали, четкость тоже соответствует половине числа строк, если предмет движется, но для статичной картинки она полная - все строки несут индивидуальную информацию о цвете. В PAL это не так - даже в неподвижной картинке четные строки попарно имеют одинаковую окраску, и нечетные - тоже. Искажения такого рода незаметны для глаза, но очень сильно усложняют наложение картинок, описанное выше. Поэтому в профессиональной технике такой формат не любят. В DV, однако, такая схема применяется с самого начала, и с этим форматом нам и приходится иметь дело.

Условное обозначение формата довольно смешное: если в основании его лежит количество выборок каждой компоненты цвета на группу из четырех выборок компоненты яркости, то для выборок в пределах одной строки форматы 4:2:2 и 4:1:1 именно это и означают. Считать выборки на четыре точки было придумано только для того, чтобы в самом плохом из используемых в профессиональной технике форматов получались справа целые числа. А если выборки производятся из разных строк, то такая формула не работает. Вот и написали 4:2:0, что формально означает, что одна компонента вообще никогда не используется. Некоторые завсегдатаи конференций по редактированию видео вообще стали говорить, что в PAL что-то интерполируется между чем-то, поэтому-де и ноль справа, и трудности с chroma keying. Смысл такого обозначения - имеется одна выборка обоих цветоразностных сигналов на пару точек в строке, и эта же выборка применяется для пары точек на строке выше(или ниже) в том же поле видео. Ничего не интерполируется, никуда вторая компонента не девается.

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

Программные компрессоры MPEG всех сортов, способные сжимать видео в реальном времени, используют именно этот формат перед сжатием. Поэтому разумно предположить, что и на вход им следует подавать именно такой поток данных из карты видеозахвата. Впрочем, форматы 4:2:0 имеют неск

FAQ по созданию и редактированию цифрового видео

Вводные замечания

Video

Canopus DV Raptor

Digital8

MPEG2

Заключение

Для чего все это написано и как появилось на свет?

Video: Требования к компьютеру для видеомонтажа