Многие пользователи интернета часто сталкиваются с одной довольно распространенной проблемой. Как правильно выложить видео ролик в интернет на обозрение другим. Причем сделать это так чтобы качество было по возможности хорошее, а размер ролика по возможности как можно меньше.
Обычный подход, используемый всеми состоит в том чтобы подготавливать и выкладывать в интернет сразу 2 версии видеоролика ужатого DIVX. Одну сильно низкого качества с очень низким битрейдом и соответственно наименьшим размером. А другую более качественную и гораздо большего размера. Как видно у такого классического подхода есть существенный недостаток. Человек, скачав низкопробную версию видеоролика, может не захотеть скачивать хорошую.
Другой способ появившийся совсем недавно - это использование нового поколения кодеков MPEG4, новой спецификации отличной от классического DIVX, XVID и прочего на них похожего. К примеру, использование любого кодека класса H.264. К примеру, X.264 взамен DIVX. В данном случае проблема размер/качество разрешима. Это наиболее правильный вариант с технической точки зрения. Не надо делать 2 разных версии одного и того же клипа, вполне возможно обойтись одним достаточно качественным. Однако для большинства пользователей данный кодек пока не известен. Многие не знают, что видео сделанное данным поколением кодеков проигрывается не только самим кодеком, но и обычным ffdshow который есть у большинства пользователей.
Для этого достаточно просто дернуть галку в настройках ffdshow.
Увы. Большинство не знают данных нюансов и не смогут посмотреть ваш видеоролик, если его кодировать по новым стандартам MPEG4. Так что пока (на момент написания данной статьи) данный вариант кодирования не стоит использовать. Если вам надо чтобы видео проигралось у всех.
Следующий вариант сжатия видео что мы рассмотрим, был придуман и апробирован автором данной статьи. Никаких дополнительных технических изысков для сжатия видео и новых кодеков не используется. Ничего сверх секретного также не присутствует. Все самое стандартное. Только программа VirtualDub и тот же кодек DivX. А в качестве рабочего материала для теста использовался фансаберский (бесплатный) рип аниме. А именно кусок видео с нарезками из аниме длинной 18 сек, в разрешении 320 на 240 и с частотой кадров заниженной до 18 fps. Хоть это и не 24 fps и более, но все же хорошо. Как ни как наша цель ужать ролик не в максимальном качестве как на DVD или HDTV, а для загрузки в интернет на свой личный небольшой сайт. Битрейд при кодировании подбирался в расчете на то чтобы видео ролик 5 мин поместился в файл размером до 4 мегабайт без звука и был лишний 1 мегабайт для размещения звуковой дороги чтобы все видео в финале занимало не более 5 мегабайт в сумме. Т.е. по 1 минуте на 1 мегабайт. Такой размер подходит для многих у кого сайты на бесплатном хостинге. К примеру как наш. Такой размер довольно быстро качается по модему. Ну и главное - это тот размер при котором уже можно удержать приемлемое качество для видеороликов с разрешением 320 на 240.
Определившись с размером файла, необходимо высчитать битрейд которым мы собираемся кодировать видео. Несложные расчеты показывают, что вполне достаточно битрейда 90 kbps чтобы уложится в запланированные размеры с запасом прочности. Но для начала, перед изложением моего метода, рассмотрим что же у нас получится если просто кодировать видео используя DIVX и X264.
DIVX6.2.5 (90kbps/18 fps) размер файла 221465 байт |
X264 (90kbps/18 fps) размер файла 219070 байт |
 |
 |
 |
 |
Как мы видим DIVX проиграл и по всем позициям. Это при том что кодирование было даже не 2х проходное , а 11 проходное. На данном месте так и хочется закончить статью и сказать всем пользуйтесь кодеком x264 или еще какими из серии h264. Или на крайний случай использовать RealVideo или VP70. И то лучше будет результат. Однако как мы рассматривали выше, не у всех пока есть данный кодек (также как RealVideo и VP70) и нам придется выкручиваться самим используя устаревший стандарт кодирования в лице DIVX, XVID и им подобных.
Переходим к реализации моего метода кодирования используя DIVX.
Берем все туже нарезку с фансаба из аниме. Все той же длиной 18 сек, Все того же разрешения 320 на 240 , но уже c частотой кадров 24 fps , а не заниженной до 18 fps как ранее. Готовый кусок видео кодируем с битрейдом 112 kbps. Получаем видео размером 271734 байт. Что гораздо больше предыдущего варианта. Спрашивается зачем мы так сделали. Раз результат вышел явно для нас не приемлемый и видео ни как не влезет в планируемые 4 мегабайта. Объяснение простое. Данной манипуляцией мы получили видео более высокого качества нежели при кодировании с битрейдом 90 kbps. А большой полученный размер можно уменьшить используя уловку которую придумал автор данной статьи.
!!! ИТАК - УМЕНЬШАЕМ РАЗМЕР ГОТОВОГО ФАЙЛА !!!
Берем VirtualDub, загружаем готовый файл который получился после кодирования с битрейдом 112 kbps. Врубаем прямопотоковое копирование для видео. И заходим в вкладку Частота кадров.
Меняем частоту кадров до нужных на 18 fps.
И сохраняем наш кодированный файл под другим именем. Что происходит при этом. В виду того что мы выбрали Прямопотоковое копирование VirtualDub не пережимает и не изменяет кодированное ранее видео. Он только грубо выкидывает лишнее из видеоряда. Что приводит к уменьшению размера получаемого файла. Итак что мы имеем. Исходный материал с 24 fps занимал 271734 байт, а после прямопотокового копирования полученный результат с 18 fps начал занимать 221114 байт. Т.е. мы вернулись в те рамки по размеру что нам надо и к тем 18fps что планировали.
Теперь сравним качество полученного материала.
DIVX6.2.5 (90kbps/18 fps) размер файла 221465 байт |
DIVX6.2.5 (112kbps/18fps) размер 221114 байт (после VD) |
|
 |
