x264 или как кодировать видео

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

Сразу оговорюсь, что изначально статья не моя. Я наткнулся на неё, лет пять назад, когда встала задача что-то делать с записанными моментами из тогда любимой многими игры Battlefield 2, на популярном отечественном ресурсе мувимейкеров. Постепенно статья допиливалась и публиковалась, то там, то там. Не исключаю, что первоначально статья пришла из-за «бугра» и всего на всего была переведена на наш могучий язык.

Итак, кодек х264 пришел на смену таким монстрам своего времени как DivX и XviD и удачно положил обоих на лопатки. Для того, что бы добиться действительно впечатляющего результата, нам понадобится следующие вещи:
1. MeGUI — этим мы сжимаем само видео. Вернее, сжимает сам кодек, а это только GUI объединивший в себе десятки разных специализированных утилит.
2. Avisynth — фреймсервер. Если вдруг кто не знает, что это такое, то он является посредником между нашим не сжатым видео и кодеком.
3. VLC media player — Тут совсем все просто. Всеядный плеер, умеющий работать с потоковым видео. Достаточно популярный.
4. K-Lite Codec Pack — пакет все возможных кодеков, на все случаи жизни. Нам нужна сборка Mega.

Настоятельно рекомендую обновлять K-Lite Codec Pack, как минимум всегда перед сжатием видео. Это конечно не обязательно, но опыт подсказывает, что если вы столкнетесь с непонятными ошибками/косяками/глюками/etc то в 50%, а то и больше, обновление кодеков избавит вас от лишнего геморроя.
Кстати, MeGUI достаточно быстро и часто обновляется и дополняется. Скриншоты приведенные ниже, могут уже не соответствовать текущей версии, но это не страшно. Как правило, меняется расположение элементов, что то пододвинули вправо, что-то перенесли в другую закладку. Пропажа находится очень быстро, поэтому не пугайтесь.

Поехали. Устанавливаем Avisynth, а затем MeGUI. После того, как MeGUI обновится, идем в папку, где лежит наш опытный образец, и для удобства создаем там файл с расширением *.avs. Открываем блокнотом и пишем заветные строки:

AVISource(«video.avi»)
ConvertToYV12()


Первая строка, подскажет MeGUI с каким файлом требуется работать. Вторая строка, указывает на используемую систему цветов.

Существует несколько различных способов представление цвета. Например: цветовое пространство YUV и RGB. В YUV цветовом пространстве есть один компонент, который представляет яркость (сигнал яркости) и два других компонента, которые представляют цвет (сигнал цветности). В то время как яркость передается со всеми деталями, некоторые детали в компонентах сигнала цветности могут быть удалены путем понижения разрешения отсчетов (фильтрация или усреднение), что может быть сделано несколькими способами (т.е. есть много форматов для сохранения изображения в цветовом пространстве YUV). YV12 — один из таких форматов (тут сигнал цветности общий для каждого блока пиксел 2x2), который поддерживается AviSynth.


У нас получился скрипт. Идем дальше. Открываем MeGUI и указываем месторасположение скрипта. Если скрипт AviSynth находится в той же папке где и ваше видео, то вторая строка заполнится автоматически.



Открываем настройки кодека, нажатием на кнопку Config, справа от Encoder settings. Ставим галочку, подтверждая, что нам действительно нужны расширенные настройки. Дальше нам остается поставить галочки в соответствии со скриншотами.







Нажимаем на кнопку queue и идем спать, пить кофе и т.д. в зависимости от предпочтений и мощностей ПК.

Хочу оговориться, что данный конфиг подходит для исходного видео 720p. Для 1080p нужно немного под редактировать конфиг:

Вкладка Frame-Type -> Меняем значение Number of Reference Frames с 9 на 4.


Так же можно указать, сколько кодеру можно использовать ядер:
Вкладка Misc -> раздел Other -> Threads и указываем, в сколько потоков сжимать видео. 1 поток на 1 виртуальное или физическое ядро.


