Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 97
1) Ваш анализ становится неверным после вот этой фразы:
2) В последних сравнениях все не очень однозначно, картинка на x265 не столько более мыльная, сколько на мой взгляд содержит меньшее количество артефактов кодирования. Некоторые фрагменты смотрятся хуже, некоторые — лучше. Но опять же — учитывая изначальную ошибку сравнение некорректно.
Для начала, возьмем в качестве исходника упомянутый выше отрывок из Аватара брызги-дерево-туман и чтобы исключить тормоза декодера, сохраним 100 кадров и из него в виде несжатого YUV4MPEG2 файла, который в дальнейшем и будет кодироваться.Т.е. с самого начала. Вы берете уже пожатый файл и пытаетесь его пережать.
2) В последних сравнениях все не очень однозначно, картинка на x265 не столько более мыльная, сколько на мой взгляд содержит меньшее количество артефактов кодирования. Некоторые фрагменты смотрятся хуже, некоторые — лучше. Но опять же — учитывая изначальную ошибку сравнение некорректно.
Это конечно да, но где взять более качественное тестовое видео как не с блюрей диска?
Попробуйте взять рендеры проекта Blender. 4K, разного уровня насыщенности деталями сцены, отсутствие артефактов сжатия.
Я свои эксперименты по поиску оптимального BPS/resolution делал именно на них. Хотя можно и здесь придраться к тому, что такой тест будет синтетическим.
Я свои эксперименты по поиску оптимального BPS/resolution делал именно на них. Хотя можно и здесь придраться к тому, что такой тест будет синтетическим.
Ищите не пожатый исходник в Apple ProRes, «киношники» часто с ним работают, как с оригиналом. Может примеры какие к Final Cut есть в нормальном качестве. 31 Mb/s это уже сильно пожато. Еще можно самому TIFF sequence наснимать :)
Да… Виноват опять — не догадался с самого начала взять исходником что-то покачественней, а теперь уже лениво и я для себя вывод сделал. Не стоит оно пока 10-ти кратного увеличения времени кодирования. Посмотрим-попробуем что будет через год-полтора.
Так время кодирования — вообще не аргумент. Добавить N часов кодирования для релиза фильма (бюджет измеряется миллионами) чтобы пользователь получил более качественную картинку — вообще не вопрос. Добавить N часов кодирования к сериалу чтобы пользователи могли стримить его на мобильники при более плохом интернете — тоже не проблема, цена подписки окупит. А домашнее видео — оно же вроде все равно пишется изначально пожатым практически любой камерой/фотоаппаратом/телефоном, разве нет?
> Добавить N часов кодирования к сериалу чтобы
Тут как раз не надо так однозначно. Это очень тонкий баланс, который можно нарушить.
Тут как раз не надо так однозначно. Это очень тонкий баланс, который можно нарушить.
Для тестирования енкодеров, нужно использовать сырое исходное видео.
Взять его можно, например, здесь.
Взять его можно, например, здесь.
Там какие то старые sd кадры, не актуально думаю.
Лучше брать здесь: www.arri.com/camera/alexa/learn/alexa_sample_footage
Лучше брать здесь: www.arri.com/camera/alexa/learn/alexa_sample_footage
Только если вы не в курсе, но почти всё видео так и получается.
Доступ до оригинала есть только в телестудии (куда никого не пустят никогда и ни за что) и на IP камерах.
На IP камерах другие ориентиры, а 99% всего видео в интернете — это пережатое откуда-то ещё. Либо скачанное с торрентов, либо рипованное с блюрея, либо стянутое со спутника.
Доступ до оригинала есть только в телестудии (куда никого не пустят никогда и ни за что) и на IP камерах.
На IP камерах другие ориентиры, а 99% всего видео в интернете — это пережатое откуда-то ещё. Либо скачанное с торрентов, либо рипованное с блюрея, либо стянутое со спутника.
И к чему это было сказано? Котик с телефона выложенный на ютуб может быть вообще в любом формате, там разнцу в качестве заметить тяжело будет. А вот возможность стримить качественное видео FullHD используя узкий канал или улучшить качество видео при том же объеме диска — это и есть цель кодека. Пережимать однажды сжатое — это не совсем цель.
к тому, что вы неправильно представляете процесс подготовки видео для раздачи в интернете.
А при чем здесь подготовка к раздаче ворованного контента и котиков на ютубе? h.264 это кодек, который используется в блюреях и для раздачи стримингового кино — т.е. жмется исходник. Так зачем сравнивать непонятно что, если h.265 призван его заменить? Такие статьи всегда весело читать, потому что они сравнивать не пойми что и из этого делают далеко идущие выводы о таких серьезных вещах как новый индустриальный стандарт кодирования видео.
Вы не знакомы с реалиями подготовки и раздачи видео, если вы думаете, что только ворованный контент пережимается.
Доступ к сырому видео из телестудии есть очень у ограниченного числа людей.
Доступ к сырому видео из телестудии есть очень у ограниченного числа людей.
Так какие это реалии? Блюрей что ли готовят из уже пережатого? Стриминговое видео для iTunes, Netflix из уже пережатого готовят? А больше ничего интереса и не представляет в данном контексте.
При чём тут нетфликс, если разговор идет о том, чем пользоваться людям?
Люди нетфликсом и пользуются. Причем очень успешно.
Вы лучше на вопрос ответьте.
Ваш предыдущий комментарий просто смешон: «больше ничего интереса и не представляет».
Опыт нетфликса как раз интересен постольку поскольку, потому что его не повторить.
Во-первых, сырое видео им вряд ли дают. Какие-то ролики могут и приносить, но в целом маловероятно.
Я держу пари, но вы ни разу в жизни даже не видели, как выглядит сырой ролик. Я работаю с видео очень давно и много и видел только один раз. Когда я спросил, не оригинал ли это, меня выгнали из комнаты, а ролик заперли в сейф.
Сырое видео очень мало распространяется и поэтому для интернета интересны прежде всего вопросы пережатия из одних сжатых форматов в другие.
И чего там удобнее для нетфликса для всех остальных должно быть наплевать, потому что это проблема нетфликса.
Опыт нетфликса как раз интересен постольку поскольку, потому что его не повторить.
Во-первых, сырое видео им вряд ли дают. Какие-то ролики могут и приносить, но в целом маловероятно.
Я держу пари, но вы ни разу в жизни даже не видели, как выглядит сырой ролик. Я работаю с видео очень давно и много и видел только один раз. Когда я спросил, не оригинал ли это, меня выгнали из комнаты, а ролик заперли в сейф.
Сырое видео очень мало распространяется и поэтому для интернета интересны прежде всего вопросы пережатия из одних сжатых форматов в другие.
И чего там удобнее для нетфликса для всех остальных должно быть наплевать, потому что это проблема нетфликса.
для начала нужно определиться, что имеется в виду под преимуществами h265 на h264. Дальше ответить на вопрос почему мы выявляем эти преимущества с помощью x265 и корректно ли это.
Пресеты почему-то называются презентами. Дефолтный crf 23 превратился в 28.
Пресеты почему-то называются презентами. Дефолтный crf 23 превратился в 28.
Насчет пресетов точно и спасибо — полчетвертого утра было :) А статья на самом не деле не об h.265, а про современные реализации x265
больше интересует ответ на первую часть комментария)
Я ни минуты не сомневаюсь что у h265 огромные перспективы и со временем все там будем. Но по-моему пока рано — доступные инструменты еще только в самых ранних стадиях разработки, да и вычислительные мощности не поспевают.
поэтому название темы не соответсвует. Легенд и мифов о реализациях я не слышал)
они есть об алгоритме, о generic encoder.
они есть об алгоритме, о generic encoder.
Вычислительные мощности тут не при чем, как таковые. Реализуют кодер/декодер в железе и будет работать для рядового пользователя «на лету», как сейчас некоторые вебки пишут в h264.
Чтобы понять масштаб проблемы и степень моей недоверчивости, отмечу, что я не верю в аппаратное кодирование в h.264/AVC (а точнее уверен, что с той же и скоростью при лучшем качестве может работать и чисто программный x264.exe)
Активно пользуюсь QuickSync'ом, качество у него действительно хуже чем у программного кодирования, но при программном кодировании при самых низких настройках падение фпс в играх — 10-20, а с QuickSync'ом — 0-5. Так что для начинающих стримеров со слабым железом QuickSync подходит идеально.
Какое у вас железо? Если, вдруг, Sandy Bridge, и вам не лень 30 минут поиздеваться над ним, пожалуйста, скачайте любой дистрибутив Linux (последняя Ubuntu подойдет), и скодируйте что-либо через gstreamer vaapi примерно так:
А то у меня на выходе получается просто дрисня какая-то, а баг подтвердить никто не может:
ovrload.ru/f/55938_bake-cbr-3000.mkv
(оригинальный исходник)
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
(оригинальный исходник)
на ivy просто нет декода исходника
при том, другие mkv работают и на энкод и на декод
Скрытый текст
[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)
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)
[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)
А, забыл, он 10-битный. Транскодируйте его как-то так сначала:
ffmpeg -i bake.mkv -map v -c:v libx264 -crf 17 -preset fast -tune animation output.mkvживое rghost.ru/private/85vtCtrmN/1039b0fd8b59090c48b5ff1ba2225298
libva 1.6.0
vaapi-intel 1.6.0
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)
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)
Если под аппаратным кодированием понимать только QuickSync — то да, это мусор какой-то.
Я у себя для конвертации выстроил ферму на GPGPU и получается, что чистое время конвертации видео в 4 качества (360p, 480p, 720p, 1080p) примерно равно половине продолжительности видео, притом что используется на порядок более дешёвое железо, нежели сервера общего назначения.
Я у себя для конвертации выстроил ферму на GPGPU и получается, что чистое время конвертации видео в 4 качества (360p, 480p, 720p, 1080p) примерно равно половине продолжительности видео, притом что используется на порядок более дешёвое железо, нежели сервера общего назначения.
Вы сейчас про какое кодирование на GPU говорите: CUDA или nvenc?
nvenc
а как у вас nvenc получился дешевле обычных серверов?
Вы какими именно платами пользуетесь?
Вы какими именно платами пользуетесь?
дешевыми ;-)
Я не знаю, что такое «дешевая» плата с поддержкой nvenc. Вы можете как-то внятно сказать?
это разве не из тех карт, у которых ограничение на 3-4 канала?
Сколько у вас реально каналов на ней обрабатывается?
Сколько у вас реально каналов на ней обрабатывается?
2 канала там ограничение. по два и обрабатывается, на каждой
Вы не пробовали с Quick Sync сравнивать?
Просто тоже присматриваемся к этой технологии
У нас на i5 получается кодировать при помощи Quick Sync порядка 35 потоков
При этом i5 в плане стоимости получается очень либерально
Просто тоже присматриваемся к этой технологии
У нас на i5 получается кодировать при помощи Quick Sync порядка 35 потоков
При этом i5 в плане стоимости получается очень либерально
Если будет на чём, то попробую, конечно.
У меня есть большие сомнения насчёт эффективности именно транскодинга — на входе большое разнообразие форматов и пытаться использовать аппаратное ускорение для декодирования — занятие неблагодарное. Кроме того, после декодинга ещё нужно деинтерполировать кадр к нужному разрешению, применить фильтры.
У меня есть большие сомнения насчёт эффективности именно транскодинга — на входе большое разнообразие форматов и пытаться использовать аппаратное ускорение для декодирования — занятие неблагодарное. Кроме того, после декодинга ещё нужно деинтерполировать кадр к нужному разрешению, применить фильтры.
Скажем так, мы в тестовом режиме сделали модули, которые работают только на GPU. Там есть проблема — если кодировать в системной памяти, то при передачи от декодера к энкодеру имеются затраты на копирование памяти. Так вот мы написали модули, которые используют только внутренние Surface Quick Sync SDK и копируются только указатели. Там есть все необходимое для VPP (resize, colorspace, deinterlace). Таким образом мы разгружаем CPU и можем кодировать софтверно еще несколько качеств/битрейтов. Да и само кодирование работает быстрее (загрузка CPU не более 20%, нет задержек при копировании памяти)
Если мне не изменяет память, то при транскодировании FullHD (mpeg2->h264) чисто на GPU (без VPP) получается ~8 потоков. + еще один — два потока удается втиснуть на CPU. Это на i5. На серверном i7 немного другие цифры. На GPU получается те же 8-9, на CPU еще 4 (там процессор мощнее)
Я не потоками меряю, у меня VOD — мне важнее получить каждый в отдельности как можно быстрее, поэтому для меня вполне приемлемо иметь множество недорогих воркеров. Говорят у Quick Sync качество страдает, но сам я в глаза не видел. На CPU в моём случае ничего не втиснуть — он занят декодированием входящего потока по максимуму.
вы это делали под линуксом или под виндовсом?
Там вроде проблемы какие-то были.
Там вроде проблемы какие-то были.
Да, когда я написал «присматриваемся к этой технологии», я имел ввиду nvenc.
Смущает вот это ограничение в 2 потока
А профессиональная видеокарта стоит дорого (там вроде бы без ограничений)
Смущает вот это ограничение в 2 потока
А профессиональная видеокарта стоит дорого (там вроде бы без ограничений)
Если конвертировать видео из очереди, то это ограничение особо не мешает — как раз хватает процессор делом занять. Если лайвстриминг, то возможно подойдёт Quadro K4200. Но я, правда, не измерял производительность GK104 для этих целей. Надо искать (или ждать) недорогие квадры на GM20*
А вообще это ограничение, по-моему, вообще искуственное и наложено драйвером, может найдётся кто-то, кто разделается с ним.
Я смотрел SDK от NV — там же вроде есть decoder CUDA based?
То есть теоретически можно декодировать на CUDA, а кодировать на nvenc.
Не смотрели в эту сторону?
То есть теоретически можно декодировать на CUDA, а кодировать на nvenc.
Не смотрели в эту сторону?
Смотрел — кодеки на входе все разные, ускорять каждый в отдельности трудно. Бывает такое, что приходит исходник ProRes 220 гигабайт — он и скачивается сам по себе долго, и тут уже диск недостаточно быстро читает. Но если решимся делать сервис конвертации дешевле, чем амазон и зенкодер, то, вероятно, применим.
это абсолютно точно и 100% исключительно искуственное ограничение. В самой дешевой плате стоит точно такой же чип, как и в самой дорогой.
Какое-то время можно было подправить сам драйвер, потом стало надо перепаивать резисторы.
Какое-то время можно было подправить сам драйвер, потом стало надо перепаивать резисторы.
Я глубоко не копал, но первое что пришло в голову:
Может быть там всё сделано наивно и бесхитростно?
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
Может быть там всё сделано наивно и бесхитростно?
Для production это критично. Как потом продать железку с перепаянным резистором?
С драйверами такая же проблема.
А профессиональная железка стоит ровно как комп с i5
Хотя технология мне нравится
Есть возможность балансировки между CUDA, nvenc и CPU
Думаю, попробуем в ближайшее время это в деле хотя бы в тестовых целях
С драйверами такая же проблема.
А профессиональная железка стоит ровно как комп с i5
Хотя технология мне нравится
Есть возможность балансировки между CUDA, nvenc и CPU
Думаю, попробуем в ближайшее время это в деле хотя бы в тестовых целях
продать очень просто — в рамках единой железки или программно аппаратного комплекса.
Вы же не собираетесь продавать сто тысяч штук ферм транскодирования за полгода =)
В теории, конечно, в 1U можно напихать 4 nvidia, один quicksync (если мать подойдет), т.е. получится что-то под 100 каналов в максимуме.
Вы же не собираетесь продавать сто тысяч штук ферм транскодирования за полгода =)
В теории, конечно, в 1U можно напихать 4 nvidia, один quicksync (если мать подойдет), т.е. получится что-то под 100 каналов в максимуме.
Короче, сделал его посговорчивее. Вот он где проверяет:
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 ролик тестовый — отконвертилось
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 ролик тестовый — отконвертилось
Так вы тратите на одной только плате 10 тыс рублей на канал, а ещё сам компьютер.
Почему вы посчитали, что это дешево?
Почему вы посчитали, что это дешево?
Предложите вашу калькуляцию
грубо говоря, один сервер с Xeon E3 сможет обработать 10 SD каналов. Его стоимость меньше 100 тыс рублей, т.е. меньше 10 тыс рублей на канал.
Пошерудил GDB по libnvidia-encode.so — вроде убрал лимит (подробнее в комменте выше). Завтра потестирую детальнее.
Спасибо! Очень интересно узнать результат.
Успешно оттестировал, написал пост.
У вас всё смешалось: люди, кони… В смысле в тексте частенько x264, а в тексте командной строки x265. Не всегда до конца понятно, что там с чем сранивается. Четно говоря, из-за этой неразберихи я даже не понял, на скришотах то под h264 имеется в виду кадр из оригинального видео с BD-видео, или пережатый вами с «идеальными» настройками x264?
x264 радует нас множеством готовых пресетов
ссылка:
http://x265.readthedocs.org/en/1.7/cli.html#cmdoption--preset
Чему верить?
И да, сколько не вглядывался, изменения в скриншотах заметил только по последней ссылке.
ой… поправил цифры в двух местах и сравнивается везде с x264 и это не «идеальный» конечно вариант, но цель была сравнить именно 264 и 265
Вы кодируете с одинаковым CRF и через x264, и через x265. Я не уверен, что диапазон значений вообще совпадает, и что корректно использовать одинаковое значение в обоих кодировщиках, ожидая, что они дадут одинаковое качество видео. С ходу проверенной информации не нашел.
И, кстати, надеюсь, что в конце сентября покажу уже сервис по распределенному кодированию видео, о концепции которого писал год назад. Сейчас, я считаю, самое время: людям нужно кодировать и в h.265, и в vp8, и в vp9, да еще и 4K-видео вот-вот пойдет потоком, а тот же ZenCoder — один из самых популярных сервисов по кодированию видео — возьмет с вас более $2 (!!!) за кодирование 3-минутного видеоролика в 4K в H.265. Мой же сервис будет не только позволять устанавливать все параметры кодирования для любого видеокодека, и использовать встроенные фильтры ffmpeg, но и будет заметно дешевле. Кодирование подобного видео обойдется примерно в 30 центов.
И, кстати, надеюсь, что в конце сентября покажу уже сервис по распределенному кодированию видео, о концепции которого писал год назад. Сейчас, я считаю, самое время: людям нужно кодировать и в h.265, и в vp8, и в vp9, да еще и 4K-видео вот-вот пойдет потоком, а тот же ZenCoder — один из самых популярных сервисов по кодированию видео — возьмет с вас более $2 (!!!) за кодирование 3-минутного видеоролика в 4K в H.265. Мой же сервис будет не только позволять устанавливать все параметры кодирования для любого видеокодека, и использовать встроенные фильтры ffmpeg, но и будет заметно дешевле. Кодирование подобного видео обойдется примерно в 30 центов.
Статья в ключе «сравнил мкпп феррари с вариатором приуса и уверенно говорю: тесла — фигня».
Поделитесь исходным y4m, пожалуйста?
Решил посмотреть, что там с метриками будет, получилось вот так (x264 — синий, x265 — оранжевый).
yadi.sk/i/pYSlMRTwhorf6
Смотрел только файлы самого близкого битрейта.
Понятно, что при включённом psy-rdo значения метрик получаются искажённые. Но общая идея в том, что от кадра к кадру битрейт и качество могут существенно меняться — обычно B-кадры кодируются с меньшим качеством. Примерно с 25 по 40 кадрый «гребёнка» идёт в противофазе, и там особенно легко найти примеры в пользу любого из кодеков, если показывать только один кадр.
И у вас ещё последовательность достаточно специфичная получилась: компьютерная графика, медленное движение, мелкие детали. Возможно, если что-то из этого менять, расклад тоже будет меняться.
И, если честно, если не пиксели разглядывать, а фильм смотреть, я бы не заметил разницы. Думаю, что если у обоих кодеков битрейт раза в два-три раза занизить, там уже разница будет заметнее.
yadi.sk/i/pYSlMRTwhorf6
Смотрел только файлы самого близкого битрейта.
Понятно, что при включённом psy-rdo значения метрик получаются искажённые. Но общая идея в том, что от кадра к кадру битрейт и качество могут существенно меняться — обычно B-кадры кодируются с меньшим качеством. Примерно с 25 по 40 кадрый «гребёнка» идёт в противофазе, и там особенно легко найти примеры в пользу любого из кодеков, если показывать только один кадр.
И у вас ещё последовательность достаточно специфичная получилась: компьютерная графика, медленное движение, мелкие детали. Возможно, если что-то из этого менять, расклад тоже будет меняться.
И, если честно, если не пиксели разглядывать, а фильм смотреть, я бы не заметил разницы. Думаю, что если у обоих кодеков битрейт раза в два-три раза занизить, там уже разница будет заметнее.
На маленьких битрейтах x265 все же визуально лучше чем x264. Вот тут сравнивали:
x265.ru/x264-and-x265-anime-source
x265.ru/x264-and-x265-anime-source
Итого, мы выяснили, что x264 пережатый в x264 даёт меньшее ухудшение качества, чем x264 пережатый в x265. А должно было быть иначе? :-)
По теме также советую посмотреть выступление Роберта Рейнхарда — он сравнивает x265 и x264, и в целом рассказывает про все плюсы и минусы.
В целом, судя по отзывам компетентных людей, x265 ещё долго будет получать распространение, сравнимое с x264.
В целом, судя по отзывам компетентных людей, x265 ещё долго будет получать распространение, сравнимое с x264.
Сравнивать алгоритмы кодирования видео на основании сриншотов?
По-моему, это все равно, что сравнивать алгоритмы кодирования звука на основании картинок спектрограмм отдельных фреймов.
Т.е., как минимум, все очень условно. Как максимум бесполезно.
Во-первых…
На сколько я помню, большинство алгоритмов кодирования видео работают по принципу опорных (ключевых) кадров, на основе которых формируются промежуточные, т.е. по сути кодируется разница между опорным и последующими N-кадрами.
Поэтому, мне не понятно, что значит упомянутый параметр «постоянное качество» в настройках.
Означает ли это, что все кадры в видео последовательности являются ключевыми? И сравниваются именно они.
Во-вторых…
Как можно сравнивать бобра с ослом, без сравнения с исходной картинкой (пусть даже и изначально пережатой, о чем упомянули выше).
Т.е. где разностная картина одного и другого кодека? Хотя бы ради академического интереса.
Итого…
это равноценно тому, чтобы выложить аудио файл кодированный двумя разными кодеками и пытаться описывать свои ощущения после их прослушивания, предлагая сделать то же самое читателям статьи.
Может я очень резок, но в данном ключе напоминает:
По-моему, это все равно, что сравнивать алгоритмы кодирования звука на основании картинок спектрограмм отдельных фреймов.
Т.е., как минимум, все очень условно. Как максимум бесполезно.
Во-первых…
На сколько я помню, большинство алгоритмов кодирования видео работают по принципу опорных (ключевых) кадров, на основе которых формируются промежуточные, т.е. по сути кодируется разница между опорным и последующими N-кадрами.
Поэтому, мне не понятно, что значит упомянутый параметр «постоянное качество» в настройках.
Означает ли это, что все кадры в видео последовательности являются ключевыми? И сравниваются именно они.
Во-вторых…
Как можно сравнивать бобра с ослом, без сравнения с исходной картинкой (пусть даже и изначально пережатой, о чем упомянули выше).
Т.е. где разностная картина одного и другого кодека? Хотя бы ради академического интереса.
Итого…
это равноценно тому, чтобы выложить аудио файл кодированный двумя разными кодеками и пытаться описывать свои ощущения после их прослушивания, предлагая сделать то же самое читателям статьи.
Может я очень резок, но в данном ключе напоминает:
Звук с этим кабелем получается глубоким и прозрачным, воздушным. Сразу заметны и хорошая детальность, и динамика. Очень неплох бас — аккуратный, структурированный и быстрый. Середина и верхние частоты ровные и открытые, без зажатости или резкости. Вообще какой-либо окраски, перекосов тонального баланса не ощущается. звук комфортный и неутомительный. Сцена широкая, глубокая, с точно очерченными образами и хорошо разделенными правильными соразмерно планами. присутствует и слитность, в том плане, что звук не разбирается на части и детальность, но без резкости. Одинаково ровно воспроизводятся разные жанры без каких-то слышимых предпочтений. С эмоциональной подачей также все в полном порядке, что предполагает музыкальное произведение, то и ощущается.
Уважаемый автор.
Если вы сравниваете эффективность стандартов кодирования видео, то потрудитесь скачать референсный кодер того и другого стандарта (HM и JM), и пожмите raw видео. Заодно можно построить RD-кривые. В настоящий момент вы сравниваете две реализации от сторонних разработчиков на разных стадиях жизненного цикла.
Если вы сравниваете эффективность стандартов кодирования видео, то потрудитесь скачать референсный кодер того и другого стандарта (HM и JM), и пожмите raw видео. Заодно можно построить RD-кривые. В настоящий момент вы сравниваете две реализации от сторонних разработчиков на разных стадиях жизненного цикла.
Наверное человеку интересно, что он может получить в реальности сегодня, а не теоретически завтра.
Интернет завален рекламными хвалебными восторженными отзывами и обзорами, причем обозреватели, в зависимости от наглости безграмотности доверчивости, обещают улучшение сжатия на 30-50% по сравнению с h.264 при том же качестве картинки
Я считаю, что писать такие вещи про стандарт — это уже за гранью. Есть публикации в серьёзных изданиях, которые подтверждают заявления о 30-50% преимуществе.
не верю в кодирование видео с помощью CUDA и DXVA и считаю все реализации таких «кодировщиков» чистым шарлатанством
И всё в таком духе.
Если интересно узнать, что могут современные реализации — давайте так и писать. К чему столько пафоса и обвинений?
Удивительно, но я как раз и пытался сравнить 2 реализации с разным жизненным циклом — просто стало интересно чем физически обосновано заметное увеличение x265 рипов на трекерах
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Легенды и мифы современных реализаций x265/HEVC или x264 vs x265 в сравнении скриншотов