FAQ по созданию и редактированию цифрового видео | |
Вводные замечания
Video
Canopus DV Raptor
Digital8
MPEG2
Заключение
Для чего все это написано и как появилось на свет?Я попытался суммировать переписку с читателями моего давнего обзора карты 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. По качеству, потери можно минимизировать выбором программы кодирования и его параметров. Я пробовал сравнивать на телевизоре клипы сделанные следующими способами: 1. исходный DV 2. DV => MPEG2 5300 kbps => DV (программно) => D8 камера 3. 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 кодеки) относятся в первую очередь: 1. Правильная работа с полями видео, включая поддержку понятия полей в недорогих и качественных аппаратных декодерах с выводом сигнала на телевизор. 2. Меры по автоматическому восстановлению синхронизации аудио и видео в MPEG потоке данных. 3. Потенциальная совместимость с бытовыми проигрывателями DVD 4. Помехоустойчивость, изначально заложенная в формате, допускающая потерю данных без нарушения целостности видео целиком: o для avi файлов потеря одного бита делает весь файл непригодным для проигрывания; o для 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 хотя бы средний по качеству (см. сравнения на http://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: 1. Размер кадра не менее 352х576, при отсутствии deinterlace фильтрации любого типа 2. Частота кадров 25 Гц (разумеется) 3. Отдельные кадры не содержат видимых на глаз типичных искажений от цифровой компрессии. То есть, контуры предметов не должны иметь ореолов (заметных с обычного для телевизионных просмотров расстояния), а кадры с быстрым движением (и другие тоже) – квадратиков, порождаемых компрессором при слишком сильном сжатии информации. 4. Видео в целом не должно выглядеть размытым более, чем это бывает на VHS копиях c VHS записей (то есть не хуже, чем после линейного редактирования оригинала с помощью камеры и видеомагнитофона VHS) 5. Не должно быть видно типично цифровых дефектов, вносимых иногда "интеллектуальными" фильтрами, типа temporal smoothing/noise reduction (фильтры, пытающиеся уменьшить поток данных в сжатом видео за счет избирательного замещения части кадра фрагментами предыдущего), чрезмерной адаптивной фильтрации шумов (фильтры, пытающиеся избирательно размывать части кадра, в которых соседние пиксели и так мало отличаются друг от друга) и им подобных. Наличие "компьютерных" составляющих может быть намеренным эффектом, но рывки в движении и какая-то "мутность" видео в целом могут полностью испортить впечатление от сюжета. 6. Не должно быть видно повышенной зашумленности видео, что происходит при достаточно больших потоках данных, когда "квадратики" уже почти незаметны на отдельных кадрах, но все же присутствуют и проявляют себя как шумы при проигрывании видео. 7. Дефекты кодека, такие, как подергивания или сильные искажения части картинки (обычно на краях, где компрессор безуспешно борется с дефектами сигнала самой видеокамеры размером в одну-две строки и в результате портит до 32 строк). 8. Должны быть установлены правильные уровни черного и белого, контраст, насыщенность, и цветопередача. Следует избегать ограничения сигнала снизу или сверху при оцифровке, которые приводят либо к обращению в черное значительной части темных деталей, либо к "выбелению" ярких частей исходного видео. Последнее сильно проявляется на кадрах с ярко освещенными солнцем лужайками, и приводит к превращению травы в бледно-зелено-белую субстанцию. В общем, цифровое видео должно смотреться на телевизоре так, чтобы зрителя не отвлекали добавки, внесенные в него с результате цифровой обработки. По моим представлениям, добиться такого качества можно при средних потоках данных не менее 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. исходный полный кадр разделяется на поля с четными и нечетными строками, 2. верхнее (с верхней строкой кадра)поле масштабируется до полного размера и его картинка смещается на полстроки вниз (интерполяцией) 3. нижнее поле масштабируется до полного размера и его картинка смещается на полстроки вверх (интерполяцией) 4. оба кадра показываются с интервалом в 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 видео на компьютере привели к следующим выводам: 1. Разница в качестве самого видео, сжатого хорошим MPEG1 и хорошим MPEG2 кодировщиками, при одинаковых потоках данных пренебрежимо мала, если ее вообще возможно обнаружить. Причем, этот вывод справедлив и для программного декодера windows, и для Hollywood+. 2. Существуют добротные кодировщики, поддерживающие только MPEG1 стандарт, например, от Panasonic. 3. Очередность полей видео при кодировании из DV или захваченного аналогового видео (по крайней мере, для моей карты Avermedia TV phone) в MPEG1 остается правильной. В принципе, это означает, что принятый в H+ порядок показа полей из полного кадра MPEG1 соответствует способу объединения полей в один полный кадр. Ведь никакого способа указать другой порядок полей в потоке MPEG1 данных просто нет. Hollywood + прекрасно показывает MPEG1 видео с полной высотой кадра и плавность движений полностью сохраняется. 4. При проигрывании MPEG1 видео на моем экземпляре no-name H+ нельзя использовать ширину кадра более 464 пикселов, если применяется используемый по умолчанию вариант кодирования с двумя B кадрами подряд. Установка только одного B кадра подряд снимает эту проблему и при полной ширине кадра (720 пикселов). Качество кодирования от этого сильно не ухудшается. 5. Разумеется, обычный медиаплеер Windows не умеет самостоятельно растягивать кадр MPEG1 уменьшенной ширины до нормальных пропорций картинки. Преодолевать это можно либо с помощью бесплатных плееров, использующих внутри windows media player control, либо созданием собственного варианта такого проигрывателя в Visual Basic. Не могу понять упорства, с которым Microsoft скрывает некоторые полезные свойства собственного произведения внутри кода. Например, в стандартном медиаплеере нельзя показать номер кадра видео, и нельзя двигаться шагами по одному кадру. H+ умеет показывать видео в полный телевизионный экран. 6. Пресловутая "расческа" всегда будет присутствовать при просмотре видео с полной высотой кадра на мониторе (я принципиально не рассматриваю перекодировку кинофильмов из 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: 1. Indeo 5.10 - >266 PII (должен быть в системе - элемент IE4) 2. Morgan, PicVideo или Mainconcept MJPEG - >400 PII 3. MPEG4 v2 и v3 (Microsoft)>450 PII 4. 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), называемых цветоразностными. Вот формулы пересчета, действующие для компьютера, и, как я убедился, работающие для телевизора тоже: 1. i=((76*r)+(150*g)+(29*b))/256 2. u=((–19*r)+(–37*g)+(56*b))/256 3. 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 имеют несколько кодов и способов упаковки данных, поэтому кодек может и отказаться работать с тем форматом (I420, IV12), который выдает ваша карта. Интересно отметить, что большинство декодеров DV или MPEG выдает кадры в формате не 4:2:0, а 4:2:2 (YUY2), хотя исходный формат распаковки видео именно 4:2:0. По–видимому, такой формат считается более универсальным. Другое объяснение – YUY2 формат постепенно вытесняет RGB даже внутри простых видеоредакторов. Придание соседним строкам независимых (пусть и одинаковых на выходе декодера) цветовых составляющих позволяет улучшить обработку видео. Последний формат - YUV9 (Intel Indeo Video Raw 1.1)- здесь точки группируются в квадратах 4x4. 16 пикселов имеют одинаковые окраски, но индивидуальные значения яркости. Формат неважный, но для прогрессивной, а не черестрочной разверки (1/4 захват) дает картинку мало отличимую от оригинала (YUV 4:2:2 или YUY2, YUV2). Его можно использовать для захвата видео, с последующим несложным редактированием и сохранением промежуточных результатов в более совершенных форматах. Среднее число бит на точку - 9. В качестве иллюстрации приведу несколько картинок, полученных из фрагментов кадра DVD фильма. Первая картинка содержит исходный кадр, оцифрованный в 4:2:0 формате (DIVX, цветовое представление 12 бит на точку в среднем): Вторая – тот же кадр, но преобразованный в 16 битное представление RGB (hi color): как видите, YUV представление, будучи более компактным, не вносит в видео контуров границ оттенков (banding artifacts) и не выявляет дефектов компрессии (исходный кадр был сжат DIVX компрессором). Поэтому не верьте словам о 16 или даже 12 битной глубине цвета в YUV форматах, какие до сих пор иногда проскакивают в некоторых обзорах. Все YUV форматы имеют общее - точно известно, сколько исходной информации о цвете было потеряно и сколько информации имеет в среднем один пиксел. Поэтому это не компрессия, а упаковка. Вообще говоря, формат MJPEG допускает использование любого из этих форматов как входного. Кадр разбивается на три под-кадра (три плоскости), размер для кадра яркости всегда полный, а для подкадров цветности - половинный, четвертинный, или даже 1/16 (по площади, или числу выборок). Все компрессоры именно эти подкадры и сжимают, избирательно удаляя часть информации уже из них. Насколько удастся уменьшить размер сжатого кадра - зависит от его содержимого и от параметров исключения избыточной информации. Размер кадра подгоняется к примерно постоянному подбором параметра выбрасывания информации. Поскольку подбор этот - занятие неопределенное, то размер кадра может изменяться довольно сильно и заранее неизвестно, сколько полезного из какого кадра было выброшено. При последующей перезаписи такого видео на кассету может оказаться, что выброшенная информация была бы полезна, а ее нет. На качестве картинки до ленты это может и не сказаться, а вот на ленте все будет выглядеть хуже чем хотелось бы. Тут я был вынужден отступить от обычного правила быть строгим - не знаю я, как компрессия и ее дефекты сказываются на записи на аналоговом магнитном носителе - это вещь субъективная. Но такое влияние, несомненно, есть. Еще одно отступление: в стандарте VHS или Video8 разрешение по горизонтали для компоненты яркости соответствует не более 352 точек на линию, а для компонент цвета - примерно впятеро меньше. Даже DV камеры на аналоговых S-video выходах для компонент цвета делают полосу пропускания вчетверо уже, чем для компоненты яркости. Таким образом, оцифровать VHS или даже SVHS видео без потерь информации можно и по схеме 4:1:1. Я не буду вдаваться в подробности, как видеомагнитофон изменяет разрешение по вертикали - не помню деталей, но то, что портит - без сомнения. Для нас важно, что формат захвата 4:1:1 содержит все, что нам нужно, даже в предположении, что каждая строка видеополя в видеомагнитофоне независима от соседней. Замечу, что в бытовых PAL видеокамерах независимости строк нет с самого начала - так устроена CCD матрица. Уже в ней строки смешиваются, но мы этим будем пренебрегать. Итак, в формате 4:1:1 мы имеем максимально достижимое качество при потоке 8 МБ/сек для половинного по ширине кадра. Именно это я и рекомендовал. Если применить программный MJPEG компрессор, то такое видео можно сделать по размеру поменьше, причем в реальном времени. Качество программных компрессоров MJPEG выше, чем у MJPEG карт с ценами бытового уровня. А процессоры нынче стоят не очень дорого и все равно нужны для всех дел. Поэтому я и говорю, что простые ТВ тюнеры сейчас смотрятся лучше. Если процессор слабый - можно писать несжатое видео и потом его сжимать уже после редактирования. Я так и делал сначала, торопиться мне было некуда. Если иметь данные карты на одном компьютере - будут ли они мешать друг другу и можно ли по заказу выводить видео то на один выход то на другой. и вообще даст ли мне это что нибудь (какой нибудь выигрыш). За исключением телевизора? Как они (ТВ тюнеры) выводят видео ? Не будут. Обе работают друг с другом нормально. В меню захвата видны два устройства - из них и можно выбирать. ТВ тюнеры никакого видео на телевизор сами не выводят. Это и есть их недостаток. Но, преодолеть его можно, либо используя выход видео вашей MJPEG карты (для вас это может показаться странным - зачем так делать, если уже есть MJPEG карта ввода/вывода), либо какое-либо надежно работающее дополнительное решение. Я попытался предложить точно работающее решение - изготовление MPEG2 видео. Если купить рекомендуемую карту MPEG2, то, помимо ее основного предназначения - просмотра DVD - появляется возможность делать видео в формате MPEG 1 или 2 и выводить его на телевизор. Это, в сумме с ТВ тюнером, стоит дешевле, чем работоспособное MJPEG решение. Если оно у вас есть и работает - ничего лучше для работы с аналоговым видео вам и не нужно. Последнее замечание можно отнести к маркетинговой философии. Карты MJPEG разрабатывались в основном для рынка довольно дорогих решений. Несмотря на некоторую архаичность их сейчас, следует признать, что года 4 назад производители могли себе позволить не экономить на качестве входных каскадов этих карт. На фоне чрезвычайно высоких цен на MJPEG карты производители ТВ тюнеров тоже могли делать свои изделия качественно и брать за них приличную цену. Покупатели хотели получить за свои, в любом случае немалые, деньги, по меньшей мере высококачественную оцифровку видео до компрессии, и отсутствие всяческих искажений на этом этапе. Сейчас ситуация несколько изменилась. Маркетологи уже научились позиционировать даже комбинированные видеокарты с аналоговыми ТВ входами-выходами как решения, пригодные для редактирования видео, но одновременно технологи научились экономить на качестве входных и выходных цепей и всем, что непосредственно не влияет на игровые свойства карт. Поэтому все мои рассуждения о простых картах оцифровки видео справедливы только с точностью до качества их изготовления сегодня. Моя Avermedia TV Phone 1997 года выпуска стоила 150$, и ради этих денег можно было постараться сделать и настроить все цепи качественно. За 30$ сейчас (без тюнера) – не знаю. Могу только порекомендовать внимательно испытывать конкретный экземпляр карты оцифровки видео на качество самой картинки. См. как пример обзоры недавно выпущенных комбинированных видеокарт. Общее замечание, что "раньше все делали лучше и солиднее" больше похоже на стариковское ворчание, но все же имеет некоторые основания. Video: Архивы на CDМожно ли записывать на CD - RW в формате AVI? C каким качеством и сколько сможем записать видео на компакт? Потребность записи - 1 раз в неделю, 15 минут исходного материала SVHS. Имеется МJPEG карта захвата. Можно записывать все, но качество видео, неважно в какой форме, зависит в конечном счете от степени компрессии данных, то есть от скорости их потока. К сожалению, все компрессоры видео делают это с потерей информации, а значит и качества. Если вы попытаетесь сжать видео с помощью zip или подобного ему алгоритма, то ничего не сожмется. Вывод - приходится пользоваться компрессией с потерями данных. Как это отражается на качестве - ваша карта выдает до 5 МБ/сек видео данных, уже сжатых с потерями, но с (теоретически) очень хорошим качеством картинки. Все-таки это не очень сильное JPEG сжатие. Но если записывать такое видео на CD, то и продолжительность такого файла будет небольшой, и скорее всего это будет именно архив - проиграть такое видео с диска без пропусков кадров вы не сможете. Придется сначала копировать этот архив на винчестер, а только потом играть. Но, такой вариант гарантирует сохранность исходных данных. Если стремиться записать побольше видео с некоторой потерей качества, то придется использовать более сильную компрессию и/или уменьшать поток данных за счет уменьшения размера кадра, например. Естественно, при таком действии вернуться к исходному качеству уже будет нельзя. Теперь о выборе компрессора. Если оставаться в пределах формата avi и компрессора, работающего на DC10 (MJPEG), то ничего хорошего при потоках менее 1.5 МБ\сек не получится. Компрессия MJPEG производит видео, в котором каждый кадр независим от соседних, и рассматривается как картинка. Такой способ принуждает даже одинаковые картинки сжимать индивидуально. Если же использовать компрессор, который пишет в файл только отличия одного кадра от предыдущего, то средний поток данных можно уменьшить значительно, и, соответственно, отдать больше байт на (примерно такую же JPEG) компрессию только некоторых опорных кадров, а не всех подряд. Типично для таких компрессоров (Indeo, Cinepak, MPEG1-4) сжимать только один из 5-25 кадров примерно также, как это делается в MJPEG, а для всех промежуточных кодировать только отличия. Например, в MPEG таким образом удается делать 1 кадр из 15 размером в 100-200 КБ (как и для всех кадров в MJPEG видео), а все остальные ужимать в 2-3 раза сильнее и почти не терять качества. Конечно, я оставил "почти", потому что кодирование таких отличий является во-первых, задачей сложной, во-вторых, неизбежно это делается тоже с потерями информации. Дело в том, что в видео никогда соседние кадры не содержат бинарных копий даже неподвижных изображений. Неизбежно присутствуют шумы, приводящие к тому, что при сравнении большая часть одинаковых по координатам пикселов на соседних кадрах будут иметь немного разные RGB (YUV) значения, даже если кадр совершенно неподвижен. Это будет даже при цифровых носителях, потому что шумит и сама CCD матрица при съемке. Алгоритм компрессии, таким образом, должен иметь какой-то уровень "терпимости" величины отличий, чтобы принять решение о том, существенны они или их кодировать вовсе не надо. Такой способ хорош всем, но для более сильного сжатия приходится порог увеличивать, и часть информации будет либо теряться, либо искажаться. Если сделать видео даже с маленьким потоком, отдельные его кадры могут выглядеть неплохо. Но при просмотре живого видео, даже статические объекты будут выглядеть на соседних кадрах чуть по-другому, из-за ошибок округления, прочих особенностей алгоритма. Вся картинка будет "шевелиться", вокруг резких границ предметов будут летать какие-то "комарики" - легкие тени от ошибок компрессора. Из всех способов компрессии, пожалуй, самым эффективным является MPEG2. При потоке данных в 0.5-1 МБ/сек можно получить почти полное соответствие оригиналу. Но вот проигрывать такой MPEG на телевизоре придется с помощью специальной карты. Я использую realmagic hollywood+ и работает он очень хорошо. Вот этот самый MPEG2 и можно использовать для хранения. Есть программки, которые позволяют из MPEGа опять сделать avi. Конечно, качество при перекодировках MJPEG-MPEG-MJPEG немного теряется, но это (для меня) лучше, чем хранить исходное видео на куче CD. Другой вариант - все видео всегда переконвертировать в DV формат и писать его на video 8 кассеты c помощью Digital8 видеокамеры. DV - это тот же MJPEG по основной идее, но оптимизированный. В нем кодек сам определяет части картинки, которые можно сжать посильнее без видимого ухудшения картинки, и отдает высвобожденные байты для кодирования более сложных частей. В MJPEG такой возможности нет, весь кадр ужимается с одним коэффициентом. Поэтому при равных размерах файлов DV имеет картинку лучше (если исходная была хороша, само собой). Этот способ подразумевает приобретение DV карты для подключения Digital8 видеокамеры. Мне он, конечно, больше всего нравится, хотя ничего, кроме самого DV видео, я так не храню. Но, в принципе, можно и DC 10 файлы именно так хранить. Хотя, если пойти таким путем и купить DV карту, то с DC10 можно прощаться. Сама Digital8 камера все оцифрует лучше, в более удобном формате, и еще сложит не на диск, а на кассету. Все диски пишу как диски компьютерных данных. Делать правильные video CD мне никогда не приходило в голову. MPEG2 с потоком 1 MB/сек нормально играет на моем DVD устройстве с CD-R или CD-RW матрицы. Следует только убедиться, что диск высококачественный. Некоторые No-name носители, хотя и не выдают явных ошибок чтения, читаются только с маленькой скоростью. Таких носителей, очевидно, следует избегать. Весьма подробные данные о качестве присутствующих на нашем рынке носителях можно найти на сайте IXBT.com. Video: Диалог о HDTVНасколько я знаю, все серьезные проекты high definition TV пока направлены на перевод киноленты в цифру или на цифровую фотографию с возможностью последующей печати кадров на бумаге. Для конкуренции с обычными фотографиями действительно нужно много пикселов… Это не так. В США и Европе уже вещают телеканалы в формате HDTV (кстати 2 разных формата). В США крупные телеканалы вроде NBC, CBS и т.п. переходят на HDTV вещание, в любом магазине продаются HDTV телевизоры. Есть много проектов по переходу киноиндустрии от аналоговой пленки к цифровым кинопроекторам, однако пока качество не является приемлемым, так что пленочные проекторы еще долго будут в кинотеатра. Для фотографий вряд ли используется HDTV, так как это still-image. Я в целом согласен, но на вопрос в заголовке цитируемой главки я ответил, по-моему, правильно. Нет пока доступных форматов. HDTV. Да, все это уже существует, однако, остается вопрос о том, откуда берутся изображения для HDTV вещания. Все цифровые форматы для видеокамер пока используют только 720 пикселов в строке. Конечно, можно такие кадры показать в окне с большим количеством пикселов, но это еще не hdtv. Как мне показалось, вся прелесть перехода на hdtv не в простом увеличении разрешения вообще, а в улучшении цветопередачи за счет перехода на другой стандарт кодирования видео, улучшении соотношения сигнал/шум. Наверное, подготовить действительно hdtv материал сейчас можно только из кинопленки или из фотографий, в том числе и цифровых. Нам же пока недоступны камеры, у которых есть 500 линий разрешения по оптической части. В DV видеокамерах для массового рынка просто не хватает для этого пикселов в CCD матрице(ах). Насколько я знаю, уже есть HDTV камеры (на западе). Я не знаю их точные параметры, но количество строк у них намного больше, чем у "обычных". Были планы по переведению всех каналов телевидения в США на HDTV, однако телекомпании активно сопротивляются из-за стоимости оборудования. HDTV камера стоит около половины миллиона долларов. Некоторые каналы уже передают отдельные программы в HDTV, например теннисный турнир US Open передавался в HDTV по каналу CBS (оборудование – Mitsubishi). По поводу сайтов о HDTV могу порекомендовать только сайты производителей, например http://www.philips.com/, www.sony.com/professional, www.mitsubishielectric-usa.com/, www.usa.canon.com/indtech/broadcasteq/index.html На сайте Sony можно найти кое-что о HDTV камерах. Philips очень мало выкладывает на интернете, все есть только на интранете, кроме того Филипс больше фокусируется на Consumer equipment, по крайней мере в лаборатории здесь. Автор реплик, выделенных зеленым текстом - Иван Крылов из Philips. Video: Native DV формат и работа с нимКак хранится DV видео на диске? Короткий ответ: DV видео на диске представляет собой файл с расширением avi. Кажется, что это все и объясняет, но Microsoft не может удержаться от того, чтобы одним именем назвать совершенно разные вещи. Если у вас достаточно старая карта IEEE1394, например Adaptec 8945 или Canopus DV Raptor, вам достаточно уже данного объяснения. AVI файлы, создаваемые программным обеспечением этих карт, являются обычными AVI (Audio/Video Interleaved), соответствующими спецификациям Video for Windows. В них имеется три потока данных – один видео и два аудиопотока (стерео). Заголовок файла содержит сведения о кодеке, размере кадра, длине файла и прочие данные. Такой файл будет читаем, если в системе установлен программный кодек соответствующего производителя. Кодек от Adaptec регистрируется в системе для кода dvsd, а кодек от Canopus использует код cdvc. Это не означает, что исходные видеоданные с ленты подвергаются какой-либо ре-компрессии при записи на диск. На самом деле, обе карты честно копируют видео- и аудио- данные в файл, но немного по-разному записывают их внутри файла. Если изменить в файле код компрессора (FourCC код) с одного на другой, то видео будет проигрываться на компьютере, но могут возникнуть проблемы при обратной перезаписи такого файла на ленту "чужим" устройством. Деталей я уже не помню, но такая проблема существовала. Главное преимущество совместимого с Video for Windows формата DV – именно в этой совместимости. Проблемы с ограничением на размер файла (2ГБ) были успешно решены практически всеми производителями таких карт, поэтому не стоит считать их серьезными. Почему же был придуман еще один формат записи DV? Вообще говоря, DV данные на ленте записаны как поток, а не в виде файлов. Разница состоит в следующем. Обычный файл, как правило, имеет заголовок, в котором содержатся данные о том, что с ним можно делать и как. Для avi в спецификации Video for Windows в заголовке указывается тип кодека, длина файла, размер кадра и прочая информация, которая нигде больше не повторяется. Поэтому если такой файл разрезать на части, то ни одна из них не будет корректным avi файлом. Первая часть будет содержать неправильное значение длины, а все остальные не будут вообще иметь заголовка. При потоковом способе хранения (или трансляции) видео, в блоках данных периодически (и довольно часто) повторяются параметры потока. Если по каким-то причинам происходит потеря блока данных при чтении (или приеме по каналам связи, если поток передается через сеть или со спутника), то сбой декодирования распространяется только на небольшую часть данных до чтения следующего блока с информацией о параметрах потока. Для декодера потока неважно, когда поток начался и когда закончится: декодирование будет продолжаться до тех пор, пока есть данные. DV данные (и MPEG данные из эфира или на DVD/CD носителе) представляют собой единый поток информации, в который упакованы и звук и видео. Разделение этого потока на аудио и видео (и другие, например субтитры для DVD или данные о параметрах съемки и код времени для DV) производится декодером. При записи DV потока с ленты на диск создается файл. Ничего другого операционная система и не умеет создавать. Обычно в него все же записываются сведения о длине видео. Это необходимо, например, для отображения длительности видеоклипа в плеере. В AVI файлах, создаваемых Adaptec Hot connect или Canopus DV Raptor, как мне приходилось читать, единый аудио/видео поток DV данных объявляется только видео потоком, а к нему добавляется аудио поток, выделенный из DV при записи файла. Такое решение увеличивает размер файла и влечет необходимость производить упаковку аудио и видео потоков итогового видео в DV поток данных при обратной записи на ленту. В DV AVI, созданном Microsoft драйверами IEEE1394 карт (почти все недорогие карты используют эти драйверы), данные хранятся как один комбинированный поток аудио/видео (копия данных на ленте). Так как ни аудио, ни видео потоков в файле нет, то реакция "правильного" Video for Windows приложения на попытку открыть такой файл будет:
Это сообщение одинаково для Adobe Premiere 4.2 и 5.1. Другие приложения могут реагировать на DV файлы этого типа иначе, но работать с ними не будут. Для работы с таким видео необходимы программы, умеющие его декодировать. Название типа DV файла, несовместимого со спецификациями VFW, для меня непонятно. Одни программы называют его DV video type1, другие – type2. Честно говоря, вместо присвоения номеров, лучше бы изменили расширение файла. Сравните, например, две картинки диалога, показывающего свойства двух файлов, содержащих идентичные видеоданные: Грустно это... Ведь выходит, что сама операционная система не ведает, что за файлы творит (верхний диалог). Научившийся понимать такое видео с последних версиях VirtualDub выдает следующее сообщение: Зато утилита Canopus DV file converter, умеющая преобразовывать DV файлы из одного формата в другой без ре-компрессии, именует их DV type 2 файлами:
Как видите, Канопус понимает под Type 1 DV обычные avi, да еще и с ограничением размера в 1 ГБ (строгое следование VFW). Ниже я буду придерживаться этой системы именований. Вот когда другая фирма выпустит бесплатные утилиты, делающие конверсию типов лучше или быстрее, и назовет форматы по-другому, я тоже буду готов изменить названия. До недавнего времени редактировать DV type 2 видео можно было только программами от Ulead Systems. Тем не менее, лишь недавно редактирование DV AVI в Ulead Media Studio Pro 6 стало нормально работать. Для это потребовались несколько патчей к самой программе, выпуск DirectX 8a и дополнительный DV patch уже к DirectX 8а. Теперь можно, наконец, и проигрывать медиаплеером эти DV файлы со 100% размером кадра, и качество встроенного в Windows DV кодека стало приемлемым. Поддержка Microsoft DV avi была встроена и в Adobe Premiere 6. Некоторые весьма полезные программы обработки видео тоже были модернизированы для возможности работать с DV видео. К ним можно отнести Virtualdub (частично) и TMPEG encoder. Что же делать, если нужно редактировать DV type 2 видео программами, не понимающими этот формат? Существует много вариантов, я приведу тот, который заработал у меня и не стоил мне денег или других затрат. 1. Скачайте с сайта Canopus утилиту DV file converter. Если размер исходного файла меньше 1 ГБ, конвертируйте ваш DV файл в Canopus Reference AVI или Canopus multiple editable avi files. Можете смело удалить оригинал после завершения конверсии. Полученный файл будет декодироваться бесплатным Canopus DV decompressor. К сожалению, полная версия кодека не будет работать без установленного продукта от Canopus. Впрочем, его полную версию можно купить отдельно. Если размер исходного файла больше 1 ГБ, становится доступной опция, показанная на рисунке выше. Ваш файл будет преобразован в набор файлов размером 1 ГБ или меньше. 2. Установите в системе либо полную версию Canopus DV codec (продается в составе некоторых программ от Canopus) либо Mainconcept DV codec. В зависимости от типа кодека вы можете либо оставить файл в формате Canopus DV, либо конвертировать его в формат MS DV type1 (для коротких файлов придется сделать это в два приема, потому что такая опция для них сразу недоступна). В последнем случае видео будет декодироваться:
Не понимаете, отчего такая путаница? Спросите Майкрософт. Для нас важно, что так можно отредактировать видео, избежать рекомпрессий, и даже вернуть его формат к виду, пригодному для копирования видео на ленту. Есть еще один способ, но он больше подходит для "питания" MPEG компрессоров данными из DV type 2 файлов. Для этого установите утилиту avisynth и используйте ее как сервер кадров видео. Об использовании этой утилиты см. другие части данного документа. Итог: сейчас уже можно заниматься монтажом DV видео, используя любые редакторы, даже если исходные DV файлы получаются с помощью дешевых IEEE1394 контроллеров. Для изготовления MPEG видео достаточно установить в системе преобразователь форматов и DV декодер от Canopus, распростаняемые бесплатно. Video: Надо ли хранить или лучше монтировать с кассеты?А если несколько кассет? А если в результате надо MPEG1 получать? Храню готовое DV видео на кассетах, как архив краткосрочный. На CD пишу MPEG1 или 2 с полным размером кадра - это позволяет сохранить поля и плавность движений. Для исходного материала VHS (c) или video8 можно использовать при кодировании в MPEG половинную ширину - 352 пиксела в строке. Так экономится размер в байтах. Для DV оригиналов желательно оставлять размер неизменным. В зависимости от особенностей сюжета, на один диск помещается примерно 10-15 минут видео с качеством, почти соответствующим DV формату. После DV лучше сжимать в MPEG1 или 2? MPEG2 лучше, потому что он в DVD совместимом варианте в точности соответствует DV по размерам кадра и явно поддерживает видео с чересстрочной разверткой (полями). MPEG1 про поля ничего не знает. Если же его их насильно заставить кодировать (просто установив размер кадра по вертикали полным) то (как ни странно), зазубрины не воспринимаются компрессором как большое количество высокочастотных компонент в кадре и качество почти не ухудшается. Впрочем, этому можно дать и научное объяснение: зазубрины добавляют в пространственный спектр сильную компоненту с максимальной частотой по вертикали, но один такой почти всегда присутствующий отсчет не может сильно изменить размер сжатого блока видео. Алгоритмы предсказания движения не перестают работать, поэтому качество сжатого видео сильно не ухудшается. При кодировке MPEG2 правильный кодер либо учитывает наличие полей в кадре, видоизменяя алгоритм кодирования кадра, либо явно разбивает кадр на поля и кодирует каждое как отдельную картинку половинной высоты. Разработчики дополнений от MPEG1 к MPEG2 ожидали уменьшения потока данных при кодировании видео с чересстрочной разверткой за счет учета полей примерно на 10%, при заданном уровне потери качества при компрессии. Надо сказать, что при достаточно больших потоках данных разницу в качестве между видео с потоком в 6 и 6.5 Мбит/сек заметить непросто. Поэтому, даже если принять на веру возможность сэкономить 10% на размере файла при кодировании MPEG 2, вы вряд ли заметите разницу при одинаковых параметрах кодирования. Этим и объясняется мое предложение не списывать MPEG1 со счетов при работе с полноразмерным видео. Видео на ленте я планирую держать до тех пор, пока не решу, что могу стереть. Хотя уже и появились кодировщики, способные кодировать в реальном времени полноразмерный MPEG2 на PIII 1000, я не спешу уничтожать оригиналы на Digital8 кассетах. Вообще говоря, довольно быстро привыкаешь к хорошему и начинаешь видеть такие малозначительные дефекты на видео, что никак не можешь остановиться в поисках лучшей схемы кодирования MPEG. Пока вот пишу файлы MPEG2 на CD и дублирую на ленте. Ведь при цифровой перегонке на ленту я качество не теряю - так почему бы им не полежать - вдруг понадобятся? Есть у меня мечта все это еще раз (на пенсии, до которой еще 20 лет) все это сделать не хроникой, а тематически. Вот только времени на это надо - тьма. Если сбрасывать на ленту итоговое видео не планируется, то что меняется? В целом – ничего. Можно смотреть итоговое видео на компьютере. Копии видеоклипов можно распространять на CD ROM. Я думаю, что в случае с DV форматом оригинала, имеет смысл сохранять итоговое видео на ленте в течение некоторого времени. Жалко сразу уничтожать наилучшую возможную копию. В случае с VHS оригиналом, правильнее было бы сохранить итог на CD в формате, допускающем запись на VHS ленту в любой момент. Видеомагнитофоны есть практически у всех, а вот с компьютерами пока дела обстоят не столь хорошо. Иногда видеокассета является единственным способом показать ваше произведение. Если же вы настроены на хранение только максимально компактного видео, то не забудьте позаботиться о сохранении рядом с ним и программы декодирования. Кто его знает, что будет с компьютерами в будущем? Я бы все-таки советовал хранить видео в формате, который по прогнозам останется в употреблении максимально долго. Пока таким форматом является MPEG 1 или 2. Кстати, за два с половиной года качество видео на моих первых лентах не изменилось, что в какой-то мере является подтверждением стойкости формата Digital8. Точнее, не появилось проблем с выпадениями сигнала на ленте. Качество цифрового видео, разумеется, не может меняться по другой причине. Video: И снова про поляДавно приобрел себе плату Avermedia TV Phone и все бы было хорошо но при полноэкранном видео идет через строчный режим. Это проблема софта, или это из-за большого потока данных? Если это из-за софта то как можно устранить? Это проблема телевидения при его переносе на экран компьютерного монитора. В телевидении всегда кадр состоит из двух разных по содержанию картинок: четные строки формируют одно изображение, а нечетные другое, отснятое на 1/50 сек раньше (позже). Поэтому на краях двигающихся предметов всегда есть зазубрины. Телевизор и показывает эти полукадры один за другим, так что зазубренности не возникает - разные картинки высвечиваются в разные моменты времени. Глаз не успевает отреагировать на быструю смену четных и нечетных полей, и воспринимает всю картинку как видео с частотой повторения "кадров" 50 Гц. Это дает иллюзию плавного движения при ширине полосы пропускания вещательного канала, соответствующей только 25 полным кадрам в секунду. Компьютеры работают в режиме прогрессивной развертки, и показывают всегда полный кадр. То есть на экране сразу показывают оба поля кадра. Это неправильно с точки зрения последовательности смены картинок, и воспринимается как зазубрины на краях: Вот картинка, иллюстрирующая эффект: Как видите, изображение птицы в верхней части кадра раздвоено. И причина этого именно в том, что в кадре содержится две независимых картинки. Бороться с этим бессмыссленно, никаких решений, кроме отбрасывания одного поля целиком, не существует. Такое отбрасывание делается при размере захватываемого кадра 288 или меньше строк. Четные (или нечетные) поля просто игнорируются. Движения получаются немного дерганые, особенно на сценах с поворотами камеры. Если же поставить высоту кадра 288< H <576, то получится вообще ерунда - в кадре будут ВСЕ строки одного поля, и добавлены равномерно строки другого поля, ровно H-288 штук. Смотреть на это без слез нельзя. Второй вариант для карты захвата – попытаться масштабировать картинку до выходного размера простым методом "ближайшего пикселя". В этом случае в кадре попеременно будут фрагменты одного и другого полей. Поэтому захват всегда должен быть с высотой кадра или полной, или не более половинной. Если нужно, чтобы все выглядело хорошо при просмотре полнокадрового видео на мониторе, то:
К сожалению, я не знаю ни одной железки, которая показывает видео на мониторе в режиме по полям. Кажется, что уже давно пора это сделать - показывать 50 кадров, формируемых из полей путем разделения полного кадра на эти самые поля и затем их последовательного выбрасывания на экран. Производительности должно хватить, не хватает только желания. Если вы установите у себя утилиту avisynth, то вот такой скрипт может показать видео как последовательность 50 кадров, скомпонованных из исходных полей: Avisource ("c:\myvideo.avi") SeparateFields bob
Подставьте в первую строку имя вашего файла, сохраните скрипт в файл с расширением avs и вбросьте его в окно Windows Media Player. Не гарантирую, что скорость проигрывания видео будет больше пары кадров в секунду, но "расческа" пропадет. Если импортировать такой файл в редактор видео, то в его свойствах будет показано 50 кадров в секунду. Программная реализация такого рода довольно медленна, но аппаратура видеокарты вполне могла бы справиться с такой задачей. Video: Какая карта аналогового захвата лучше?Так и не нашел ответа на интересующий меня вопрос - какую карту видеозахвата лучше всего использовать для захвата не DV, а обычного аналогового? Или я невнимательно читал? Если Вы прочли мои вводные замечания, то из них следует, что в обзоре собраны мои личные впечатления от того, что я сам пробовал. Из аналоговых карт я пользовался Avermedia TV phone и Matrox Rainbow Runner G series в сочетании с Matrox Mystique G200. Avermedia TV phone (или любая подобная ей) - это просто TV tuner и карта захвата аналогового видео без компрессии. Достоинство ее в простоте использования, низкой цене, очень хорошей стабильности в работе. У нее оказалось также наилучшее качество захвата видео (картинка) по сравнению с Matrox Rainbow Runner G series и аналоговой частью DV Raptor. Канопус выпустил драйверы к DV Raptor, позволяющие захватывать аналоговое видео без аппаратной компрессии, тем самым превратив Raptor в карту аналогового захвата тоже. Недостаток таких карт в том, что размер видео файла получается очень большим. В то время, когда я эту карту купил (январь 1998), у меня был P200, даже не MMX. Мощности процессора не хватало для захвата с программной компрессией, поэтому пользоваться такой картой для чего-либо, кроме изготовления MPEG1 с размером кадра 384х288, было практически невозможно. Теперь, когда за разумные деньги можно купить в десять раз более быстрый (по скорости вычислений для компрессии видео) процессор и очень сильно подешевели и улучшились в параметрах жесткие диски, этот недостаток в значительной мере преодолен. Судите сами: если у вас есть быстрый 800+ PIII, FCPGA Celeron или AMD процессор, то вы можете использовать программные компрессоры MJPEG и еще несколько других им подобных (например, Mainconcept DV codec) для компрессии в реальном времени. Цена процессора сейчас менее $200. Или, купив диск объемом не менее 40 GB за каждые $100, вы можете захватывать видео и без компрессии, вплоть до полноразмерного. В последнем случае вы получаете максимально достижимое качество видео. Еще один недостаток связан с невозможностью вывода видео на телевизор средствами самой карты захвата. В принципе, это можно довольно просто решить, если купить MPEG2 карту - декодер. Она и сама по себе не лишняя, как DVD комплект, а побочным ее свойством является способность показывать любые MPEG файлы. Если переконвертировать готовое видео в MPEG2 с большим (1.5-2 МБ/сек) потоком данных, и только с I кадрами (это фактически аналог MJPEG), то качество картинки на телевизоре будет практически идеальным. Цена такой карты примерно $60. Итого, при условии, что у вас уже есть компьютер, затраты на систему захвата/редактирования аналогового видео будут примерно 35 (карта захвата видео без тюнера, или на $30 больше за тюнер) +100 (диск) + 31 (половина цены MPEG2 декодера, остальное можно приписать его многофункциональности) = $166. Если вы купите MJPEG карту с аппаратной компрессией, то потратите не меньше, но не получите ни ТВ тюнера, ни средства показа MPEG видео на телевизоре (любых MPEG файлов, не только собственных, но и Video CD и DVD), ни диска. Все это придется покупать дополнительно. Кроме того, опыт использования этих карт показывает, что они бывают капризны. Так, их не следует использовать для захвата видео со старых лент с дефектами - теряются практически все слегка искаженные кадры. Карта может иметь индивидуальную несовместимость с некоторыми материнскими платами. У меня была карта Rainbow Runner G, к которой требовалась дополнительно Matrox G400 Dual Head. Проблемы, отмеченные выше, разумеется, никуда не девались. Необходимость быть привязанным к Матроксу по части видеокарты не вполне подходит для многофункционального компьютера, если учесть неспособность Матрокса конкурировать на рынке 3D ускорителей. Мой собственный опыт использования такой системы следует признать неудачным. Помимо проблем с неустойчивой работой "железа", качество видео при использовании VHS-C записей и VHS магнитофона оказалось ниже ожиданий. После покупки Digital8 видеокамеры выяснилось, что качество видео на входе стало слишком хорошим, и возникли проблемы со сбоями из-за проблем с контролем за потоком данных внутри схемы аппаратной компрессии MJPEG. Этот поток мог легко превысить внутренний предел аппаратного компрессора, что приводило к пропускам кадров или к сильным искажениям в захваченном видео. Да и потеря качества по сравнению с оригиналом чувствовалась тоже. Лучше уж купить приличный 3D ускоритель, ТВ тюнер, Hollywood+ MPEG2 decoder и диск впридачу. Редактирование будет не таким удобным, но имейте ввиду, что мне, например, приходилось тратить уйму времени на "воспитание" MJPEG карты, так что производительность определялась именно этим параметром. А у меня довольно большой опыт настройки железок. Теория о том, что всякая система нелинейного монтажа должна строиться путем построения компьютера вокруг карты захвата, для нас не слишком подходит. После покупки Digital8 видеокамеры и DV карты, пришел к выводу, что такая комбинация является оптимальной и по качеству, и по возможностям, в том числе и для захвата аналогового сигнала. При цене, сравнимой с ценой DC30+, D8 камера является идеальным устройством захвата и хранения оцифрованного видео, даже если оно изначально было снято аналоговым устройством. Учтите еще ее способность снимать видео самостоятельно. Цена решения: примерно $600 за камеру, и придется добавить еще немного за DV карту. Модели Digital8 видеокамер от Sony, начиная с 2000 года, все умеют переводить входной аналоговый телевизионный сигнал (только PAL) в поток DV данных на выходе I-link в режиме СТОП. Используя такую камеру как карту захвата видео, вы не расходуете ресурс ее механики. Я не могу рекомендовать такое решение всем, но подумайте - цену "карты захвата" в $600 следует поделить пополам, потому что это еще и полноценная цифровая видеокамера. Если учесть, что такое устройство можно использовать как стример для хранения видео, то вычтите из этой цены еще и цену стримера. И на объеме дисков можно сэкономить. 14 Гб видео на кассете за $3 - это очень хорошо. Даже в сочетании с моим достаточно дорогим Canopus DV Raptor все это смотрится довольно красиво. Качество видео - наилучшее из всего, что я видел. Я имею в виду именно качество оцифровки внешнего аналогового видеосигнала. Дело с том, что DV формат заметно лучше по качеству, чем MJPEG. Мне было не очень легко решиться на такие затраты, но результат превзошел ожидания. Все равно рано или поздно придется переходить на формат получше VHS, а если оставшийся аналоговый архив можно после такого перехода легко оцифровать и сохранить, то почему бы так и не сделать? В попытках сделать приемлемую систему редактирования аналогового видео я потратил даже больше денег. Не скажу что впустую, но и выигрыша от наращивания памяти, мощности процессора, размера и скорости дисков, я получал не очень много, а вот переход на Firewire общение компьютера с видеокамерой показал, что так и надо было делать, а потом потихоньку наращивать все остальное. Просто оказалось, что совокупность требований к компьютеру для DV намного ниже, чем для аналоговых решений, при гарантированном качестве самого видео. Недавно на рынке появилось множество не слишком дорогих решений, в основе которых лежат аппаратные DV кодеки. Такие карты могут работать как с DV, так и с аналоговыми видеокамерами. Форматом записи видео на диск во всех случаях является DV. Я не испытывал таких карт сам, но, если информация о них достоверна и драйверы работоспособны, такие карты представляют собой почти идеальное решение.
|