Легенды и мифы современных реализаций x265/HEVC или x264 vs x265 в сравнении скриншотов


    Удивительно, но факт — стандарту сжатия видео High Efficiency Video Coding (HEVC) уже более трех лет. Существуют не только программные, но и аппаратные решения для кодирования и даже бытовые медиаплееры с поддержкой этого формата. Интернет завален рекламными хвалебными восторженными отзывами и обзорами, причем обозреватели, в зависимости от наглости безграмотности доверчивости, обещают улучшение сжатия на 30-50% по сравнению с h.264 при том же качестве картинки. Теоретически оно наверняка так и есть и я совершенно ничего не имею против самого стандарта, всей этой высшей математики, множественности профайлов и объективной оценки субъективного восприятия психофизиологических параметров с помощью PSNR. Побудительным мотивом для написания этой антинаучной статьи послужила чистая недоверчивость, желание самостоятельно пощупать имеющиеся на данный момент свободные реализации кодировщиков видео в этот формат (x265) и сравнить результаты со старым добрым x264.

    Чтобы понять масштаб проблемы и степень моей недоверчивости, отмечу, что я не верю в аппаратное кодирование в h.264/AVC (а точнее уверен, что с той же и скоростью при лучшем качестве может работать и чисто программный x264.exe), не верю в кодирование видео с помощью CUDA и DXVA и считаю все реализации таких «кодировщиков» чистым шарлатанством и не верю в магические двухкнопочные программы, которые могут «закодировать быстро и хорошо». Еще я не верю в демократию, антивирусы и современное высшее образование, но это уже чисто мои проблемы не имеющие отношения в кодированию видео :)
    А теперь, зарядившись изрядной долей скептицизма возьмем один из скомпилированных вариантов свободного кодировщика x265, а точнее восьмибитовую GCC сборку 1.7+286 и все дальнейшие действия будем производить с ней.
    В этом пункте, кстати, моя недоверчивость опять взбрыкнула и пришлось потратить около 6 часов для сравнения 11 разных сборок с разных сайтов чтобы ее успокоить. Оказалось что результаты кодирования с аналогичными параметрами были идентичны до степени смешения, а время кодирования отличалось не больше чем на 5-6 процентов.
    Для начала, возьмем в качестве исходника упомянутый выше отрывок из Аватара брызги-дерево-туман и чтобы исключить тормоза декодера, сохраним 100 кадров и из него в виде несжатого YUV4MPEG2 файла, который в дальнейшем и будет кодироваться. В x265 по умолчанию применяется CRF метод сжатия с постоянным качеством, поэтому закодируем и в x264 тоже в режиме CRF с показателем качества 17.2. Цифра взята не с потолка, а опытным путем выяснено что любое увеличение этой цифры ведет к понижению и битрейта и качества картинки на выходе, а уменьшение только повышает битрейт без какого-либо заметного увеличения качества. Конечно же остальные параметры кодирования были тоже на максимуме и в результате получился сжатый файл с битрейтом 17.6 Mb/s (что почти в 2 раза ниже исходных 31 Mb/s на BD диске). Время кодирования 100 кадров — 40 секунд. Качество картинки получилось почти идентичным по сравнению с исходником и даже не стоит выкладывать сравнение. В дальнейшем мы будем сравнивать 12-й В-кадр файла x264-17.2.mkv с разными вариантами кодирования в HEVC.

    x265 радует нас множеством готовых пресетов, но нас конечно же будет интересовать самый последний — placebo. На самом деле даже placebo не обеспечивает максимальные установки, но об этом чуть позже. По умолчанию x265 кодирует с показателем качества 28 (возможно в этом и есть глубокий смысл, но я его не уловил). С такими установками битрейт выходного файла получается менее 2 Mb/s (для 1080p) и вместо картинки на выходе такое мыло, что и смотреть невозможно и сравнивать смысла нет. Поэтому на первый раз ужесточим условия совсем немного и воспользуемся максимально короткой командной строкой
    "E:\Video\x265\x265_64-8.exe" "E:\Video\avatar\raw.y4m"  --crf 23 --preset placebo --output "E:\Video\avatar\x265-test1.mkv"
    
    В результате у нас получится файл с битрейтом 5.4 Mb/s. Время кодирования чуть менее 7 минут. Качество в принципе не плохое, но пока до x264 далеко. На ссылке сравнение скриншотов общим весом около 6 Мб на сайте screenshotcomparison.com (виноват, но я не знаю другого удобного способа сравнивать скриншоты)

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

    Попытка #2, crf 20, битрейт 9050 kb/s — лучше, но все равно не то


    А вот тут пора вспомнить что пресет placebo использует далеко не самые максимально возможные параметры. Наиболее важные здесь --me star (при максимальном значении full) и --subme 5 (при максимальном 7). Попробуем ужесточить условия и вручную сказать
    "E:\Video\x265\x265_64-8.exe" "E:\Video\avatar\raw.y4m" --preset placebo --me full --subme 7 --psy-rd 0.5 --psy-rdoq 0.5 --output "E:\Video\avatar\x265-test1.mkv"
    
    Сразу же становится понятным почему разработчики не рискнули вставить в «максимальный» профайл максимальные значения параметров. Время кодирования увеличилось более чем в 10 раз

    И стоил ли результат этих жертв? не уверен…
    Итак попытка #3, crf 20, -me full --subme 7, битрейт 9045 kb/s — 77 минут кодирования


    И тут же сравнение результатов пресета placebo с вручную заданными -me full --subme 7


    Выкидываем вручную заданные me, subme и ползем дальше.
    Попытка #4, crf 18, битрейт 12922 kb/s — почти хорошо, но x264 пока лучше


    Теперь посмотрим что будет если закодировать в x265 с тем же битрейтом что и x264 и с максимальными параметрами.
    Этого же битрейта удалось достичь при значении crf 16.2. В этот раз кодирование заняло 90 минут.
    Ссылка на файл

    Результаты очень близки, но все же x264 сохранил чуть больше деталей и добавил чуть меньше мыла.
    Вывод: Текущие реализации x265 проигрывают по качеству x264 на высоких битрейтах.

    Вот мы и подошли к основному посылу всей статьи. Форматы сжатия видео вместе со всем остальным миром катятся в сторону упрощения и отупления населения. Никому не интересно иметь потребителя, который разглядывает скриншоты сравнений, борется за каждый лишний пиксель искажений, вчитывается в параметры кодирования и т.д. Все затачивается на максимально быстрые и смешные профайлы кодирования с минимальными битрейтами. Наверняка на низких битрейтах x265 будет иметь значительное преимущество над x264. Хотя и там и там будет масса искажений и мыла, но у x264 будет больше. Проверим.
    Попытка #5, x265 5371 kb/s, x264 5374 kb/s


    А вот и не отгадали :) Даже на родном для x265 битрейте x264 выглядит поприличнее.

    Выводы делайте сами, а я с надеждой жду объективной критики :)
    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 97

      +4
      1) Ваш анализ становится неверным после вот этой фразы:
      Для начала, возьмем в качестве исходника упомянутый выше отрывок из Аватара брызги-дерево-туман и чтобы исключить тормоза декодера, сохраним 100 кадров и из него в виде несжатого YUV4MPEG2 файла, который в дальнейшем и будет кодироваться.
      Т.е. с самого начала. Вы берете уже пожатый файл и пытаетесь его пережать.

      2) В последних сравнениях все не очень однозначно, картинка на x265 не столько более мыльная, сколько на мой взгляд содержит меньшее количество артефактов кодирования. Некоторые фрагменты смотрятся хуже, некоторые — лучше. Но опять же — учитывая изначальную ошибку сравнение некорректно.
        +1
        Это конечно да, но где взять более качественное тестовое видео как не с блюрей диска?
          +4
          Попробуйте взять рендеры проекта Blender. 4K, разного уровня насыщенности деталями сцены, отсутствие артефактов сжатия.
          Я свои эксперименты по поиску оптимального BPS/resolution делал именно на них. Хотя можно и здесь придраться к тому, что такой тест будет синтетическим.
            +1
            Ищите не пожатый исходник в Apple ProRes, «киношники» часто с ним работают, как с оригиналом. Может примеры какие к Final Cut есть в нормальном качестве. 31 Mb/s это уже сильно пожато. Еще можно самому TIFF sequence наснимать :)
              +1
              Да… Виноват опять — не догадался с самого начала взять исходником что-то покачественней, а теперь уже лениво и я для себя вывод сделал. Не стоит оно пока 10-ти кратного увеличения времени кодирования. Посмотрим-попробуем что будет через год-полтора.
                +2
                Так время кодирования — вообще не аргумент. Добавить N часов кодирования для релиза фильма (бюджет измеряется миллионами) чтобы пользователь получил более качественную картинку — вообще не вопрос. Добавить N часов кодирования к сериалу чтобы пользователи могли стримить его на мобильники при более плохом интернете — тоже не проблема, цена подписки окупит. А домашнее видео — оно же вроде все равно пишется изначально пожатым практически любой камерой/фотоаппаратом/телефоном, разве нет?
                  +1
                  > Добавить N часов кодирования к сериалу чтобы

                  Тут как раз не надо так однозначно. Это очень тонкий баланс, который можно нарушить.
                    0
                    С чего не однозначно? На съемку уходит денег и времени в разы больше.
                      0
                      Вы исходите из того неверного предположения, что готовят для раздачи те же люди, которые и снимают.
                        –2
                        Т.е. Amazon, например, чтобы стримить видео покупает blu ray диск с фильмом/сериалом, пережимает его и стримит? Серьезно?
                          0
                          Амазон. Стримить?

                          Разговор идет о том, чем пользоваться обычному OTT оператору. Единицы в самом топе типа нетфликса особого интереса не представляют, поскольку при их масштабах их опыт не повторяется.
                            0
                            Amazon Instant Video, да, стримит видео.
              0
              Для тестирования енкодеров, нужно использовать сырое исходное видео.
              Взять его можно, например, здесь.
                0
                Там какие то старые sd кадры, не актуально думаю.
                Лучше брать здесь: www.arri.com/camera/alexa/learn/alexa_sample_footage
                  0
                  Гляньте еще раз, там есть и 2К
                  Интел свой квик синк H265 в том числе на этих стримах тестирует.
              +4
              Только если вы не в курсе, но почти всё видео так и получается.

              Доступ до оригинала есть только в телестудии (куда никого не пустят никогда и ни за что) и на IP камерах.

              На IP камерах другие ориентиры, а 99% всего видео в интернете — это пережатое откуда-то ещё. Либо скачанное с торрентов, либо рипованное с блюрея, либо стянутое со спутника.

                0
                И к чему это было сказано? Котик с телефона выложенный на ютуб может быть вообще в любом формате, там разнцу в качестве заметить тяжело будет. А вот возможность стримить качественное видео FullHD используя узкий канал или улучшить качество видео при том же объеме диска — это и есть цель кодека. Пережимать однажды сжатое — это не совсем цель.
                  0
                  к тому, что вы неправильно представляете процесс подготовки видео для раздачи в интернете.
                    +1
                    А при чем здесь подготовка к раздаче ворованного контента и котиков на ютубе? h.264 это кодек, который используется в блюреях и для раздачи стримингового кино — т.е. жмется исходник. Так зачем сравнивать непонятно что, если h.265 призван его заменить? Такие статьи всегда весело читать, потому что они сравнивать не пойми что и из этого делают далеко идущие выводы о таких серьезных вещах как новый индустриальный стандарт кодирования видео.
                      0
                      Вы не знакомы с реалиями подготовки и раздачи видео, если вы думаете, что только ворованный контент пережимается.

                      Доступ к сырому видео из телестудии есть очень у ограниченного числа людей.
                        0
                        Так какие это реалии? Блюрей что ли готовят из уже пережатого? Стриминговое видео для iTunes, Netflix из уже пережатого готовят? А больше ничего интереса и не представляет в данном контексте.
                          0
                          При чём тут нетфликс, если разговор идет о том, чем пользоваться людям?
                            –2
                            Люди нетфликсом и пользуются. Причем очень успешно.
                              0
                              Вы лучше на вопрос ответьте.
                                +1
                                Ваш предыдущий комментарий просто смешон: «больше ничего интереса и не представляет».

                                Опыт нетфликса как раз интересен постольку поскольку, потому что его не повторить.

                                Во-первых, сырое видео им вряд ли дают. Какие-то ролики могут и приносить, но в целом маловероятно.

                                Я держу пари, но вы ни разу в жизни даже не видели, как выглядит сырой ролик. Я работаю с видео очень давно и много и видел только один раз. Когда я спросил, не оригинал ли это, меня выгнали из комнаты, а ролик заперли в сейф.

                                Сырое видео очень мало распространяется и поэтому для интернета интересны прежде всего вопросы пережатия из одних сжатых форматов в другие.

                                И чего там удобнее для нетфликса для всех остальных должно быть наплевать, потому что это проблема нетфликса.
                                  +1
                                  Работаешь с видео давно, а оперируешь странными терминами))
                                  Что ещё за сырое видео? Больше похоже на исходники-равчики, нежели на готовый продукт.
                                  Может речь про мастер-копию?
                                  А вообще да, конечно стриминговое видео для iTunes, Netflix и прочих готовят из уже пережатого материала и это ок
                +1
                для начала нужно определиться, что имеется в виду под преимуществами h265 на h264. Дальше ответить на вопрос почему мы выявляем эти преимущества с помощью x265 и корректно ли это.
                Пресеты почему-то называются презентами. Дефолтный crf 23 превратился в 28.
                  –1
                  Насчет пресетов точно и спасибо — полчетвертого утра было :) А статья на самом не деле не об h.265, а про современные реализации x265
                    0
                    больше интересует ответ на первую часть комментария)
                      –1
                      Я ни минуты не сомневаюсь что у h265 огромные перспективы и со временем все там будем. Но по-моему пока рано — доступные инструменты еще только в самых ранних стадиях разработки, да и вычислительные мощности не поспевают.
                        0
                        поэтому название темы не соответсвует. Легенд и мифов о реализациях я не слышал)
                        они есть об алгоритме, о generic encoder.
                          +1
                          Вычислительные мощности тут не при чем, как таковые. Реализуют кодер/декодер в железе и будет работать для рядового пользователя «на лету», как сейчас некоторые вебки пишут в h264.
                            +1
                            Теоретически уже и то и то есть — AL1200 и Sigma SMP8756. Последний надеюсь пощупать как только новые дюны начнут продавать.
                    +2
                    Чтобы понять масштаб проблемы и степень моей недоверчивости, отмечу, что я не верю в аппаратное кодирование в h.264/AVC (а точнее уверен, что с той же и скоростью при лучшем качестве может работать и чисто программный x264.exe)


                    Активно пользуюсь QuickSync'ом, качество у него действительно хуже чем у программного кодирования, но при программном кодировании при самых низких настройках падение фпс в играх — 10-20, а с QuickSync'ом — 0-5. Так что для начинающих стримеров со слабым железом QuickSync подходит идеально.
                      +1
                      Какое у вас железо? Если, вдруг, Sandy Bridge, и вам не лень 30 минут поиздеваться над ним, пожалуйста, скачайте любой дистрибутив Linux (последняя Ubuntu подойдет), и скодируйте что-либо через gstreamer vaapi примерно так:
                      gst-launch-1.0 -e filesrc location=steins-gate-op-remux.mkv ! matroskademux ! vaapidecode ! videoconvert ! video/x-raw,format=NV12 ! vaapiencode_h264 rate-control=cbr bitrate=3000 ! video/x-h264,stream-format=byte-stream ! h264parse ! matroskamux ! progressreport ! filesink location=bake-cbr-4000.mkv

                      А то у меня на выходе получается просто дрисня какая-то, а баг подтвердить никто не может:
                      ovrload.ru/f/55938_bake-cbr-3000.mkv

                      (оригинальный исходник)
                        0
                        на ivy просто нет декода исходника
                        Скрытый текст
                        [rz2k@victorique x264]$ mpv --vo=vaapi --hwdec=vaapi --hwdec-codecs=all 1.mkv
                        Playing: 1.mkv
                        (+) Video --vid=1 (h264)
                        (+) Audio --aid=1 --alang=jpn (*) (flac)
                        (+) Subs --sid=1 --slang=eng (*) 'qIIq' (ass)
                        File tags:
                        Title: Ep03 Creditless Opening
                        libva info: VA-API version 0.38.0
                        libva info: va_getDriverName() returns 0
                        libva info: Trying to open /usr/lib/dri/i965_drv_video.so
                        libva info: Found init function __vaDriverInit_0_38
                        libva info: va_openDriver() returns 0
                        Using hardware decoding.
                        AO: [pulse] 48000Hz stereo 2ch s16
                        [ffmpeg/video] h264: decode_slice_header error
                        [ffmpeg/video] h264: no frame!
                        Error while decoding frame!
                        Error using hardware decoding, falling back to software decoding.
                        Using conversion filter.
                        VO: [vaapi] 1920x1080 yuv420p
                        AV: 00:00:01 / 00:01:31 (1%) A-V: 0.000

                        Exiting… (Quit)

                        при том, другие mkv работают и на энкод и на декод
                        Скрытый текст
                        [rz2k@victorique Downloads]$ cp \[HorribleSubs\]\ The\ Disappearance\ of\ Nagato\ Yuki-chan\ -\ 13\ \[1080p\].mkv 1.mkv
                        [rz2k@victorique Downloads]$ gst-launch-1.0 -e filesrc location=1.mkv! matroskademux! vaapidecode! videoconvert! video/x-raw,format=NV12! vaapiencode_h264 rate-control=cbr bitrate=3000! video/x-h264,stream-format=byte-stream! h264parse! matroskamux! progressreport! filesink location=output.mkvlibva info: VA-API version 0.38.0
                        libva info: va_getDriverName() returns 0
                        libva info: Trying to open /usr/lib/dri/i965_drv_video.so
                        libva info: Found init function __vaDriverInit_0_38
                        libva info: va_openDriver() returns 0
                        Установка конвейера в состояние PAUSED…
                        Подготовка конвейера (PREROLL)…
                        Получен контекст из элемента «vaapidecode0»: gst.vaapi.Display=context, display=(GstVaapiDisplay)NULL;
                        Конвейер подготовлен (PREROLLED)…
                        Установка конвейера в состояние PLAYING…
                        New clock: GstSystemClock
                        Unrepairable overflow!
                        progressreport0 (00:00:05): 12 / 1477 seconds ( 0,8 %)
                        progressreport0 (00:00:10): 25 / 1477 seconds ( 1,7 %)

                        progressreport0 (00:09:46): 1476 / 1477 seconds (99,9 %)
                        progressreport0 (00:09:46): 1477 / 1477 seconds (100,0 %)
                        Получен маркер EOS («конец потока») от элемента «pipeline0».
                        Execution ended after 0:09:46.203432237
                        Установка конвейера в состояние PAUSED…
                        Установка конвейера в состояние READY…
                        Установка конвейера в состояние NULL…
                        Освобождение конвейера…
                        [rz2k@victorique Downloads]$ mpv --vo=vaapi --hwdec=vaapi --hwdec-codecs=all output.mkv
                        Playing: output.mkv
                        (+) Video --vid=1 (*) 'Video' (h264)
                        File tags:
                        Title: Video
                        libva info: VA-API version 0.38.0
                        libva info: va_getDriverName() returns 0
                        libva info: Trying to open /usr/lib/dri/i965_drv_video.so
                        libva info: Found init function __vaDriverInit_0_38
                        libva info: va_openDriver() returns 0
                        Using hardware decoding.
                        VO: [vaapi] 1920x1088 vaapi
                        V: 00:03:18 / 00:24:37 (13%) Dropped: 2

                        Exiting… (Quit)
                          0
                          А, забыл, он 10-битный. Транскодируйте его как-то так сначала:
                          ffmpeg -i bake.mkv -map v -c:v libx264 -crf 17 -preset fast -tune animation output.mkv
                            0
                            живое rghost.ru/private/85vtCtrmN/1039b0fd8b59090c48b5ff1ba2225298
                            libva 1.6.0
                            vaapi-intel 1.6.0
                            Скрытый текст
                            [rz2k@victorique x264]$ ffmpeg -i 1.mkv -map v -c:v libx264 -crf 17 -preset fast -tune animation 2.mkv
                            ffmpeg version 2.7.1 Copyright © 2000-2015 the FFmpeg developers
                            built with gcc 5.1.0 (GCC)
                            configuration: --prefix=/usr --disable-debug --disable-static --disable-stripping --enable-avisynth --enable-avresample --enable-fontconfig --enable-gnutls --enable-gpl --enable-libass --enable-libbluray --enable-libfreetype --enable-libfribidi --enable-libgsm --enable-libmodplug --enable-libmp3lame --enable-libopencore_amrnb --enable-libopencore_amrwb --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-libschroedinger --enable-libspeex --enable-libssh --enable-libtheora --enable-libv4l2 --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265 --enable-libxvid --enable-shared --enable-version3 --enable-x11grab
                            libavutil 54. 27.100 / 54. 27.100
                            libavcodec 56. 41.100 / 56. 41.100
                            libavformat 56. 36.100 / 56. 36.100
                            libavdevice 56. 4.100 / 56. 4.100
                            libavfilter 5. 16.101 / 5. 16.101
                            libavresample 2. 1. 0 / 2. 1. 0
                            libswscale 3. 1.101 / 3. 1.101
                            libswresample 1. 2.100 / 1. 2.100
                            libpostproc 53. 3.100 / 53. 3.100
                            Input #0, matroska,webm, from '1.mkv':
                            Metadata:
                            title: Ep03 Creditless Opening
                            encoder: libebml v1.2.2 + libmatroska v1.3.0
                            creation_time: 2011-10-29 12:44:08
                            Duration: 00:01:31.51, start: 0.000000, bitrate: 6760 kb/s
                            Stream #0:0(eng): Video: h264 (High 10), yuv420p10le(tv, bt709/unknown/unknown), 1920x1080, SAR 1:1 DAR 16:9, 23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc (default)
                            Stream #0:1(jpn): Audio: flac, 48000 Hz, stereo, s16 (default)
                            Stream #0:2(eng): Subtitle: ass (default)
                            Metadata:
                            title: qIIq
                            Stream #0:3: Attachment: ttf
                            Metadata:
                            filename: cac-moose.ttf
                            mimetype: application/x-truetype-font
                            [libx264 @ 0x7fc83392ce80] using SAR=1/1
                            [libx264 @ 0x7fc83392ce80] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
                            [libx264 @ 0x7fc83392ce80] profile High, level 4.0
                            [libx264 @ 0x7fc83392ce80] 264 — core 144 r2533 c8a773e — H.264/MPEG-4 AVC codec — Copyleft 2003-2015 — www.videolan.org/x264.html — options: cabac=1 ref=4 deblock=1:1:1 analyse=0x3:0x113 me=hex subme=6 psy=1 psy_rd=0.40:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=6 lookahead_threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=5 b_pyramid=2 b_adapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=1 keyint=250 keyint_min=23 scenecut=40 intra_refresh=0 rc_lookahead=30 rc=crf mbtree=1 crf=17.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:0.60
                            Output #0, matroska, to '2.mkv':
                            Metadata:
                            title: Ep03 Creditless Opening
                            encoder: Lavf56.36.100
                            Stream #0:0(eng): Video: h264 (libx264) (H264 / 0x34363248), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], q=-1--1, 23.98 fps, 1k tbn, 23.98 tbc (default)
                            Metadata:
                            encoder: Lavc56.41.100 libx264
                            Stream mapping:
                            Stream #0:0 -> #0:0 (h264 (native) -> h264 (libx264))
                            Press [q] to stop, [?] for help
                            frame= 2194 fps= 12 q=-1.0 Lsize= 65186kB time=00:01:31.42 bitrate=5840.9kbits/s
                            video:65167kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.028508%
                            [libx264 @ 0x7fc83392ce80] frame I:106 Avg QP:13.93 size:117982
                            [libx264 @ 0x7fc83392ce80] frame P:1302 Avg QP:17.85 size: 36857
                            [libx264 @ 0x7fc83392ce80] frame B:786 Avg QP:19.03 size: 7934
                            [libx264 @ 0x7fc83392ce80] consecutive B-frames: 50.1% 13.2% 2.7% 8.2% 6.6% 19.1%
                            [libx264 @ 0x7fc83392ce80] mb I I16..4: 34.0% 44.7% 21.3%
                            [libx264 @ 0x7fc83392ce80] mb P I16..4: 9.0% 10.0% 4.5% P16..4: 25.0% 7.0% 3.1% 0.0% 0.0% skip:41.5%
                            [libx264 @ 0x7fc83392ce80] mb B I16..4: 0.7% 8.1% 0.4% B16..8: 10.6% 2.6% 0.3% direct: 4.9% skip:72.3% L0:49.4% L1:45.7% BI: 5.0%
                            [libx264 @ 0x7fc83392ce80] 8x8 transform intra:49.8% inter:72.3%
                            [libx264 @ 0x7fc83392ce80] coded y,uvDC,uvAC intra: 44.4% 57.1% 31.6% inter: 10.7% 10.3% 2.0%
                            [libx264 @ 0x7fc83392ce80] i16 v,h,dc,p: 67% 18% 7% 8%
                            [libx264 @ 0x7fc83392ce80] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 24% 15% 44% 3% 3% 2% 3% 3% 3%
                            [libx264 @ 0x7fc83392ce80] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 25% 17% 19% 7% 7% 7% 7% 6% 5%
                            [libx264 @ 0x7fc83392ce80] i8c dc,h,v,p: 67% 15% 14% 3%
                            [libx264 @ 0x7fc83392ce80] Weighted P-Frames: Y:1.5% UV:0.2%
                            [libx264 @ 0x7fc83392ce80] ref P L0: 60.8% 19.3% 14.8% 5.1%
                            [libx264 @ 0x7fc83392ce80] ref B L0: 75.6% 21.2% 3.2%
                            [libx264 @ 0x7fc83392ce80] ref B L1: 90.6% 9.4%
                            [libx264 @ 0x7fc83392ce80] kb/s:5833.85
                            [rz2k@victorique x264]$ ls^C
                            [rz2k@victorique x264]$ gst-launch-1.0 -e filesrc location=2.mkv! matroskademux! vaapidecode! videoconvert! video/x-raw,format=NV12! vaapiencode_h264 rate-control=cbr bitrate=3000! video/x-h264,stream-format=byte-stream! h264parse! matroskamux! progressreport! filesink location=output.mkv
                            libva info: VA-API version 0.38.0
                            libva info: va_getDriverName() returns 0
                            libva info: Trying to open /usr/lib/dri/i965_drv_video.so
                            libva info: Found init function __vaDriverInit_0_38
                            libva info: va_openDriver() returns 0
                            Установка конвейера в состояние PAUSED…
                            Подготовка конвейера (PREROLL)…
                            Получен контекст из элемента «vaapidecode0»: gst.vaapi.Display=context, display=(GstVaapiDisplay)NULL;
                            Конвейер подготовлен (PREROLLED)…
                            Установка конвейера в состояние PLAYING…
                            New clock: GstSystemClock
                            progressreport0 (00:00:05): 12 / 91 seconds (13,2 %)
                            progressreport0 (00:00:10): 25 / 91 seconds (27,5 %)
                            progressreport0 (00:00:15): 38 / 91 seconds (41,8 %)
                            progressreport0 (00:00:20): 51 / 91 seconds (56,0 %)
                            progressreport0 (00:00:25): 64 / 91 seconds (70,3 %)
                            progressreport0 (00:00:30): 78 / 91 seconds (85,7 %)
                            progressreport0 (00:00:35): 87 / 91 seconds (95,6 %)
                            progressreport0 (00:00:36): 91 / 91 seconds (100,0 %)
                            Получен маркер EOS («конец потока») от элемента «pipeline0».
                            Execution ended after 0:00:36.109251149
                            Установка конвейера в состояние PAUSED…
                            Установка конвейера в состояние READY…
                            Установка конвейера в состояние NULL…
                            Освобождение конвейера…
                            [rz2k@victorique x264]$ mpv --vo=vaapi --hwdec=vaapi --hwdec-codecs=all output.mkv
                            Playing: output.mkv
                            (+) Video --vid=1 (*) 'Video' (h264)
                            File tags:
                            Title: «Ep03\ Creditless\ Opening»
                            libva info: VA-API version 0.38.0
                            libva info: va_getDriverName() returns 0
                            libva info: Trying to open /usr/lib/dri/i965_drv_video.so
                            libva info: Found init function __vaDriverInit_0_38
                            libva info: va_openDriver() returns 0
                            Using hardware decoding.
                            VO: [vaapi] 1920x1088 vaapi
                            V: 00:00:46 / 00:01:31 (50%) Dropped: 1

                            Exiting… (Quit)

                              0
                              У вас похожие артефакты, но гораздо лучше. Спасибо.
                        0
                        Если под аппаратным кодированием понимать только QuickSync — то да, это мусор какой-то.

                        Я у себя для конвертации выстроил ферму на GPGPU и получается, что чистое время конвертации видео в 4 качества (360p, 480p, 720p, 1080p) примерно равно половине продолжительности видео, притом что используется на порядок более дешёвое железо, нежели сервера общего назначения.
                          +1
                          Вы сейчас про какое кодирование на GPU говорите: CUDA или nvenc?
                            +1
                            nvenc
                              –1
                              а как у вас nvenc получился дешевле обычных серверов?

                              Вы какими именно платами пользуетесь?
                                –2
                                дешевыми ;-)
                                  0
                                  Я не знаю, что такое «дешевая» плата с поддержкой nvenc. Вы можете как-то внятно сказать?
                                    +1
                                      +1
                                      это разве не из тех карт, у которых ограничение на 3-4 канала?

                                      Сколько у вас реально каналов на ней обрабатывается?
                                        +1
                                        2 канала там ограничение. по два и обрабатывается, на каждой
                                          0
                                          Вы не пробовали с Quick Sync сравнивать?
                                          Просто тоже присматриваемся к этой технологии
                                          У нас на i5 получается кодировать при помощи Quick Sync порядка 35 потоков
                                          При этом i5 в плане стоимости получается очень либерально
                                            0
                                            Если будет на чём, то попробую, конечно.

                                            У меня есть большие сомнения насчёт эффективности именно транскодинга — на входе большое разнообразие форматов и пытаться использовать аппаратное ускорение для декодирования — занятие неблагодарное. Кроме того, после декодинга ещё нужно деинтерполировать кадр к нужному разрешению, применить фильтры.
                                              0
                                              Скажем так, мы в тестовом режиме сделали модули, которые работают только на GPU. Там есть проблема — если кодировать в системной памяти, то при передачи от декодера к энкодеру имеются затраты на копирование памяти. Так вот мы написали модули, которые используют только внутренние Surface Quick Sync SDK и копируются только указатели. Там есть все необходимое для VPP (resize, colorspace, deinterlace). Таким образом мы разгружаем CPU и можем кодировать софтверно еще несколько качеств/битрейтов. Да и само кодирование работает быстрее (загрузка CPU не более 20%, нет задержек при копировании памяти)
                                                0
                                                Если мне не изменяет память, то при транскодировании FullHD (mpeg2->h264) чисто на GPU (без VPP) получается ~8 потоков. + еще один — два потока удается втиснуть на CPU. Это на i5. На серверном i7 немного другие цифры. На GPU получается те же 8-9, на CPU еще 4 (там процессор мощнее)
                                                  0
                                                  Я не потоками меряю, у меня VOD — мне важнее получить каждый в отдельности как можно быстрее, поэтому для меня вполне приемлемо иметь множество недорогих воркеров. Говорят у Quick Sync качество страдает, но сам я в глаза не видел. На CPU в моём случае ничего не втиснуть — он занят декодированием входящего потока по максимуму.
                                                  0
                                                  вы это делали под линуксом или под виндовсом?

                                                  Там вроде проблемы какие-то были.
                                                0
                                                Да, когда я написал «присматриваемся к этой технологии», я имел ввиду nvenc.
                                                Смущает вот это ограничение в 2 потока
                                                А профессиональная видеокарта стоит дорого (там вроде бы без ограничений)
                                                  0
                                                  Если конвертировать видео из очереди, то это ограничение особо не мешает — как раз хватает процессор делом занять. Если лайвстриминг, то возможно подойдёт Quadro K4200. Но я, правда, не измерял производительность GK104 для этих целей. Надо искать (или ждать) недорогие квадры на GM20*
                                                    0
                                                    А вообще это ограничение, по-моему, вообще искуственное и наложено драйвером, может найдётся кто-то, кто разделается с ним.
                                                      0
                                                      Я смотрел SDK от NV — там же вроде есть decoder CUDA based?
                                                      То есть теоретически можно декодировать на CUDA, а кодировать на nvenc.
                                                      Не смотрели в эту сторону?
                                                        0
                                                        Смотрел — кодеки на входе все разные, ускорять каждый в отдельности трудно. Бывает такое, что приходит исходник ProRes 220 гигабайт — он и скачивается сам по себе долго, и тут уже диск недостаточно быстро читает. Но если решимся делать сервис конвертации дешевле, чем амазон и зенкодер, то, вероятно, применим.
                                                        0
                                                        это абсолютно точно и 100% исключительно искуственное ограничение. В самой дешевой плате стоит точно такой же чип, как и в самой дорогой.

                                                        Какое-то время можно было подправить сам драйвер, потом стало надо перепаивать резисторы.
                                                          0
                                                          Я глубоко не копал, но первое что пришло в голову:
                                                          root@videoconv4:~# ipcs -a
                                                          
                                                          ------ Shared Memory Segments --------
                                                          key        shmid      owner      perms      bytes      nattch     status
                                                          
                                                          ------ Semaphore Arrays --------
                                                          key        semid      owner      perms      nsems
                                                          0x002fa327 0          root       666        2
                                                          
                                                          ------ Message Queues --------
                                                          key        msqid      owner      perms      used-bytes   messages
                                                          

                                                          Может быть там всё сделано наивно и бесхитростно?
                                                            0
                                                            Для production это критично. Как потом продать железку с перепаянным резистором?
                                                            С драйверами такая же проблема.
                                                            А профессиональная железка стоит ровно как комп с i5
                                                            Хотя технология мне нравится
                                                            Есть возможность балансировки между CUDA, nvenc и CPU
                                                            Думаю, попробуем в ближайшее время это в деле хотя бы в тестовых целях
                                                              0
                                                              продать очень просто — в рамках единой железки или программно аппаратного комплекса.

                                                              Вы же не собираетесь продавать сто тысяч штук ферм транскодирования за полгода =)

                                                              В теории, конечно, в 1U можно напихать 4 nvidia, один quicksync (если мать подойдет), т.е. получится что-то под 100 каналов в максимуме.
                                                                +1
                                                                Короче, сделал его посговорчивее. Вот он где проверяет:
                                                                www.dropbox.com/s/btk26v3qdv31bh8/%D0%A1%D0%BA%D1%80%D0%B8%D0%BD%D1%88%D0%BE%D1%82%202015-07-13%2019.59.23.png?dl=0
                                                                и вот где оно в файле:
                                                                www.dropbox.com/s/xfl6oacq44uopat/%D0%A1%D0%BA%D1%80%D0%B8%D0%BD%D1%88%D0%BE%D1%82%202015-07-13%2020.46.13.png?dl=0

                                                                test eax, eax заменяем на вычитание
                                                                jne заменяем двумя nop-ами
                                                                файл /usr/lib/x86_64-linux-gnu/libnvidia-encode.so.1 версия драйвера 346.46

                                                                Только что запустил разом 10 потоков на 1 ролик тестовый — отконвертилось
                                                                  +2
                                                                  внезапно!
                                                        0
                                                        Так вы тратите на одной только плате 10 тыс рублей на канал, а ещё сам компьютер.

                                                        Почему вы посчитали, что это дешево?
                                                          0
                                                          Предложите вашу калькуляцию
                                                            0
                                                            грубо говоря, один сервер с Xeon E3 сможет обработать 10 SD каналов. Его стоимость меньше 100 тыс рублей, т.е. меньше 10 тыс рублей на канал.
                                                              +1
                                                              Пошерудил GDB по libnvidia-encode.so — вроде убрал лимит (подробнее в комменте выше). Завтра потестирую детальнее.
                                                                0
                                                                Спасибо! Очень интересно узнать результат.
                                                                  +3
                                                                  Успешно оттестировал, написал пост.
                                                                    0
                                                                    Оперативно! С удовольствием почитаю.
                                                                      0
                                                                      ага, спасибо
                                        +3
                                        У вас всё смешалось: люди, кони… В смысле в тексте частенько x264, а в тексте командной строки x265. Не всегда до конца понятно, что там с чем сранивается. Четно говоря, из-за этой неразберихи я даже не понял, на скришотах то под h264 имеется в виду кадр из оригинального видео с BD-видео, или пережатый вами с «идеальными» настройками x264?
                                          +1
                                          x264 радует нас множеством готовых пресетов

                                          ссылка:
                                          http://x265.readthedocs.org/en/1.7/cli.html#cmdoption--preset

                                          Чему верить?

                                          И да, сколько не вглядывался, изменения в скриншотах заметил только по последней ссылке.
                                            0
                                            ой… поправил цифры в двух местах и сравнивается везде с x264 и это не «идеальный» конечно вариант, но цель была сравнить именно 264 и 265
                                              +3
                                              Вы кодируете с одинаковым CRF и через x264, и через x265. Я не уверен, что диапазон значений вообще совпадает, и что корректно использовать одинаковое значение в обоих кодировщиках, ожидая, что они дадут одинаковое качество видео. С ходу проверенной информации не нашел.

                                              И, кстати, надеюсь, что в конце сентября покажу уже сервис по распределенному кодированию видео, о концепции которого писал год назад. Сейчас, я считаю, самое время: людям нужно кодировать и в h.265, и в vp8, и в vp9, да еще и 4K-видео вот-вот пойдет потоком, а тот же ZenCoder — один из самых популярных сервисов по кодированию видео ­— возьмет с вас более $2 (!!!) за кодирование 3-минутного видеоролика в 4K в H.265. Мой же сервис будет не только позволять устанавливать все параметры кодирования для любого видеокодека, и использовать встроенные фильтры ffmpeg, но и будет заметно дешевле. Кодирование подобного видео обойдется примерно в 30 центов.
                                                0
                                                crf двух кодеков не совпадает — вы правы.
                                                  0
                                                  Так их никто и не сравнивал :) Во внимание принимался только средний битрейт и размер файла
                                                +5
                                                Статья в ключе «сравнил мкпп феррари с вариатором приуса и уверенно говорю: тесла — фигня».
                                                  0
                                                  У Приуса не вариатор.
                                                  0
                                                  Поделитесь исходным y4m, пожалуйста?
                                                    0
                                                    Только он 128 мб в архиве на 100 кадров…
                                                    yadi.sk/d/TgXowu6rhopun
                                                      +3
                                                      Решил посмотреть, что там с метриками будет, получилось вот так (x264 — синий, x265 — оранжевый).
                                                      yadi.sk/i/pYSlMRTwhorf6

                                                      Смотрел только файлы самого близкого битрейта.
                                                      Понятно, что при включённом psy-rdo значения метрик получаются искажённые. Но общая идея в том, что от кадра к кадру битрейт и качество могут существенно меняться — обычно B-кадры кодируются с меньшим качеством. Примерно с 25 по 40 кадрый «гребёнка» идёт в противофазе, и там особенно легко найти примеры в пользу любого из кодеков, если показывать только один кадр.

                                                      И у вас ещё последовательность достаточно специфичная получилась: компьютерная графика, медленное движение, мелкие детали. Возможно, если что-то из этого менять, расклад тоже будет меняться.

                                                      И, если честно, если не пиксели разглядывать, а фильм смотреть, я бы не заметил разницы. Думаю, что если у обоих кодеков битрейт раза в два-три раза занизить, там уже разница будет заметнее.
                                                    +1
                                                    На маленьких битрейтах x265 все же визуально лучше чем x264. Вот тут сравнивали:
                                                    x265.ru/x264-and-x265-anime-source
                                                      +2
                                                      Итого, мы выяснили, что x264 пережатый в x264 даёт меньшее ухудшение качества, чем x264 пережатый в x265. А должно было быть иначе? :-)
                                                        0
                                                        По теме также советую посмотреть выступление Роберта Рейнхарда — он сравнивает x265 и x264, и в целом рассказывает про все плюсы и минусы.
                                                        В целом, судя по отзывам компетентных людей, x265 ещё долго будет получать распространение, сравнимое с x264.
                                                          +1
                                                          Сравнивать алгоритмы кодирования видео на основании сриншотов?
                                                          По-моему, это все равно, что сравнивать алгоритмы кодирования звука на основании картинок спектрограмм отдельных фреймов.
                                                          Т.е., как минимум, все очень условно. Как максимум бесполезно.

                                                          Во-первых…
                                                          На сколько я помню, большинство алгоритмов кодирования видео работают по принципу опорных (ключевых) кадров, на основе которых формируются промежуточные, т.е. по сути кодируется разница между опорным и последующими N-кадрами.
                                                          Поэтому, мне не понятно, что значит упомянутый параметр «постоянное качество» в настройках.
                                                          Означает ли это, что все кадры в видео последовательности являются ключевыми? И сравниваются именно они.

                                                          Во-вторых…
                                                          Как можно сравнивать бобра с ослом, без сравнения с исходной картинкой (пусть даже и изначально пережатой, о чем упомянули выше).
                                                          Т.е. где разностная картина одного и другого кодека? Хотя бы ради академического интереса.

                                                          Итого…
                                                          это равноценно тому, чтобы выложить аудио файл кодированный двумя разными кодеками и пытаться описывать свои ощущения после их прослушивания, предлагая сделать то же самое читателям статьи.

                                                          Может я очень резок, но в данном ключе напоминает:
                                                          Звук с этим кабелем получается глубоким и прозрачным, воздушным. Сразу заметны и хорошая детальность, и динамика. Очень неплох бас — аккуратный, структурированный и быстрый. Середина и верхние частоты ровные и открытые, без зажатости или резкости. Вообще какой-либо окраски, перекосов тонального баланса не ощущается. звук комфортный и неутомительный. Сцена широкая, глубокая, с точно очерченными образами и хорошо разделенными правильными соразмерно планами. присутствует и слитность, в том плане, что звук не разбирается на части и детальность, но без резкости. Одинаково ровно воспроизводятся разные жанры без каких-то слышимых предпочтений. С эмоциональной подачей также все в полном порядке, что предполагает музыкальное произведение, то и ощущается.


                                                          • UFO just landed and posted this here
                                                            +1
                                                            Уважаемый автор.

                                                            Если вы сравниваете эффективность стандартов кодирования видео, то потрудитесь скачать референсный кодер того и другого стандарта (HM и JM), и пожмите raw видео. Заодно можно построить RD-кривые. В настоящий момент вы сравниваете две реализации от сторонних разработчиков на разных стадиях жизненного цикла.
                                                              +1
                                                              Наверное человеку интересно, что он может получить в реальности сегодня, а не теоретически завтра.
                                                                0
                                                                Интернет завален рекламными хвалебными восторженными отзывами и обзорами, причем обозреватели, в зависимости от наглости безграмотности доверчивости, обещают улучшение сжатия на 30-50% по сравнению с h.264 при том же качестве картинки


                                                                Я считаю, что писать такие вещи про стандарт — это уже за гранью. Есть публикации в серьёзных изданиях, которые подтверждают заявления о 30-50% преимуществе.

                                                                не верю в кодирование видео с помощью CUDA и DXVA и считаю все реализации таких «кодировщиков» чистым шарлатанством


                                                                И всё в таком духе.

                                                                Если интересно узнать, что могут современные реализации — давайте так и писать. К чему столько пафоса и обвинений?
                                                                  0
                                                                  Не поверите, но фраза «современные реализации» даже в заголовок вынесена :)
                                                                0
                                                                Удивительно, но я как раз и пытался сравнить 2 реализации с разным жизненным циклом — просто стало интересно чем физически обосновано заметное увеличение x265 рипов на трекерах
                                                                  0
                                                                  Ок — измерьте, пожалуйста, PSNR для сжатых кадров, и давайте поговорим конкретно. Определение количества «мыла» на глаз зависит от глаза.
                                                                    0
                                                                    :) боевую задачу взял
                                                                    0
                                                                    к сожалению, на трекерах до сих пор выкладывают avi с mpeg4part2

                                                                Only users with full accounts can post comments. Log in, please.