|
 |
Как мы видим наши манипуляции привели к заметному увеличению качества картинки при приемлемом размере получаемого файла. Конечно это далеко не то что позволяет сделать кодек x264. Но не в этом дело. Мы не стремились выиграть у нового поколения кодеков. Нам надо было просто найти наиболее приемлемый вариант подготовки видео роликов. Используя DIVX. И мы его нашли. Кроме того данный способ дает уже качество лучше чем использование RealVideo. Примерно как при использовании VP70.
Вообще, если отвлечься на секунду на кодек VP70, то можно сказать что это по качеству промежуточный вариант между MPEG4 старого образца и нового. Но увы VP70 чуток не подходит под стандарт MPEG4 и также данный кодек дает довольно неординарные результаты при кодировании видео. На live-action фильмах и сценах видео иногда опережает даже H.264 по качеству. Но на нашем примере он не сильно отличается от DIVX. В общем довольно неординарный кодек. И если вы желаете его мучить и использовать, то я как автор данной статьи вам не советчик. Как говорится, пробуйте сами, сравнивайте VP70 с H.264. И решайте где и когда что лучше применить. Так как споры что лучше VP70 или H.264 в интернете не утихают до сих пор :-) Что касается меня, то я остановился именно на H.264. Как ни как это новый стандарт MPEG4.
ФИНАЛ.
У вас наверняка возникнет желание проделать тоже самое с кодеком x264, чтобы получить более качественный результат. Это возможно если не сильно отходить от стандартных настроек в x264. Если же сильно замудрить с настройками x264, то мой метод применить корректно не выйдет (про настройки x264 речь пойдет отдельно в конце статьи). Если же применить мой способ к кодеку x264, мы почти приблизимся к оригиналу. Артефакты кодирования будут видны очень слабо. Хотя сильно хорошего улучшения картинки как при кодировании DivX мы не увидим. Линии разве что кое где станут чуть четче и муара меньше. Связано это с тем что уже битрейда 90 kbps уже достаточно чтобы нормально закодировать видео в нашем случае. Вполне вероятно если вы захотите еще больше унизить битрейд к примеру до 50-75 kbps, то тогда пользы от моего способа будет больше.
Ну вот почти и все. Нам осталось приклеить к готовому видео звуковую дорогу размером до 1 мегабайта и клип готов. Звук может быть в формате OGG Vorbis, MP3 или еще каком на свой вкус и цвет.
Но если быть более точными. То звуковая дорожка должна быть без изменений после применения моего метода. Т.е. до применения моего метода она должна (по возможности) прикрепляется к видео прямопотоковым копированием. При применении моего метода прямопотоковое копирование звука должно ОБЯЗАТЕЛЬНО сохранятся. Это позволяет более или менее побороть десинхронизацию звука и видео на быстрых сценах. А если все же включить перекодирование звуковой дорожки при применении моего метода то будет наблюдается довольно сильная рассинхротнизация звука с видео. Что есть нехорошо :-)
Теперь поговорим о настройках x264 для (многопроходного кодирования) которые автор статьи использовал в данных примерах. Вначале настройки для простого кодирования при 90 kbps и направленные на достижение максимального качества. При которых мой метод корректно применить не удается.
 |
 |
 |
Теперь настройки кодека для 112 kbps, при которых мой метод применить удается.
 |
|
|
Как видим различие только в вкладке Rate Control и в используемом битрейде. Стоит еще оговорится что данные настройки не универсальны. С ними при желании можно экспериментировать и экспериментировать. К примеру поменять настройки в группе Quantization Limits. Кроме того многое зависит от типа видеоматериала с которым приходится иметь дело.
Вот и все что я хотел донести до вас.
Конец
P.s. Единственный минус моего метода это получаемая инертность при проигрывании видео. Такое ощущение что у нас не 18 fps , а только 15. А при попытке выкинуть еще кадры снизив частоту кадров до 15 мы получим при проигрывании совсем невменяемый результат. Так как в отличии от обычного режима пропуска похожих кадров (что есть во многих кодеках). Мой метод выкидывает из видео все подряд особо не сортируя по полкам и в последствии это часто видно на проигрываемом видео.
В статье использованы материалы сторонних производителей. По всем вопросам, претензиям и пожеланиям (если таковые возникнут) писать автору данной статьи.
Отправить E-mail в Nimic Anime
