Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 71
Двухпроходное кодирование сильно улучшит результат если есть время на кодирование.
Да, конечно. А три прохода в некоторых случаях дадут ещё больше профита :-)
Просто я хотел затронуть эту тему, в следующей части, т.к. и сами настройки кодека надо менять и этот пост получился бы не очень длинным.
Просто я хотел затронуть эту тему, в следующей части, т.к. и сами настройки кодека надо менять и этот пост получился бы не очень длинным.
Опечатался. Имел ввиду, что пост получился бы очень длинным.
Очень интересно будет прочитать о настройках в следующей части. Насколько я знаю, для разного рода видео нужно использовать свои настройки. Например, для мультфильмов настройки кодера, по идее, должны отличаться от настроек кодера для обычных фильмов.
Для x264 третий проход лишний, особенно после появления mbtree. Я ещё не натыкался на случаи, когда он давал заметный выигрыш.
Двухпроходный алгоритм нужен в первую очередь тогда, когда нужно иметь файл определённого размера. Если же вас интересует именно постоянное качество, не зависящее от того что на ролике (глупо тратить на ролик состоящий из статичной сцены столько же битрейта, сколько и на сверх-динамичный, где практически в каждом пятом кадре фактически новое изображение).
так же оно нужно если хочется в определённый битрейт для веб передачи фильмов например обеспечить как можно лучшее качество
Битрейт и конечный размер файла взаимосвязаны.
Задачи разные.
Одна задача это если надо допустим уместить фильм на CD, т.е. фильм любой длины в 700МБ.
А другая это когда допустим любой фильм кодировать так чтоб пролез через мегабитный канал.
Одна задача это если надо допустим уместить фильм на CD, т.е. фильм любой длины в 700МБ.
А другая это когда допустим любой фильм кодировать так чтоб пролез через мегабитный канал.
Как раз таки задача одинаковая, просто с немного различными данными. Например, в случае если вам нужно уместить 1.5 часовой фильм на 700 Мб, получаем:
700*8/(1.5*3600) = 1.037 Мбит/с
Получили вашу задачу с необходимостью обеспечить нужный битрейт.
700*8/(1.5*3600) = 1.037 Мбит/с
Получили вашу задачу с необходимостью обеспечить нужный битрейт.
Неверно, при фиксированном размере файла, фактический битрейт может прыгать, от 600 до 1500, допустим (получая средний 1.037, но не пролезая в канал 1.2Мбита).
Ну хорошо, задача немного отличается в деталях. Но суть всё равно остаётся — если вам нужно контролировать итоговый битрейт/размер, то тогда нужно два прохода, если же вас интересует только итоговое постоянное качество — то однопроходный (--crf).
Если ставить задачу гарантированного прохождения потока через ограниченный канал, то тут надо задавать --vbr-max равным ширине канала, правда это достигается за счёт ухудшения качества итогового видео, по сравнению с чистым двухпроходным алгоритмом, т. к. вы ограничиваете диапазон переменного битрейта (статичный сцены получат больший битрейт (что не особо то и нужно), а динамические меньший).
Ширина диапазона в котором будет прыгать битрейт будет зависеть от разности ширины канала и целевого битрейта, и в худшем случае, когда они равны, вы получите постоянный битрейт (правда тут не учитывается наличие буфера на стороне клиента).
Если ставить задачу гарантированного прохождения потока через ограниченный канал, то тут надо задавать --vbr-max равным ширине канала, правда это достигается за счёт ухудшения качества итогового видео, по сравнению с чистым двухпроходным алгоритмом, т. к. вы ограничиваете диапазон переменного битрейта (статичный сцены получат больший битрейт (что не особо то и нужно), а динамические меньший).
Ширина диапазона в котором будет прыгать битрейт будет зависеть от разности ширины канала и целевого битрейта, и в худшем случае, когда они равны, вы получите постоянный битрейт (правда тут не учитывается наличие буфера на стороне клиента).
Статья ни о чём.
AVISource? Зачем? Кому надо пережимать AVI файл?
DirectShowSource или FFMpegSource — да.
Настройки x264 не объяснены. Кому интересна вся эта ваша куча. Тем более она не подходит для всех случаев.
Полезная статья вот:
zoltan0.livejournal.com/11021.html
zoltan0.livejournal.com/11422.html
zoltan0.livejournal.com/11545.html
zoltan0.livejournal.com/11946.html
zoltan0.livejournal.com/12286.html
AVISource? Зачем? Кому надо пережимать AVI файл?
DirectShowSource или FFMpegSource — да.
Настройки x264 не объяснены. Кому интересна вся эта ваша куча. Тем более она не подходит для всех случаев.
Полезная статья вот:
zoltan0.livejournal.com/11021.html
zoltan0.livejournal.com/11422.html
zoltan0.livejournal.com/11545.html
zoltan0.livejournal.com/11946.html
zoltan0.livejournal.com/12286.html
Я брал во внимание когда есть не сжатое видео при весьма не скромных размерах. Зашел, посмотрел примерные настройки как должно быть, сделал так же у себя, получил профит.
Углубляться в дебри, и рассказывать для чего нужна каждая галочка, в данном топике не хотел. Но отлично понимая, какой контингент читает Хабр, предчувствовал, что без тех. части не обойтись, поэтому сделал не большую ссылку на YV12. В следующий раз, я ещё больше сделаю акцента на тех. части.
Углубляться в дебри, и рассказывать для чего нужна каждая галочка, в данном топике не хотел. Но отлично понимая, какой контингент читает Хабр, предчувствовал, что без тех. части не обойтись, поэтому сделал не большую ссылку на YV12. В следующий раз, я ещё больше сделаю акцента на тех. части.
Согласен. Даже на рутрекере лучше написано, чем в этом топике.
Если будете описывать настройки кодеков в следующих статьях, то если можно — использовать примеры, для чего оно и как, т.к. понравилось про YUV — кратко и интересно.
А как сейчас обстоят дела с поддержкой x264 в различных домашних медиа-девайсах: DVD-проигрывателях, телевизорах, и др. различных устройствах?
Сейчас h264 уже наверное поддерживается большим количеством устройств, чем xvid/divx. По крайней мере современные устройства затачивают на воспроизведение именно этого формата. Другое дело не все параметры поддерживаются разными устройствами. Например некоторые поддерживают только baseline-профиль, другие имеют ограничение на кол-во референсных кадров (-ref), например Asus O Play! — не более 9 ReFrame.
х264 это кодек. А стандарт H264 или MPEG-4 Part 10 или AVC.
Во всех новых девайсах этот стандарт поддерживается по умолчанию.
Просто в зависимости от мощности устройства он тянет разные уровни стандарта. Baseline или High например.
Во всех новых девайсах этот стандарт поддерживается по умолчанию.
Просто в зависимости от мощности устройства он тянет разные уровни стандарта. Baseline или High например.
Если вы пережимали видео геймплея Battlefield2, откуда у вас взялось видео в YUV?
Мои много «НО»:
1) Для чего автор рекомендует VLC media player и K-Lite Codec Pack? Какое они имеют отношение к сжатию, если автор использует MeGUI?
2) Последние версии x264 содержит в себе библиотеку libavcodec и вполне себе может открывать любые файлы без AviSynth, не знаю как MeGUI, но консольная утилита это может точно.
3) Непонятно вообще, что за настройки рекомендует автор??? Вообще разработчики x264 не дураки и специально придумали:
а) профили кодирования для регулирования скорости сжатия (--preset от ultrafast до placebo)
б) параметр учитывающий тип сжимаемого материала (--tune)
в) параметр для ограничения формата для воспроизведения на различных устройствах (--profile).
г) параметры для регулирования степени сжатия (--crf и др.)
Остальные настройки крутить без знания для чего они конкретно нужны — не стоит.
4) > Для 1080p нужно немного под редактировать конфиг
> Меняем значение Number of Reference Frames с 9 на 4
Автор даёт советы, при этом не понимает для чего. Это стоит ограничивать только, если планируется воспроизведение на каком-нибудь железном плеере, или мобильном телефоне. Дело в том что контроллер устройства может не поддерживать количество референсных кадров >9 при разрешении FullHD. Или например аппаратное ускорение DXVA не может работать при --ref>11
1) Для чего автор рекомендует VLC media player и K-Lite Codec Pack? Какое они имеют отношение к сжатию, если автор использует MeGUI?
2) Последние версии x264 содержит в себе библиотеку libavcodec и вполне себе может открывать любые файлы без AviSynth, не знаю как MeGUI, но консольная утилита это может точно.
3) Непонятно вообще, что за настройки рекомендует автор??? Вообще разработчики x264 не дураки и специально придумали:
а) профили кодирования для регулирования скорости сжатия (--preset от ultrafast до placebo)
б) параметр учитывающий тип сжимаемого материала (--tune)
в) параметр для ограничения формата для воспроизведения на различных устройствах (--profile).
г) параметры для регулирования степени сжатия (--crf и др.)
Остальные настройки крутить без знания для чего они конкретно нужны — не стоит.
4) > Для 1080p нужно немного под редактировать конфиг
> Меняем значение Number of Reference Frames с 9 на 4
Автор даёт советы, при этом не понимает для чего. Это стоит ограничивать только, если планируется воспроизведение на каком-нибудь железном плеере, или мобильном телефоне. Дело в том что контроллер устройства может не поддерживать количество референсных кадров >9 при разрешении FullHD. Или например аппаратное ускорение DXVA не может работать при --ref>11
а где покурить смысл этих волшебноудобных параметров (3), их назначение и границы применимости?
Наиболее полное описание параметров видел тут, ну и конечно в --help консольного енкодера, т. к. параметры время от времени бывают меняются.
Та статья, в которой комменты интересней самой статьи.
Большое комьюнити AMV-шников пользуется для кодирования AMVSimple GUI:
amvnews.ru/index.php?go=Pages&in=view&id=34
Что приятно берет на вход помимо Uncompressed в том числе и AVISynth скрипты.
amvnews.ru/index.php?go=Pages&in=view&id=34
Что приятно берет на вход помимо Uncompressed в том числе и AVISynth скрипты.
Зачем столько телодвижений, если пережимание в h264 можно сделать одной строчкой? Например, для декодирования BD:
ffmpeg -i 00010.m2ts -acodec ac3 -ab 128k -ac 6 -map 0.0:0.0 -map 0.4:0.1 -sn -s hd1080 -b 5000k -maxrate 10000k -bufsize 256000k -threads 16 One.mkv
Командная строка вообще почти идеальный способ взаимодействия с компьютером. Смысл слова «почти» в том, что у этого интерфейса есть только один недостаток — нужно запоминать команды.
Меня вот интересуют оптимальные настройки по битрейту для BD FullHD пережимаемого в mkv. Хотелось бы сохранить максимальное качество при небольшом объеме (10-15 Гб) за счет времени обработки (несколько проходов, ReFrames и прочее). Какое кстати преимущество ac3 перед aac?
Для выбора оптимальных настроек я кодировал кусок фильма с разными параметрами и сравнивал.
Звуковым кодеком выбрал ac3, как более распространенный. В принципе, можно и с aac попробовать.
Звуковым кодеком выбрал ac3, как более распространенный. В принципе, можно и с aac попробовать.
Каких только настроек не встречал. Хотелось бы выделить какой-то базовый набор параметров (вот эти параметры ставим всегда и не меняем), и небольшую табличку (2-3 фиксированных значения) для изменяемых параметров, например для анимации ставим такое значение, для фильмов другое. Мне казалось aac по качеству лучше, а ac3 просто исторически больше распространен, совместимость с железом и лицензионные ограничения мало волнуют.
Прогрессивные люди уже используют WebM (в частности, кодеки VP8 и Vorbis) вместо x264. По слухам, сейчас эффективность кодирования по стандарту WebM с последними версиями кодеков превысило возможности x264.
Серьёзно? Честно говоря, мечтаю именно об этом. Где почитать сравнения?
Это только слухи. Достаточно посмотреть результаты тестов.
Всё слухи.
Разработчики, конечно, бьются за улучшения. Но на деле серьёзная работа приносит плоды считанных процентов. А преподносится каждый раз как прорыв, оттуда и слухи.
Сравнение VP8 и x264, наиболее актуальное, можно посмотреть тут.
compression.ru/video/codec_comparison/index.html
Судя по графикам, качество вполне сравнимое, но везде есть пометка, что VP8 не соответствует требованиям по времени. В действительности, сравнение кодеков проводится не по двум параметрам «размер/качество», а по трём — «размер/качество/скорость».
По сравнению видно, что VP8 достаёт по качеству x264, но при этом в разы уступает по скорости. Если же попробовать уравнять их по скорости, то у VP8 просядет качество либо увеличится размер.
И скорость является достаточно важным фактором, поскольку она напрямую связана с требуемыми мощностями и энергопотреблением. Этот вопрос является актуальным, поскольку бОльшая часть видео кодируется либо на девайсах, работающих от аккумулятора на этапе записи (телефоны, видеокамеры), либо на серверах сервисов вроде YouTube.
И поскольку формат VP8 более ограниченный, с большой вероятностью VP8 будет уступать лучшим кодекам стандарта H.264. Хотя гугл заинтересован в том, чтобы это отставание было минимальным.
Разработчики, конечно, бьются за улучшения. Но на деле серьёзная работа приносит плоды считанных процентов. А преподносится каждый раз как прорыв, оттуда и слухи.
Сравнение VP8 и x264, наиболее актуальное, можно посмотреть тут.
compression.ru/video/codec_comparison/index.html
Судя по графикам, качество вполне сравнимое, но везде есть пометка, что VP8 не соответствует требованиям по времени. В действительности, сравнение кодеков проводится не по двум параметрам «размер/качество», а по трём — «размер/качество/скорость».
По сравнению видно, что VP8 достаёт по качеству x264, но при этом в разы уступает по скорости. Если же попробовать уравнять их по скорости, то у VP8 просядет качество либо увеличится размер.
И скорость является достаточно важным фактором, поскольку она напрямую связана с требуемыми мощностями и энергопотреблением. Этот вопрос является актуальным, поскольку бОльшая часть видео кодируется либо на девайсах, работающих от аккумулятора на этапе записи (телефоны, видеокамеры), либо на серверах сервисов вроде YouTube.
И поскольку формат VP8 более ограниченный, с большой вероятностью VP8 будет уступать лучшим кодекам стандарта H.264. Хотя гугл заинтересован в том, чтобы это отставание было минимальным.
Не могу найти сравнение кодеков VP8 и x264 за 2012 год. Это вообще сравнивалось в этом году? За последний год кодек VP8 очень сильно оптимизировали.
За 2012 год ещё нет сравнения.
В 2011 его тоже «очень сильно оптимизировали», но это не значит, что он от этого должен обязательно обогнать x264. И тот тоже не стоит на месте.
В 2011 его тоже «очень сильно оптимизировали», но это не значит, что он от этого должен обязательно обогнать x264. И тот тоже не стоит на месте.
Вот тут новость от 11 мая: www.opennet.ru/opennews/art.shtml?num=33825
В обсуждении люди всерьёз говорят о переходе с x264 на WebM: «Еще годик и начнем, щас в группе рипперов тестим WebM 1080/720p и H.264 аналогичного качества, много споров и сомнений, хотя как по мне — разница в качестве минимальна (3-5%), либо вообще незаметна. Так что год максимум я бы еще потерпел, пара обновлений выйдет и можно переходить полностью на этот замечательный кодек.»
В обсуждении люди всерьёз говорят о переходе с x264 на WebM: «Еще годик и начнем, щас в группе рипперов тестим WebM 1080/720p и H.264 аналогичного качества, много споров и сомнений, хотя как по мне — разница в качестве минимальна (3-5%), либо вообще незаметна. Так что год максимум я бы еще потерпел, пара обновлений выйдет и можно переходить полностью на этот замечательный кодек.»
Новость я видел, но там все улучшения по частным случаям и довольно специфичные. Они не дают радикального прироста.
Про близость по качеству я уже говорил, но по скорости он, по крайней мере, прошлый год проигрывал значительно.
Рипперы тоже разные бывают. То, что на т.ру кто-то выкладывал рипы с помощью Theora, ещё не значит, что так делать правильно.
Про близость по качеству я уже говорил, но по скорости он, по крайней мере, прошлый год проигрывал значительно.
Рипперы тоже разные бывают. То, что на т.ру кто-то выкладывал рипы с помощью Theora, ещё не значит, что так делать правильно.
Послушайте, вы дали ссылку, где есть сравнение кодеков VP8 и x264 только по 2010 году, то есть тестировался кодек VP8 до версии 0.9.6. С тех пор кодек VP8 претерпел существенные изменения и увеличение быстродействия в несколько раз по сравнению с первыми публичными версиями — достаточно проследить историю новостей о выпусках VP8 на OpenNet.ru и цифры увеличения быстродействия для каждого случая применения кодека.
«Частные случаи» совсем не специфические, а касаются вполне востребованных возможностей:
1) кодирование в режиме реального времени;
2) кодирование с высоким качеством.
В обоих случаях VP8 последних версии (1.0.0-1.1.0) показывает сопоставимые результаты с x264. Цитата: «Webm нынче жмет на уровне baseline профайла h.264. Совершенно без скидок.» — www.opennet.ru/opennews/art.shtml?num=32924#6 от января 2012 года.
Сейчас идёт «полировка» кода. Каждый квартал выпускается исправленная и улучшенная версия, отсюда быстродействие растёт незначительно, так как код и формат структур данных кодека уже стабилизированы и меняются незначительно.
«Частные случаи» совсем не специфические, а касаются вполне востребованных возможностей:
1) кодирование в режиме реального времени;
2) кодирование с высоким качеством.
В обоих случаях VP8 последних версии (1.0.0-1.1.0) показывает сопоставимые результаты с x264. Цитата: «Webm нынче жмет на уровне baseline профайла h.264. Совершенно без скидок.» — www.opennet.ru/opennews/art.shtml?num=32924#6 от января 2012 года.
Сейчас идёт «полировка» кода. Каждый квартал выпускается исправленная и улучшенная версия, отсюда быстродействие растёт незначительно, так как код и формат структур данных кодека уже стабилизированы и меняются незначительно.
У вас более свежие цифры есть?
Формулировка «Webm нынче жмет на уровне baseline профайла h.264. Совершенно без скидок.» подразумевает сравнение форматов, на самом деле. И если у WebM одна реализация, то у H.264 их десятки, если не сотни. И baseline profile, как следует из названия, это базовые возможности для совместимости с самыми слабыми железками.
Формулировка «Webm нынче жмет на уровне baseline профайла h.264. Совершенно без скидок.» подразумевает сравнение форматов, на самом деле. И если у WebM одна реализация, то у H.264 их десятки, если не сотни. И baseline profile, как следует из названия, это базовые возможности для совместимости с самыми слабыми железками.
На уровне baseline — это разве достижение?
Вообще все эти разговоры вокруг VP8 ерунда несусветная, потому что аппаратной поддержки его практически нигде нет, в отличие от h264, который и сжимает лучше.
А конечного пользователя юридические заморочки вообще не должны волновать.
Следующий рывок качества будет в стандарте h265, до которого VP8 конечно же как до луны.
Вообще все эти разговоры вокруг VP8 ерунда несусветная, потому что аппаратной поддержки его практически нигде нет, в отличие от h264, который и сжимает лучше.
А конечного пользователя юридические заморочки вообще не должны волновать.
Следующий рывок качества будет в стандарте h265, до которого VP8 конечно же как до луны.
Отлично. А сколько телевизоров, плееров и мобильных телефонов поддерживают WebM?
Хочу, чтобы затронули тему CUDA при транскоде.
Я одно время очень быстро и приятно пережимал фрапсы при помощи badaboom (от nvidia) — там мало профилей и настроек, но скорость сжатия исходного материала в х264 радует.
Но мне кажется, уже и более профессиональные транскодеры используют CUDA и хочу встретить на хабре статью о таких транскодерах и примерах настроек.
Я одно время очень быстро и приятно пережимал фрапсы при помощи badaboom (от nvidia) — там мало профилей и настроек, но скорость сжатия исходного материала в х264 радует.
Но мне кажется, уже и более профессиональные транскодеры используют CUDA и хочу встретить на хабре статью о таких транскодерах и примерах настроек.
Xilisoft Video Converter довольно мощный, использует CUDA и даёт возможность вручную выбрать разрешение и битрейт, в отличие от Badaboom.
CUDA по качеству пока даёт гавно, достаточное только для еденичного просмотра на телефоне/планшете, а не для длительного хранения (качество на уровне x264 --superfast), это видно на тестах compression.ru
Intel Quicksync впрочем тоже, но чуть получше (на уровне --veryfast)
Может когда-нибудь качество вырастет (особенно когда x264 портируют на OpenCL), но не сейчас.
Кстати есть li5.ziti.uni-heidelberg.de/x264gpu/, но там код от 2008 года, с тех пор x264 далеко ушёл вперёд. Жаль что разработчики x264 никак не родят OpenCL версию сами.
Intel Quicksync впрочем тоже, но чуть получше (на уровне --veryfast)
Может когда-нибудь качество вырастет (особенно когда x264 портируют на OpenCL), но не сейчас.
Кстати есть li5.ziti.uni-heidelberg.de/x264gpu/, но там код от 2008 года, с тех пор x264 далеко ушёл вперёд. Жаль что разработчики x264 никак не родят OpenCL версию сами.
бесплатный комбайн-транскодер MediaCoder тоже вроде бы поддерживает CUDA
есть 2 часа видео(кусками) с камеры в 1080п весом гигов 20 в формате .mts как и чем жать чтобы получить нормальный контейнер и приемлемый вес с видео в хорошем качестве, и для второй версии насколько сжать которую заливать на ютуб(всего 20 минут)
Мне было бы очень интересно прочитать про скринкасты. В каком разрешении снимать, чем жать, чтобы людям было не больно смотреть на элементы интерфейса. Сейчас я рисую на рабочем столе прямоугольник размером 1280×720, выставляю размер окон программ (которые участвуют в скринкасте) такого размера, в Камтасе захватываю только эту область. Видимо, делаю не верно, а как правильно – хотел бы узнать из статьи.
В свое время закачивал аниме в контакт. Основным требованием к конвертеру было умение встраивать ssa/ass-сабы, поэтому выбор пал на xvid4psp. Он тоже использует avisynth и у него есть специальные синхронизаторы, чтобы видео/аудио/сабы не расползались. Как с этим у MeGUI?
Фраза «не одну кошку съели» ввела меня в ступор.
А как лучше пережать видео, чтобы его ютуб не похерил?
Пример — заливаю свою видяшку на ютуб, как есть, пол гига за 10 минутный ролик, лить долго, ютуб сам жмет, но зато потом, на тюбике картинка красивая выходит.
Пробовал сам ужимать в H264 и получалась лажа. Локально ролик выглядит неплохо, но стоило его залить на ютуб, как тот видимо его еще раз плющил и получалось адское мыло в котором нифига не видно.
Пример — заливаю свою видяшку на ютуб, как есть, пол гига за 10 минутный ролик, лить долго, ютуб сам жмет, но зато потом, на тюбике картинка красивая выходит.
Пробовал сам ужимать в H264 и получалась лажа. Локально ролик выглядит неплохо, но стоило его залить на ютуб, как тот видимо его еще раз плющил и получалось адское мыло в котором нифига не видно.
Комментатор выше вроде дал ответ.
Youtube сам использует ffmpeg для пережатия, поэтому понимает lossless форматы ffdshow вроде FFV1 или HUFFYUV.
Комментатор выше вроде дал ответ.
Ужас.
Кодек-паки — это первое, что стоит снести нафиг, если планируется работа с видео. В профильных форумах по обработке видео в случае возникновения проблем — это первая рекомендация (к сожалению порой корректно снести всё, что установил кодек-пак очень сложно).
Знаешь какой кодек нужен — покури мануал, поставь нужный. Иначе «возможны» проблемы. А если точнее, то не «возможны», а «будут».
P.S. Для тех, кому нужно лишь пережать видео для загрузки на youtube — лучше воспользоваться специальными однокнопочными конверторами (типа HandBrake), чем связываться с MeGUI & Co. Я не говорю что MeGUI плохая программа (хотя хорошей я её тоже не назову), я говорю, что она _слишком_сложна_ для новичка, которому перекодировать что-то надо раз в пятилетку.
P.P.S. Для просмотра видео кодек-паки тоже не нужны. Гораздо лучше взять плеер, который имеет встроенные декодеры, чем загаживать систему кодек-паками. А плееров таких сейчас навалом: PotPlayer, GOM, VLC, MPC HC, Splash Lite…
Кодек-паки — это первое, что стоит снести нафиг, если планируется работа с видео. В профильных форумах по обработке видео в случае возникновения проблем — это первая рекомендация (к сожалению порой корректно снести всё, что установил кодек-пак очень сложно).
Знаешь какой кодек нужен — покури мануал, поставь нужный. Иначе «возможны» проблемы. А если точнее, то не «возможны», а «будут».
P.S. Для тех, кому нужно лишь пережать видео для загрузки на youtube — лучше воспользоваться специальными однокнопочными конверторами (типа HandBrake), чем связываться с MeGUI & Co. Я не говорю что MeGUI плохая программа (хотя хорошей я её тоже не назову), я говорю, что она _слишком_сложна_ для новичка, которому перекодировать что-то надо раз в пятилетку.
P.P.S. Для просмотра видео кодек-паки тоже не нужны. Гораздо лучше взять плеер, который имеет встроенные декодеры, чем загаживать систему кодек-паками. А плееров таких сейчас навалом: PotPlayer, GOM, VLC, MPC HC, Splash Lite…
PotPlayer, GOM, VLC, MPC HC, Splash Lite
VLC из всех, пожалуй, самый кошерный, остальные freeware в большинстве своём имееют в составе OSS компоненты, часто включённые с нарушением лицензий.
Из freeware стоит ещё упомянуть KM Player корейского разработчика.
Я не знаю в чем измеряется кошерность видео плееров, но на всякий случай сообщу, что PotPlayer — плеер того-же корейского разработчика, который до этого сделал KM Player, продал (кажется) разработку, и начал делать PotPlayer :)
Лично мне Pot нравится больше KM. Последним я пользоваться не мог, а первый является одним из двух установленных у меня в системе плееров.
A Splash Lite (бесплатный вариант платного Splash Pro) — имеет лучше всего оптимизированные декодеры, что позволяет плавно играть 1080-50p на довольно слабых компах, там где MPC HC, VLC и прочие, не справляются даже при использовании аппаратного ускорения (заявляю как владелец камеры, снимающей 1080-50p и не раз присутствовавший при обсуждении выбора плеера для проигрывания такого видео).
P.S. Лично мне VLC из этого списка совершенно не нравится из-за неродного win интерфейса (да, я пользователь win). Упомянул этот плеер т.к. он не смотря на это очень популярный и, кстати, может быть использован для конвертации видео (о чем вообще эта статья).
Лично мне Pot нравится больше KM. Последним я пользоваться не мог, а первый является одним из двух установленных у меня в системе плееров.
A Splash Lite (бесплатный вариант платного Splash Pro) — имеет лучше всего оптимизированные декодеры, что позволяет плавно играть 1080-50p на довольно слабых компах, там где MPC HC, VLC и прочие, не справляются даже при использовании аппаратного ускорения (заявляю как владелец камеры, снимающей 1080-50p и не раз присутствовавший при обсуждении выбора плеера для проигрывания такого видео).
P.S. Лично мне VLC из этого списка совершенно не нравится из-за неродного win интерфейса (да, я пользователь win). Упомянул этот плеер т.к. он не смотря на это очень популярный и, кстати, может быть использован для конвертации видео (о чем вообще эта статья).
x264 не положил на лопатки Xvid. Он заметно больше времени тратит на распаковку. По-крайней мере, на мобиле это заметно и после перехода eztv.it на x264 пришлось активно использовать mencoder.
Не ясно в чем преимущество перед Handbrake. Хотя в нем тоже есть куча настроек, я никогда ими не пользовался и совершенно не жалею об этом. Там есть несколько пресетов, которые подходят для PS3, PSP, BlackBerry, iШнягам, YouTube, а что еще нужно?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
x264 или как кодировать видео