Что мы получаем в итоге. Я имел в наличии следующий видео-ролик:
Format: RGB
Codec ID: 0x00000000
Codec ID/Info: Basic Windows bitmap format. 1, 4 and 8 bpp versions are palettised. 16, 24 and 32bpp contain raw RGB samples
Duration: 3mn 42s
Bit rate: 663 Mbps
Width: 1 280 pixels
Height: 720 pixels
Display aspect ratio: 16:9
Frame rate: 29.970 fps
Bit depth: 8 bits
Bits/(Pixel*Frame): 24.000
Stream size: 17.2 GiB (100%)


После ожидания около 15-16 минут, я получил на выходе 184 Мб.



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

Комментарии 71

    +3
    Двухпроходное кодирование сильно улучшит результат если есть время на кодирование.
      0
      Да, конечно. А три прохода в некоторых случаях дадут ещё больше профита :-)

      Просто я хотел затронуть эту тему, в следующей части, т.к. и сами настройки кодека надо менять и этот пост получился бы не очень длинным.
        +1
        Опечатался. Имел ввиду, что пост получился бы очень длинным.
          +4
          Очень интересно будет прочитать о настройках в следующей части. Насколько я знаю, для разного рода видео нужно использовать свои настройки. Например, для мультфильмов настройки кодера, по идее, должны отличаться от настроек кодера для обычных фильмов.
          +3
          Для x264 третий проход лишний, особенно после появления mbtree. Я ещё не натыкался на случаи, когда он давал заметный выигрыш.
          +2
          Двухпроходный алгоритм нужен в первую очередь тогда, когда нужно иметь файл определённого размера. Если же вас интересует именно постоянное качество, не зависящее от того что на ролике (глупо тратить на ролик состоящий из статичной сцены столько же битрейта, сколько и на сверх-динамичный, где практически в каждом пятом кадре фактически новое изображение).
            0
            так же оно нужно если хочется в определённый битрейт для веб передачи фильмов например обеспечить как можно лучшее качество
              +1
              Битрейт и конечный размер файла взаимосвязаны.
                +1
                Задачи разные.
                Одна задача это если надо допустим уместить фильм на CD, т.е. фильм любой длины в 700МБ.
                А другая это когда допустим любой фильм кодировать так чтоб пролез через мегабитный канал.
                  –1
                  Как раз таки задача одинаковая, просто с немного различными данными. Например, в случае если вам нужно уместить 1.5 часовой фильм на 700 Мб, получаем:
                  700*8/(1.5*3600) = 1.037 Мбит/с
                  Получили вашу задачу с необходимостью обеспечить нужный битрейт.
                    +4
                    Неверно, при фиксированном размере файла, фактический битрейт может прыгать, от 600 до 1500, допустим (получая средний 1.037, но не пролезая в канал 1.2Мбита).
                      –1
                      Ну хорошо, задача немного отличается в деталях. Но суть всё равно остаётся — если вам нужно контролировать итоговый битрейт/размер, то тогда нужно два прохода, если же вас интересует только итоговое постоянное качество — то однопроходный (--crf).
                      Если ставить задачу гарантированного прохождения потока через ограниченный канал, то тут надо задавать --vbr-max равным ширине канала, правда это достигается за счёт ухудшения качества итогового видео, по сравнению с чистым двухпроходным алгоритмом, т. к. вы ограничиваете диапазон переменного битрейта (статичный сцены получат больший битрейт (что не особо то и нужно), а динамические меньший).
                      Ширина диапазона в котором будет прыгать битрейт будет зависеть от разности ширины канала и целевого битрейта, и в худшем случае, когда они равны, вы получите постоянный битрейт (правда тут не учитывается наличие буфера на стороне клиента).
          +27
          Статья ни о чём.

          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
            –6
            Я брал во внимание когда есть не сжатое видео при весьма не скромных размерах. Зашел, посмотрел примерные настройки как должно быть, сделал так же у себя, получил профит.

            Углубляться в дебри, и рассказывать для чего нужна каждая галочка, в данном топике не хотел. Но отлично понимая, какой контингент читает Хабр, предчувствовал, что без тех. части не обойтись, поэтому сделал не большую ссылку на YV12. В следующий раз, я ещё больше сделаю акцента на тех. части.
              +4
              Согласен. Даже на рутрекере лучше написано, чем в этом топике.
              0
              Если будете описывать настройки кодеков в следующих статьях, то если можно — использовать примеры, для чего оно и как, т.к. понравилось про YUV — кратко и интересно.
                0
                А как сейчас обстоят дела с поддержкой x264 в различных домашних медиа-девайсах: DVD-проигрывателях, телевизорах, и др. различных устройствах?
                  +1
                  Сейчас h264 уже наверное поддерживается большим количеством устройств, чем xvid/divx. По крайней мере современные устройства затачивают на воспроизведение именно этого формата. Другое дело не все параметры поддерживаются разными устройствами. Например некоторые поддерживают только baseline-профиль, другие имеют ограничение на кол-во референсных кадров (-ref), например Asus O Play! — не более 9 ReFrame.
                    0
                    х264 это кодек. А стандарт H264 или MPEG-4 Part 10 или AVC.
                    Во всех новых девайсах этот стандарт поддерживается по умолчанию.
                    Просто в зависимости от мощности устройства он тянет разные уровни стандарта. Baseline или High например.
                    0
                    Если вы пережимали видео геймплея Battlefield2, откуда у вас взялось видео в YUV?
                      0
                      Какая разница, что записывалось для данной ситуации? А вообще изначально было просто RGB.
                        0
                        My bad, невнимательно прочитал, думал конвертация из YUV. Но тогда другой вопрос, зачем конвертировать в YUV? Будет меньше размер? Лучше картинка?
                          0
                          h264 по моему, кодирует только его.
                            +1
                            По меньшей мере x264 поддерживает RGB, а вот есть ли это в стандарте H264, к сожалению не могу найти.
                            Из --help:
                            --output-csp Specify output colorspace [«i420»] — i420, i422, i444, rgb
                      +21
                      Мои много «НО»:
                      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
                        а где покурить смысл этих волшебноудобных параметров (3), их назначение и границы применимости?
                          0
                          Наиболее полное описание параметров видел тут, ну и конечно в --help консольного енкодера, т. к. параметры время от времени бывают меняются.
                        +13
                        Та статья, в которой комменты интересней самой статьи.
                          +3
                          На Хабре таких большинство, мне кажется.
                          +1
                          Большое комьюнити AMV-шников пользуется для кодирования AMVSimple GUI:
                          amvnews.ru/index.php?go=Pages&in=view&id=34

                          Что приятно берет на вход помимо Uncompressed в том числе и AVISynth скрипты.
                            +6
                            Зачем столько телодвижений, если пережимание в 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
                            
                              –1
                              Командная строка вообще почти идеальный способ взаимодействия с компьютером. Смысл слова «почти» в том, что у этого интерфейса есть только один недостаток — нужно запоминать команды.
                                +3
                                Можно один раз записать эти команды в скрипт и запускать его.
                                +1
                                Меня вот интересуют оптимальные настройки по битрейту для BD FullHD пережимаемого в mkv. Хотелось бы сохранить максимальное качество при небольшом объеме (10-15 Гб) за счет времени обработки (несколько проходов, ReFrames и прочее). Какое кстати преимущество ac3 перед aac?
                                  0
                                  Для выбора оптимальных настроек я кодировал кусок фильма с разными параметрами и сравнивал.
                                  Звуковым кодеком выбрал ac3, как более распространенный. В принципе, можно и с aac попробовать.
                                    +1
                                    Каких только настроек не встречал. Хотелось бы выделить какой-то базовый набор параметров (вот эти параметры ставим всегда и не меняем), и небольшую табличку (2-3 фиксированных значения) для изменяемых параметров, например для анимации ставим такое значение, для фильмов другое. Мне казалось aac по качеству лучше, а ac3 просто исторически больше распространен, совместимость с железом и лицензионные ограничения мало волнуют.
                                –2
                                Прогрессивные люди уже используют WebM (в частности, кодеки VP8 и Vorbis) вместо x264. По слухам, сейчас эффективность кодирования по стандарту WebM с последними версиями кодеков превысило возможности x264.
                                  0
                                  Серьёзно? Честно говоря, мечтаю именно об этом. Где почитать сравнения?
                                    +3
                                    Это только слухи. Достаточно посмотреть результаты тестов.
                                      0
                                      Всё слухи.
                                      Разработчики, конечно, бьются за улучшения. Но на деле серьёзная работа приносит плоды считанных процентов. А преподносится каждый раз как прорыв, оттуда и слухи.

                                      Сравнение VP8 и x264, наиболее актуальное, можно посмотреть тут.
                                      compression.ru/video/codec_comparison/index.html

                                      Судя по графикам, качество вполне сравнимое, но везде есть пометка, что VP8 не соответствует требованиям по времени. В действительности, сравнение кодеков проводится не по двум параметрам «размер/качество», а по трём — «размер/качество/скорость».
                                      По сравнению видно, что VP8 достаёт по качеству x264, но при этом в разы уступает по скорости. Если же попробовать уравнять их по скорости, то у VP8 просядет качество либо увеличится размер.
                                      И скорость является достаточно важным фактором, поскольку она напрямую связана с требуемыми мощностями и энергопотреблением. Этот вопрос является актуальным, поскольку бОльшая часть видео кодируется либо на девайсах, работающих от аккумулятора на этапе записи (телефоны, видеокамеры), либо на серверах сервисов вроде YouTube.

                                      И поскольку формат VP8 более ограниченный, с большой вероятностью VP8 будет уступать лучшим кодекам стандарта H.264. Хотя гугл заинтересован в том, чтобы это отставание было минимальным.
                                        0
                                        Не могу найти сравнение кодеков VP8 и x264 за 2012 год. Это вообще сравнивалось в этом году? За последний год кодек VP8 очень сильно оптимизировали.
                                          0
                                          За 2012 год ещё нет сравнения.
                                          В 2011 его тоже «очень сильно оптимизировали», но это не значит, что он от этого должен обязательно обогнать x264. И тот тоже не стоит на месте.
                                            0
                                            Вот тут новость от 11 мая: www.opennet.ru/opennews/art.shtml?num=33825

                                            В обсуждении люди всерьёз говорят о переходе с x264 на WebM: «Еще годик и начнем, щас в группе рипперов тестим WebM 1080/720p и H.264 аналогичного качества, много споров и сомнений, хотя как по мне — разница в качестве минимальна (3-5%), либо вообще незаметна. Так что год максимум я бы еще потерпел, пара обновлений выйдет и можно переходить полностью на этот замечательный кодек.»
                                              0
                                              Новость я видел, но там все улучшения по частным случаям и довольно специфичные. Они не дают радикального прироста.

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

                                              Рипперы тоже разные бывают. То, что на т.ру кто-то выкладывал рипы с помощью Theora, ещё не значит, что так делать правильно.
                                                0
                                                Послушайте, вы дали ссылку, где есть сравнение кодеков 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 года.

                                                Сейчас идёт «полировка» кода. Каждый квартал выпускается исправленная и улучшенная версия, отсюда быстродействие растёт незначительно, так как код и формат структур данных кодека уже стабилизированы и меняются незначительно.
                                                  0
                                                  У вас более свежие цифры есть?

                                                  Формулировка «Webm нынче жмет на уровне baseline профайла h.264. Совершенно без скидок.» подразумевает сравнение форматов, на самом деле. И если у WebM одна реализация, то у H.264 их десятки, если не сотни. И baseline profile, как следует из названия, это базовые возможности для совместимости с самыми слабыми железками.
                                                    0
                                                    На уровне baseline — это разве достижение?
                                                    Вообще все эти разговоры вокруг VP8 ерунда несусветная, потому что аппаратной поддержки его практически нигде нет, в отличие от h264, который и сжимает лучше.
                                                    А конечного пользователя юридические заморочки вообще не должны волновать.
                                                    Следующий рывок качества будет в стандарте h265, до которого VP8 конечно же как до луны.
                                          0
                                          Отлично. А сколько телевизоров, плееров и мобильных телефонов поддерживают WebM?
                                          +5
                                          Хочу, чтобы затронули тему CUDA при транскоде.

                                          Я одно время очень быстро и приятно пережимал фрапсы при помощи badaboom (от nvidia) — там мало профилей и настроек, но скорость сжатия исходного материала в х264 радует.

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

                                            0
                                            Xilisoft Video Converter довольно мощный, использует CUDA и даёт возможность вручную выбрать разрешение и битрейт, в отличие от Badaboom.
                                              0
                                              CUDA по качеству пока даёт гавно, достаточное только для еденичного просмотра на телефоне/планшете, а не для длительного хранения (качество на уровне x264 --superfast), это видно на тестах compression.ru
                                              Intel Quicksync впрочем тоже, но чуть получше (на уровне --veryfast)
                                              Может когда-нибудь качество вырастет (особенно когда x264 портируют на OpenCL), но не сейчас.
                                              Кстати есть li5.ziti.uni-heidelberg.de/x264gpu/, но там код от 2008 года, с тех пор x264 далеко ушёл вперёд. Жаль что разработчики x264 никак не родят OpenCL версию сами.
                                                +3
                                                Предполагаю, что дело не в технологии CUDA, а в реализации кода badaboom.
                                                0
                                                бесплатный комбайн-транскодер MediaCoder тоже вроде бы поддерживает CUDA
                                                0
                                                есть 2 часа видео(кусками) с камеры в 1080п весом гигов 20 в формате .mts как и чем жать чтобы получить нормальный контейнер и приемлемый вес с видео в хорошем качестве, и для второй версии насколько сжать которую заливать на ютуб(всего 20 минут)
                                                  +1
                                                  Контейнер — MP4 или MKV, битрейт можно выставить как у устраивающих по качеству BDRipов. А для Youtube битрейт его родной битрейт (6Мб/с), умноженный на полтора, будет достаточен.
                                                  +1
                                                  Мне было бы очень интересно прочитать про скринкасты. В каком разрешении снимать, чем жать, чтобы людям было не больно смотреть на элементы интерфейса. Сейчас я рисую на рабочем столе прямоугольник размером 1280×720, выставляю размер окон программ (которые участвуют в скринкасте) такого размера, в Камтасе захватываю только эту область. Видимо, делаю не верно, а как правильно – хотел бы узнать из статьи.
                                                    –2
                                                    В свое время закачивал аниме в контакт. Основным требованием к конвертеру было умение встраивать ssa/ass-сабы, поэтому выбор пал на xvid4psp. Он тоже использует avisynth и у него есть специальные синхронизаторы, чтобы видео/аудио/сабы не расползались. Как с этим у MeGUI?
                                                      +1
                                                      Фраза «не одну кошку съели» ввела меня в ступор.
                                                        0
                                                        А вы разве не знали, что профессиональные кодировщики видео едят кошек?
                                                          +1
                                                          Не предполагал даже, если честно. Хотя если кодировщик действительно профессиональный, то он ее и в говядину наверное перекодирует, и в авокадо ;)
                                                          0
                                                          Может первоначальный автор статьи был китайцем или корейцем? :}
                                                          +7
                                                          А как лучше пережать видео, чтобы его ютуб не похерил?

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

                                                          Пробовал сам ужимать в H264 и получалась лажа. Локально ролик выглядит неплохо, но стоило его залить на ютуб, как тот видимо его еще раз плющил и получалось адское мыло в котором нифига не видно.
                                                            0
                                                            Комментатор выше вроде дал ответ.
                                                              0
                                                              Youtube сам использует ffmpeg для пережатия, поэтому понимает lossless форматы ffdshow вроде FFV1 или HUFFYUV.
                                                              0
                                                              Комментатор выше вроде дал ответ.
                                                                +5
                                                                Ужас.
                                                                Кодек-паки — это первое, что стоит снести нафиг, если планируется работа с видео. В профильных форумах по обработке видео в случае возникновения проблем — это первая рекомендация (к сожалению порой корректно снести всё, что установил кодек-пак очень сложно).
                                                                Знаешь какой кодек нужен — покури мануал, поставь нужный. Иначе «возможны» проблемы. А если точнее, то не «возможны», а «будут».

                                                                P.S. Для тех, кому нужно лишь пережать видео для загрузки на youtube — лучше воспользоваться специальными однокнопочными конверторами (типа HandBrake), чем связываться с MeGUI & Co. Я не говорю что MeGUI плохая программа (хотя хорошей я её тоже не назову), я говорю, что она _слишком_сложна_ для новичка, которому перекодировать что-то надо раз в пятилетку.

                                                                P.P.S. Для просмотра видео кодек-паки тоже не нужны. Гораздо лучше взять плеер, который имеет встроенные декодеры, чем загаживать систему кодек-паками. А плееров таких сейчас навалом: PotPlayer, GOM, VLC, MPC HC, Splash Lite…
                                                                  0
                                                                  PotPlayer, GOM, VLC, MPC HC, Splash Lite

                                                                  VLC из всех, пожалуй, самый кошерный, остальные freeware в большинстве своём имееют в составе OSS компоненты, часто включённые с нарушением лицензий.
                                                                  Из freeware стоит ещё упомянуть KM Player корейского разработчика.
                                                                  0
                                                                  Я не знаю в чем измеряется кошерность видео плееров, но на всякий случай сообщу, что PotPlayer — плеер того-же корейского разработчика, который до этого сделал KM Player, продал (кажется) разработку, и начал делать PotPlayer :)
                                                                  Лично мне Pot нравится больше KM. Последним я пользоваться не мог, а первый является одним из двух установленных у меня в системе плееров.

                                                                  A Splash Lite (бесплатный вариант платного Splash Pro) — имеет лучше всего оптимизированные декодеры, что позволяет плавно играть 1080-50p на довольно слабых компах, там где MPC HC, VLC и прочие, не справляются даже при использовании аппаратного ускорения (заявляю как владелец камеры, снимающей 1080-50p и не раз присутствовавший при обсуждении выбора плеера для проигрывания такого видео).

                                                                  P.S. Лично мне VLC из этого списка совершенно не нравится из-за неродного win интерфейса (да, я пользователь win). Упомянул этот плеер т.к. он не смотря на это очень популярный и, кстати, может быть использован для конвертации видео (о чем вообще эта статья).
                                                                    +1
                                                                    x264 не положил на лопатки Xvid. Он заметно больше времени тратит на распаковку. По-крайней мере, на мобиле это заметно и после перехода eztv.it на x264 пришлось активно использовать mencoder.
                                                                      0
                                                                      Не ясно в чем преимущество перед Handbrake. Хотя в нем тоже есть куча настроек, я никогда ими не пользовался и совершенно не жалею об этом. Там есть несколько пресетов, которые подходят для PS3, PSP, BlackBerry, iШнягам, YouTube, а что еще нужно?

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

                                                                      Самое читаемое