Huffyuv avi lossless video codec remove only что это
Друзья, помогите, пожалуйста, прикрутить кодек Huffyuv v2.1.1 к Win7x64 Захватил с VHS несколько файлов этим кодеком, ещё когда сидел на WinXP. А сейчас юзаю Win7x64 и не могу открыть видео в этих файлах (звук есть). Что делать? Help me |
Конфигурация компьютера | |
Процессор: Intel Core i7 Q720 | |
Память: 4 гб | |
HDD: 500 гб | |
Видеокарта: NVIDIA GeForce GT 240M | |
Ноутбук/нетбук: Lenovo Y550P | |
ОС: Windows 7 - 64 Ultimate SP1, Windows 10 ent - 32 on VHD | |
Индекс производительности Windows: 5,9 |
Для отключения данного рекламного блока вам необходимо зарегистрироваться или войти с учетной записью социальной сети.
Пакет k-lite пробовали? Этот кодек входит в его состав. Попробуйте еще video_conversion_pack » |
Тут дело вот в чём. Если бы вопрос касался только просмотра видео, то да, тогда бы я поставил какой-нить кодек-пак. Мне же нужно поработать с редактированием видео, по этой причине установка мультипаков не приветствуется, желательно установить только те кодеки, которые действительно нужны для работы.
. не понятно, почему видео нет, Huffyuv вроде устанавливается и рапортует что всё ок, а видео нет
Причём, на ХРшке всё работает.
upd.
Вот, ещё нюанс обнаружился. Если в win7x64 открыть файлы захваченные посредством данного кодека в virtualdub, то всё работает (и звук и видео), а если в sony vegas или каком-нить плеере, то работает только звук. Непонятно.
Последний раз редактировалось YanTo, 11-10-2009 в 11:01 . Причина: upd.
Конфигурация компьютера | |
Процессор: Intel(R) Core(TM) i5-2300 CPU @ 2.80GHz | |
Материнская плата: Gigabyte GA-H67MA-UD2H-B3 | |
Память: Hynix HMT325U6BFR8C-H9 2x2Gb + Hynix HMT351U6BFR8C-H9 2x4Gb | |
HDD: Hitachi HDS721010CLA332 | |
Звук: Realtek ALC889 | |
Блок питания: Asus 500W | |
CD/DVD: Optiarc DVD RW AD-7201S ATA Device | |
Монитор: Acer V243HQAbd | |
ОС: Windows 7 Ultimate x64 SP1 RTM (6.1.7601) | |
Индекс производительности Windows: 5,1 |
- Извлеките файлы: huffyuv.dll и huffyuv.inf в C:\Temp
- Запустите командную строку от имени администратора (Важно!).
- В окне командной строки введите: "cd C:\Windows\SysWOW64" без кавычек.
- Введите: "rundll32.exe setupapi.dll,InstallHinfSection DefaultInstall 0 C:\Temp\huffyuv.inf" без кавычек.
- Если не появилось ошибок - уходим на перезагрузку. Если же ошибка возникла - повторяем пункт №4 (возможно 3-4 раза).
Возможно, придётся попробовать с каждой из них.
YYYn, спасибо большое, Ваша рекомендация помогла!
Помогла, правда, частично, потому что винда кодек видит, а вот софт как-то не совсем.
WMP12 стал видео открывать и исправно показывать. MPC-HC говорит, мол, кодека нет и играет только звук. Так же ведёт себя и Vegas (это очень грустно). По поводу Vegas и MPC-HC, я так понимаю, надо разбираться непосредственно с самими программами, а не с виндой.
Как делал.
С Вашей подсказки, набросал простейший
pause - чтобы контролировать наличие\отсутствие ошибок
и положил его в корень С: , а в C:\Temp сложил huffyuv.dll и huffyuv.inf .
Батник запускал от админа. Что интересно, WMP стал открывать проблемные файлы сразу - до перезагрузки ПК.
Что касается Win7 - наверное, можно считать что проблема решена. По поводу вегаса - пойду на их форум Спасибо!
Конфигурация компьютера | |
Процессор: Intel(R) Core(TM) i5-2300 CPU @ 2.80GHz | |
Материнская плата: Gigabyte GA-H67MA-UD2H-B3 | |
Память: Hynix HMT325U6BFR8C-H9 2x2Gb + Hynix HMT351U6BFR8C-H9 2x4Gb | |
HDD: Hitachi HDS721010CLA332 | |
Звук: Realtek ALC889 | |
Блок питания: Asus 500W | |
CD/DVD: Optiarc DVD RW AD-7201S ATA Device | |
Монитор: Acer V243HQAbd | |
ОС: Windows 7 Ultimate x64 SP1 RTM (6.1.7601) | |
Индекс производительности Windows: 5,1 |
YanTo, пожалуйста!
А все 3 кодека попробовали?
YYYn, да, попробовал все три версии, плюс ту, с которой собственно и был сделан захват.
Сегодня видел информацию, что якобы к Win7x64 довольно сложно прикрутить кодеки не х64. В том смысле, что если кодек х86, то х64 софт этот кодек не увидит. Вот я и думаю, может поэтому Vegas x64 не видит моё видео, т.к. huffyuv - это х86 кодек (хотя, пробовал и версию huffyuv64 - не помогло). Вобщем, надо проверять.
Конфигурация компьютера | |
Процессор: Intel(R) Core(TM) i5-2300 CPU @ 2.80GHz | |
Материнская плата: Gigabyte GA-H67MA-UD2H-B3 | |
Память: Hynix HMT325U6BFR8C-H9 2x2Gb + Hynix HMT351U6BFR8C-H9 2x4Gb | |
HDD: Hitachi HDS721010CLA332 | |
Звук: Realtek ALC889 | |
Блок питания: Asus 500W | |
CD/DVD: Optiarc DVD RW AD-7201S ATA Device | |
Монитор: Acer V243HQAbd | |
ОС: Windows 7 Ultimate x64 SP1 RTM (6.1.7601) | |
Индекс производительности Windows: 5,1 |
Сегодня видел информацию, что якобы к Win7x64 довольно сложно прикрутить кодеки не х64. В том смысле, что если кодек х86, то х64 софт этот кодек не увидит. Вот я и думаю, может поэтому Vegas x64 не видит моё видео, т.к. huffyuv - это х86 кодек (хотя, пробовал и версию huffyuv64 - не помогло). Вобщем, надо проверять. » |
YYYn,
vegas 9-ый, редакция х64. Открыть требуемое видео отказывается.
Сегодня видел совет, что для такого случая нужно поставить vegas x86 и работать в нём. Кодек к самой винде, я так понял "прикрутился", т.к. WMP работает, а вот чтобы vegas увидел х86-ой кодек, vegas тоже должен быть х86. Завтра буду пробовать
Это первый и единственнык косяк (фича?), который меня существенно огорчил с момента выхода первой беты Win7.
Последний раз редактировалось YanTo, 12-10-2009 в 21:50 . Причина: upd
Недостатком lossless компрессии является требование к месту на диске. Если исходное видео было 50 MB, то сконвертировав его с помощью lossless кодека вы получите несколько сотен мегабайт.
Как вы успели догадаться, помимо сжатия без потери качества, есть еще сжатие с потерей качества (Lossy compression). Таким способом жмут видеопоток все популярные кодеки (xvid, divx, x264 и многие другие).
Для чего нужно сжатие без потери качества
Сжатие без потери качества необходимо в том случае, если нужно перенести видео из одной программы в другую. Представьте ситуацию, вам прислали видео с телескопа, который записал его в хитром формате и ваш любимый видеоредактор не может его открыть. Тут возможны два варианта:
- С помощью сторонней утилиты сконвертируем исходное видео в формат понятный для видеоредактора (например в mp4). Но в этом случае есть шанс потерять в качестве, так как любое (почти любое) преобразование видео из одного формата в другой ведет к ухудшению картинки, даже если вы отвели под это гигантский битрейт. Этот вариант нам не подходит, так как информация с телескопа ценная и вот так просто разбрасываться качеством картинки мы не имеем права. То есть, в данном случае мы отказываемся от Lossy кодека.
- Давайте преобразуем это видео не в широкораспространенный формат (mp4), а в другой. В тот, который сохранит все наши данные в первозданном виде. А полученное видео мы скормим видеоредактору. Для этого возьмем кодек Huffyuv. Как говорит Wikipedia этот кодек сжимает без потерь и сжатое видео полностью совпадает с исходным. Как вы уже поняли, Huffyuv относится к семейству Lossless кодеков, а это именно то, что нам нужно.
Как сжать видео без потери качества
Для того чтобы сконвертировать наше видео при помощи кодека Huffyuv мы возьмем самые распространенные бесплатные программы ffmpeg и mencoder. Они поддерживает кучу экзотических форматов и конечно же смогут закодировать кодеком Huffyuv.
FFmpeg
Что такое FFmpeg, где его скачать и как его установить я подробно расписал в этом руководстве.
После установки необходимо проверить поддерживает ли, скачанный вами ffmpeg кодек Huffyuv. Для этого выполните:
Если на выходе будут вот такие строки:
значит можно приступать к кодированию.
Mencoder
Проверим, поддержку кодека Huffyuv нашим mencoder.exe:
В отличии от ffmpeg, mencoder не показал нам наличие строки huffyuv в запросе на поддерживаемые кодеки. Но зато он выдал вот такую строчку:
У неискушенного читателя может возникнуть вопрос. Зачем проверять ffmpeg и mencoder на поддержку тех или иных кодеков (в нашем, случае huffyuv)? Ведь эти инструменты объявлены универсальными и утверждается, что они поддерживают все возможные форматы кодирования мультимедиа. Дело в том, что существует много различных сборок ffmpeg и mencoder. Какие-то сборки поддерживают один кодек, но не поддерживают другой, другие наоборот. Можно собрать ffmpeg и mencoder таким образом, что они будут работать только с одним форматом данных (например h.265). Соответственно они будут иметь очень маленький размер. Для чего это нужно? Ну может для всяких встраиваемых систем, типа Raspberry Pi или на WEB серверах (вдруг захочется свой YouTube запилить 🙂 ).
Сравнение
Попробуем сжать следующее видео без потери в качестве изображения:
Волны были выбраны не случайно, потому что для видеокодека нет ничего сложнее чем движение по всему кадру и наличие мелких частиц, хаотично летающих по всем направлениям.
Но прежде чем закодировать это видео с помощью кодека Huffyuv (сжатие видео без потери качества), мы сначала сделаем, кое что еще.
Бытует мнение, что если использовать стандартный Lossy кодек, например x264, но сказать ему использовать сколько угодно большой битрейт (пусть ни в чем себе не отказывает), то мы получим сжатие без потери качества. Давайте проверим:
После этого сразу запустим кодирование с помощью huffyuv, чтобы получить видео без потери качества (Lossless кодирование):
Получился файл размером 1300 MB, что в 65 раз превышает исходный по размеру. Дисковым пространством приходится жертвовать.
А теперь сравним, полученные видео с оригиналом.
Исходное видео 20MB
Для нахождения разницы между изображениями воспользуемся Imagemagick (мощный консольный редактор изображений):
в данном случае мы вычли img2.jpg из img1.jpg и результат записали в diff.jpg
На этих картинках мы видим, что Lossy кодек, как и ожидалось, теряет в качестве при кодировании, несмотря на то, что мы разрешили кодеку брать сколь угодно большой битрейт. Серые разводы на левой картинке указывают на то, что исходная и оригинальная картинки различаются.
Huffyuv выступил на отлично. Черный квадрат указывает, что различия отсутствуют и оригинальная и закодированная картинки полностью идентичны.
Заключение
Подитожим вкратце основные преимущества/недостатки Lossless сжатия (сжатие видео без потери качества), на примере кодека Huffyuv:
При частой/постоянной работе с видео нередка одна из ситуаций, в которой мы сталкиваемся либо с нехваткой места на диске, либо с тем, что, имея мощный процессор для кодирования, видим, что процесс сжатия упирается в "бутылочное горлышко", а именно в скорость отдачи видеопотока винчестером (в качестве примера, - обычный поток 720х576 4:2:2 - 160 Мбит/с, казалось бы, по формальным характеристикам не превышает скорости передачи данных ATA-дисков, на практике же получается торможение, причем весьма заметное). Понятно, что вторая проблема частично или полностью обходится установкой простейшего RAID, но далеко не все имеют подобную возможность. И обе проблемы можно попытаться обойти при помощи использования "сжатия без потерь" - мы одновременно уменьшаем и место, необходимое для хранения видео, и снижаем поток данных, запрашиваемых с жесткого диска.
Lossless-кодеки (или же lossless-режимы некоторых кодеков) - особая подгруппа энкодеров видеопотока, позволяющая сократить объем занимаемый видео на жестком диске, но при этом сохранить всю видеоинформацию без потерь в определенном (YUV или RGB) цветовом формате. Последняя оговорка весьма важна для понимания того, что большинство lossless-кодеков работают в режимах YUY2 (4:2:2) или YV12 (4:2:0), поэтому, если Вы не хотите потерь цвета, внимательно проверьте цветовой формат видео на входе и установки lossless-кодека при сжатии.
Следует добавить, однако, что если Вы собираетесь хранить свои материалы на DVD или в MPEG4-подобном формате (xVid, DivX, WMV9, VP6/7, h.263, h.264, все форматы для мобильных устройств), то YV12, возможно, более предпочтителен, т.к. при сохранении материала в эти форматы поток все равно будет преобразован в YV12. Поэтому при захвате и обработке видео лучше сразу выбирать YV12. (При отсутствии такого режима захвата в тюнере/карте захвата попробуйте найти подходящие драйверы, - например, для чипов Philips SAA713x YV12 есть в версии драйвера от Beholder или же в референсном драйвере.) При этом будет экономиться дисковое пространство при захвате или при архивном хранении материала (видеопоток в формате YV12 занимает в несжатом состоянии на 25% меньше места по сравнению с несжатым YUY2 - выигрыш даже в этом).
Данный материал рассматривает характеристики ряда lossless-кодеков, доступных в сети, по параметрам, интересным для применения, а именно: степени сжатия и нагрузке на CPU при кодировании/декодировании (буквально: скорости, выраженной в частоте кадров).
Тесты проходили на системе с установленным Intel Pentium IV 3.5 ГГц, запись и чтение производились с разных физических устройств.
Сжатие в YV12
Нижеприведенная таблица демонстрирует результаты, полученные при сжатии минутного фрагмента (источник - эфир, захват на ТВ-тюнере, качество - субъективно хорошее, формат - чересстрочный YV12). Таблица отсортирована так, что сверху располагаются кодеки, давшие лучшее сжатие, снизу - худшее. Изначальный размер видеофрагмента - 933 165 056 байтов.
Что можно сказать, глядя на результат? Ну, выбирать кодек-победитель для сжатия не в тесных временных рамках каждый должен сам - по степени сжатия или по оптимальному соотношению степень сжатия/скорость. А вот про применение кодеков из таблицы для сжатия при захвате следует сказать, что те из них, что показали время больше минуты, непригодны, и FFV1, который на минутное видео потратил 55 секунд тоже под вопросом - проверьте его вначале, вдруг Ваша система не окажется столь быстрой для него. Также отмечу "призом за волю к победе" Arithyuv - работая в формате YUY2 (!), он, конечно, проиграл - но не всухую!
Сжатие в YUY2
Целесообразность использования данного формата может проявлять себя только в том случае, если исходное видео у Вас имеет цветовую размерность не хуже 4:2:2 и оно более или менее приличного качества. Во всех остальных случаях - не ломайте голову и смело используйте YV12.
В таблице чуть ниже приведены результаты, полученные при сжатии другого минутного фрагмента (источник - RAW YUY2). Таблица отсортирована так, что сверху располагаются кодеки, давшие лучшее сжатие, снизу - худшее. Изначальный размер видеофрагмента - 1 244 205 056 байтов.
Выводы, используя уже сказанное нами, Вы легко сделаете сами!
Lossless и двух-ядерные процессоры
В связи с доступностью двухпроцессорных систем возникает вполне понятный вопрос - а нужно ли вообще, в таком случае, сжатие видео "без потерь"? Ведь на двухпроцессорной системе мы достаточно просто "посадим" на один процессор фрейм-сервер, который будет выполнять обработку видео на лету (например, AVISynth), а на втором процессоре у нас будет происходить финальное сжатие (в MPEG-2 для DVD, в MPEG-4 или во что угодно). И нет нужды каждый раз изыскивать свободное место на дисках:
Что тут сказать. Раньше на этот вопрос ответить было достаточно просто: используя сжатие без потерь после обработки видео (очистка, преобразование, подготовка к кодированию) до финального сжатия, мы зачастую экономили время - ведь большинство кодеков и энкодеров, используемых нами для подготовки финального потока, применяют двух- или мульти- проходные методики, т.е. каждый раз, встраивая в цепочку обработки фрейм-сервер, мы сильно увеличивали время финального сжатия. А если финальный вариант должен быть в нескольких форматах, то тут вообще обработка могла вестись сутками. Поэтому запись подготовленного видеопотока в формат без сжатия экономил массу времени.
Сейчас так просто, увы, не ответишь - ведь, если энкодер для финального сжатия использует только одно ядро процессора (яркий пример - Canopus Procoder 1.5), то второе простаивает, и на него вполне можно повесить фрейм-сервер. В общем, каждый выберет сам - приведем лишь доводы в пользу lossless-сжатия: во-первых, проекты, как правило, лежат несколько недель "на всякий случай", во-вторых, параллельно со сжатием можно заняться другой работой (часть второго ядра- то простаивает :) ), в третьих , а зачем еще нужны терабайтные RAID'ы? :)
Надеемся, что помогли Вам в нелегком выборе кодека - безопасного для Вашего видео и Вашего свободного места на винчестерах. И очень рады, если слегка взбаламутили вопросом "а нужно ли это?" - если так, приходите, вспомним старые споры "lossless-сжатие vs frame-server"
Видео высокой четкости радует красивой и детализированной картинкой, однако оно занимает много места на диске. CHIP расскажет, как сократить объем файлов и сэкономить место в домашнем архиве.
Видео высокой четкости радует красивой и детализированной картинкой, однако оно занимает много места на диске. CHIP расскажет, как сократить объем файлов и сэкономить место в домашнем архиве.
CHIP расскажет, как сократить объем файлов и сэкономить место в домашнем архиве Лето подошло к концу, и наступила пора разобраться с отснятыми в отпуске фото- и видеоматериалами. Причем современные фотокамеры уже позволяют снимать видео в формате высокой четкости. Однако отличное качество снимков и видеороликов имеет и обратную сторону: файлы стали более объемными и в большом количестве уже с трудом могут помещаться на жесткий диск ПК. А значит, прежде чем поделиться впечатлениями с друзьями, выложив видеоролики в Сеть, а затем разместить их в домашнем видеоархиве, необходимо позаботиться о том, чтобы полученные файлы все же занимали поменьше места. Но как сделать так, чтобы все эти красивые и яркие пейзажи не были испорчены применяемыми в видеоконвертерах алгоритмами сжатия? Первое, что при ходит в голову, — найти в Интернете надежные методики компрессии без потерь. Однако чаще всего под этим понятием подразумеваются вовсе не lossless-форматы, а способы кодирования с потерями, позволяющие визуально не ухудшать качество изображения.
Стандарт для сжатия видео
Своеобразным «стандартом» в сфере кодирования видео является кодек H.264. Он поддерживается в рамках стандартов Blu-ray и HD DVD. Кроме того, с ним работают Apple QuickTime и Adobe Flash Player. Такая мощная поддержка профессионального сообщества, наряду с ростом вычислительных мощностей ПК, обеспечила ему широчайшие возможности использования в видеотехнике и программных продуктах.
Главным достоинством кодека H.264 является высокая возможная степень сжатия видеопотока без значительных визуальных изменений картинки. Достигается это за счет анализа не только каждого кадра в отдельности, но и их последовательности. В типичном видеоролике, где изображение в кадре быстро меняется лишь изредка, применяются методики предсказания сразу нескольких последующих кадров, что дает существенный выигрыш при кодировании разного рода движения. Кроме того, определенный выигрыш получается от экономии на цветовом пространстве (4:2:0 YUV вместо RGB). Это позволяет кодировать видео «на лету» без особых вычислительных затрат. Именно поэтому кодек H.264 используется в большинстве современных потребительских камер, смартфонах и видеорегистраторах.
Идеальное сжатие и высокое качество
Вкратце опишем процесс настройки бесплатного кодека ffdshow tryouts (есть на CHIP DVD) построенного на базе H.264. Наша цель — продемонстрировать основные возможности, поэтому мы остановимся лишь на нескольких базовых параметрах. Для конвертирования видео мы выбрали бесплатную программу MeGUI и пакет кодеков K-Lite Codec Pack (есть на CHIP DVD). После того как вы установите эти два пакета, откройте MeGUI. На вкладке «Input» в меню «Encoder setting» выберите вариант «x264» и кликните по кнопке справа «Config». Теперь можно заняться настройкой параметров кодека. Они разделены на несколько закладок.
MAIN — здесь можно задать «Preset» кодирования. Для «домашнего» видео имеет смысл выбирать медленные пресеты («Slow», «Slower» и т. п.). Кроме того, в меню «Tuning» можно выбрать характер кодируемого ролика. Это тоже своего рода пресет, «включающий» определенные параметры оптимизации.
FRAME-TYPE — группа параметров, управляющих качеством сжатия. H.264 поддерживает многопроходное кодирование. Опытные пользователи считают, что для перекодирования фильмов оптимально использовать два прохода. Ниже задается требуемая степень сжатия. Все зависит от выбранного режима: можно указать либо битрейт, либо индекс качества.
MISC — здесь в поле «Custom command line» опытные пользователи могут задать дополнительные параметры кодирования. Доступные команды можно найти в спецификации метода.
Хотя H.264 и относится к стандарту «сжатие с потерями», в нем не применяются методики обратимой архивации. В частности, в H.264 позволяется выбрать способ сжатия без потерь по итогам всей обработки: CABAC (Context adaptive binary arythmetic codes) или CAVLC (Сontext adaptive variable length codes). Правда, стоит отметить, что в использованной нами в качестве примера бесплатной библиотеке ffdshow эта настройка из графического интерфейса недоступна.
Сохраняем видео в архив и на YouTube
Отснятые в отпуске видеоролики в высоком разрешении, как правило, занимают много места на диске. Хранить их в таком виде в домашнем видеоархиве не очень экономно. К тому же многие предпочитают делиться впечатлениями с друзьями, выкладывая наиболее интересные ролики на популярный видеохостинг YouTube. Мы предлагаем совместить архивирование контента и подготовку роликов к закачке на видеосервис, воспользовавшись нашими советами по сжатию роликов без ощутимых потерь и адаптируя их для размещения в Сети.
YouTube, как и многие другие онлайн-сервисы, применяет методику сжатия H.264. При этом для эффективной передачи видео по Сети, в том числе на мобильные устройства, ресурс задействует строго определенный набор параметров. При загрузке ролика на сервер осуществляется его перекодирование с учетом этих параметров. Наилучшего качества удастся достичь вовсе не наибольшим потоком или индексом качества, заданными при кодировании, а наиболее удачным подбором параметров под требования видеохостинга. Иными словами, если вы хотите в итоге разместить видео на YouTube, сжатие без потерь для вас будет означать следование следующим рекомендациям.
КОНТЕЙНЕР MPEG-4. Для сохранения видео YouTube рекомендует использовать контейнер MPEG-4, который является в каком-то смысле «родным» для H.264. Для этого воспользуйтесь бесплатной программой Avidemux (есть на CHIP DVD).
«ВЫСОКИЙ» ПРОФИЛЬ (HIGH QUALITY). В базовых параметрах кодека надо указать «Высокий» профиль (High). Для кодирования видео HD качества следует использовать уровень не ниже 4: лишь начиная с него поддерживается разрешение 1920×1080 точек с частотой до 30 кадров/с. Цветовое пространство — 4.2.0. Уровень можно выбирать самому.
В Avidemux в разделе «Video Output» выберите кодек MPEG-4 AVC (x264) и в настройках последнего задайте профиль «High Quality» СРЕДНИЙ БИТРЕЙТ. Для видео высокой четкости (разрешение 1920×1080 точек при 29,97 кадра/с) YouTube рекомендует устанавливать средний битрейт от 5 до 8 Мбит/с. Его можно задать вручную, выбрав на первой вкладке метод кодирования «Average Bitrate». Это уменьшит размер файла с сохранением того же качества.
Чтобы вручную указать битрейт, в настройках кодека x264 на вкладке «General» задайте метод кодирования «Average Bitrate» B-КАДРЫ. При кодировании видео на ресурсе задействованы так называемые B-кадры — кадры, предсказанные с помощью специального алгоритма по двум соседним. Рекомендуем указывать присутствие двух последовательных B-кадров. При этом закрытая группа изображений (GOP) должна составлять не более половины кадровой частоты (15, если речь идет о 29,97 кадра/с).
На вкладке «Frame» установите значение последовательных B-кадров (B-Frame), равное двум СЖАТИЕ CABAC. В качестве дополнительного метода сжатия без потерь используется не самый эффективный, зато применимый на мобильных устройствах CABAC (Context adaptive binary arythmetic codes).
Для улучшения качества кодирования видео на вкладке «Frame» можно задать дополнительный метод сжатия без потерь CABAC ЗВУК В AAC-LC. Для аудио следует задействовать кодек AAC-LC (в Avidemux применяется тип AAC lav) при частоте дискретизации 48 или 96 кГц.
Для домашнего архива звук в видеоролике можно оставить без обработки. Для YouTube необходимо применить кодек AAC-LC
Сжатие без потерь: lossless-форматы
Методика сжатия видео без потерь — это обратимая архивация, аналогичная той, что мы применяем, к примеру, при упаковке в архив текстовых и других документов для пересылки по электронной почте. Она позволяет получить исходные данные в неизменном виде после распаковки. При работе с видео наибольшей степени компрессии можно добиться, применяя специальные алгоритмы. Наиболее известными считаются следующие из них.
MOTION JPEG 2000 — коммерческий кодек для видео (около 1200 руб., демоверсия есть на CHIP DVD), построенный на принципах сжатии без потерь статических изображений JPEG2000.
Коммерческий кодек MJPEG2000 позволяет кодировать видео без потерь в качестве, обеспечивая высокую степень сжатия HUFFYUV — достаточно быстрый и эффективный свободный кодек, основанный на методике побитового предсказания следующего пикселя в потоке и архивации данных (есть на CHIP DVD).
Свободно распространяемый кодек Huffyuv также обеспечивает высокую степень сжатия видео без ощутимых потерь в его качестве LAGARITH — «продолжатель» идеи кодирования Huffyuv (есть на CHIP DVD). Авторам удалось добиться большей степени сжатия, в частности, за счет добавления методов работы с почти статическими изображениями. Обращение с роликами, сжатыми с помощью lossless-алгоритмов, осложнено тем, что они занимают много места на диске и поддерживаются ограниченным числом плееров и бытовых устройств. При этом они действительно нужны, только если камера позволяет скопировать несжатые данные (так называемые RAW, по аналогии с фотографией) либо по каким-то причинам важна высокая точность передачи этого изображения. Из специальных областей это могут быть медицина и картография.
Кодек Lagarith можно бесплатно использовать для «домашнего» кодирования — например, с помощью программы VirtualDubMod
Так ли необходимо сжатие без потерь?
Применительно к цифровому видео понятие «сжатие без потерь» подразумевает, что алгоритм позволяет архивировать каждую картинку в том виде, в каком она была получена с записывающего устройства. При этом стоит отметить, что фото и видео, снятые даже полупрофессиональной видеокамерой, не требуют столь бережного отношения к себе. В кадре почти всегда присутствуют шумы, аберрации и искажения, которые в целом не влияют на наше восприятие картинки — иными словами, картинка, как правило, сама по себе не идеальна. Применяя методики сжатия с потерями, вы, конечно, еще немного «испортите» ее, сэкономив на избыточности как в рамках отдельных кадров, так и внутри их последовательности. Но при этом вы добьетесь значительно большей степени компрессии, то есть в десятки раз меньшего размера файла на жестком диске.
А что будет дальше?
Различные видеосервисы, в частности «видео по запросу», уже задумываются о переходе на следующую версию стандарта — H.265, эффективность сжатия которого гораздо выше. Используемый кодек даст возможность гибко управлять качественными потерями. Кроме того, он позволит работать с непостоянной частотой кадров.
Стабильный релиз 1.10.4 (build 35491) от 27.10.2013 • Тестовый релиз 1.10.5 Test 7 от 13.10.2014 - x86, x64 (исходники).
• VirtualDubMod - подерживает MP3-VBR, несколько аудиодорожек, форматы OGM и MKV (Матрешка) и др.
- полная версия 1.5.10.2 + апдейт до 1.5.10.2 build 2542 (только exe)
- VirtualDubMod 1.5.10.3
- VDubMod-1.5.10.1-noblock.7z - версия, которая позволяет копировать кодируемый файл и просматривать его плеером в тот момент когда он еще не закодился
• VirtualDub2 (бывший FilterMod) - современный форк на основе кода VD 1.10.5 Test 7. Обладает следующими возможностями:
- открывает разные виды файлов (благодаря плагину caching input driver);
- умеет сохранять в форматах MKV, MP4, MOV и др.;
- в комплекте идут кодеки x264, Huffyuv, FFV1, Apple ProRes, AAC и MP3 (теперь их не требуется устанавливать в системе);
- поддерживает работу с цветом высокой битности;
- имеет дополнительные фильтры для обработки видео.
(сайт, тема на doom9)
Другие сборки:
- Русская версия 1.10.6ru от Uncle KILLER 18.05.2018 , в архиве VirtualDub2 19 сборка 41867 (update 6) , х86 и х64 + Mod.
- Русифицированный плагин х264
• от Aktaf Авторская сборка 41462 в каталогах переведенные плагины, ехе автора на английском 32 и 64 битные, мои с цифрой 2 только 32 на английском и русском. Поменяйте на свежие 41493 русская и английская ехе ка
Набор кодеков с ХР и др. на русском - *.dll ки положите рядом с ехе кой Даба (можно положить в каталог system32 Винды) и 3 дополнительной справки на русском. Любые 2 справки, можете "скормить" VD, просто переименуйте файлы на запрашиваемое название.
Можно дополнительно, в любых версиях Выводить данные о видео, какие и как
Для открытия и работы с файлами других форматов
Плагины для различных видеоформатов
Плагин vdubaudio.vdf
ACM-кодеки для звука
VFW-кодеки для видео
Систематизированный список фильтров к VirtualDub от Дмитрия Попова
Подборка плагинов от Shedrin
Описание по работе с VirtualDub
Несколько полезных уроков по работе с VirtualDub
Описание работы с Virtual Dub на русском
Описание Virtual Dub на 3D News
Утилиты, повышающие функциональность VirtualDub
AviSynth - фрейм-сервер, используется для редактирования и обработки видео совместно с другими программами (VirtualDub и др.)
MPEG4 Modifier
Утилита работает с видео потоком MPEG-4 ASP (XviD, DivX) и позволяет изменять пропорции кадра (Aspect Ratio) без перекодировки.
другие утилиты
ЧАсто задаваемые ВОпросы (FAQ):
1. ПАМАГИТЕ! После VirtualDub файл стал весить МНОГО ГИГАБАЙТ. Как же вы меня. RTFM
Выберите в Video->Compression кодек и укажите битрейт.
Если вы не использовали фильтры для обработки изображения, можете посмотреть след. вопрос.
(Звук тоже можно сжимать. PCM означает несжатый звук).
2. VirtualDub / VirtualDub2 / VirtualDubMod — что выбрать?
Зависит от задачи.
3. Как сохранить видео без пережатия?
Выберите в меню Video->Direct stream copy и сохраняйте как обычно.
(аналогичная опция есть и для звука)
Сохранить кусок видео без пережатия в VirtualDub можно только с ключевого кадра.
Если Вам нужно начать фрагмент с другого кадра, то
в меню выбираем 1)Video - fast recompres (Видео - быстрая перекомпрессия)
2) Video - Smart rendering (Видео - умный рендеринг)
3) Video - compression (Видео - компрессия), кодек, каким сжато исходное видео.
Настраиваем кодек с необходимыми параметрами для пережатия начала фрагмента.
Сохраняем АВИ, у нас пережмется от начала фрагмента до ключевого кадра.
Начиная с ключевого будет без пережатия
Удалить кусок видео без пережатия в VirtualDubMod проще.
Выбираем ненужный фрагмент метками (снизу черные галочки), нажимаем Del. Выбранный фрагмент удалён.
Сохраняем выходной AVI (F7 или в меню Сохранить как. )
Весьма полезно для удаления встроенного в экранки рекламного ролика.
[!] Error loading plugin "FFMpeg Lame MP3" from module avlib-1.vdplugin:
Plugin requires a newer plugin API version (v12 > v10).
Добавлено:
Лично я бы не беспокоился о том, что планины написанные для FilterMod на новом API не работают в оригинальном VD. Это как бы естественно.
Но avlib-1.vdplugin включены VirtualDub_pack_38919.zip, а cch_input.vdf - нет.
С последним обновлением FilterMod решил немного навести порядок у себя в коллекции сборок VirtualDub, из которых FilterMod теперь (ну, где-то с августа 2016) является основной.
Мне лучше чтобы VirtualDub у меня мог открывать так много видеоформатов, как это только возможно.
Однако обращаю, что в последних сборках FilterMod отсутствуют cch_input.vdf. Читаю:
Здесь вы пишите :
Предполагаю, что раз вы убрали cch_input.vdf из сборки, то именно он является тем "старым" и больше не нужен, а avlib-1.vdplugin нужен, раз вы его оставили.
Итак, речь я веду о последней сборке VirtualDub FilterMod (version 15, VirtualDub_pack_38919.zip) и ни о каких других, и о ее плагинах и ни о каких других:
- если cch_input.vdf отсутствует в VirtualDub_pack_38919.zip, то это не ошибка, так и должно быть.
- если avlib-1.vdplugin присутствует в VirtualDub_pack_38919.zip, и раз это "одно и тоже", то это так и должно быть?
- и относительно VirtualDub pack 38919 описание "открывает разные виды файлов (благодаря плагину caching input driver)" остается актуальным, то есть внесенные изменения никак не уменьшили число открываемых форматов?
Краткий ответ "да" на все эти вопросы применительно к VirtualDub pack 38919 меня бы очень обрадовал
да, avlib-1.vdplugin это новый, в нем все есть
Я ведь еще решил поместить VirtualDub FilterMod с этой сборки у себя на флешке в синхронизируемую группу обязательных носимых программ (до этого программа присутствовала на десктопах, но обновлялась вручную, что, понятно, не так удобно), в свете чего не хочется иметь и гонять туда-сюда ненужные файлы, и не в плане занимаемого места, так как сейчас это не особо актуально, а в первую очередь ввиду желания не мешать правильной работе программного обеспечения.
Читайте также: