Удивительно, но факт — стандарту сжатия видео High Efficiency Video Coding (HEVC) уже более трех лет. Существуют не только программные, но и аппаратные решения для кодирования и даже бытовые медиаплееры с поддержкой этого формата. Интернет завален
Чтобы понять масштаб проблемы и степень моей недоверчивости, отмечу, что я не верю в аппаратное кодирование в 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"
Будем работать на повышение бирейта путем понижения показателя качества и смотреть результаты.
Попытка #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"
И стоил ли результат этих жертв? не уверен…
Итак попытка #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 выглядит поприличнее.
Выводы делайте сами, а я с надеждой жду объективной критики :)
Комментарии (97)
zelenin
11.07.2015 09:58+1для начала нужно определиться, что имеется в виду под преимуществами h265 на h264. Дальше ответить на вопрос почему мы выявляем эти преимущества с помощью x265 и корректно ли это.
Пресеты почему-то называются презентами. Дефолтный crf 23 превратился в 28.
7313 Автор
11.07.2015 10:09-1Насчет пресетов точно и спасибо — полчетвертого утра было :) А статья на самом не деле не об h.265, а про современные реализации x265
zelenin
11.07.2015 10:10больше интересует ответ на первую часть комментария)
7313 Автор
11.07.2015 10:15-1Я ни минуты не сомневаюсь что у h265 огромные перспективы и со временем все там будем. Но по-моему пока рано — доступные инструменты еще только в самых ранних стадиях разработки, да и вычислительные мощности не поспевают.
zelenin
11.07.2015 10:17поэтому название темы не соответсвует. Легенд и мифов о реализациях я не слышал)
они есть об алгоритме, о generic encoder.
VenomBlood
11.07.2015 10:22+1Вычислительные мощности тут не при чем, как таковые. Реализуют кодер/декодер в железе и будет работать для рядового пользователя «на лету», как сейчас некоторые вебки пишут в h264.
7313 Автор
11.07.2015 10:37+1Теоретически уже и то и то есть — AL1200 и Sigma SMP8756. Последний надеюсь пощупать как только новые дюны начнут продавать.
portable
11.07.2015 12:55+2Чтобы понять масштаб проблемы и степень моей недоверчивости, отмечу, что я не верю в аппаратное кодирование в h.264/AVC (а точнее уверен, что с той же и скоростью при лучшем качестве может работать и чисто программный x264.exe)
Активно пользуюсь QuickSync'ом, качество у него действительно хуже чем у программного кодирования, но при программном кодировании при самых низких настройках падение фпс в играх — 10-20, а с QuickSync'ом — 0-5. Так что для начинающих стримеров со слабым железом QuickSync подходит идеально.
ValdikSS
11.07.2015 16:55+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
(оригинальный исходник)
RZK333
11.07.2015 18:18на 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)ValdikSS
11.07.2015 18:22А, забыл, он 10-битный. Транскодируйте его как-то так сначала:
ffmpeg -i bake.mkv -map v -c:v libx264 -crf 17 -preset fast -tune animation output.mkvRZK333
11.07.2015 19:57живое 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)
YourChief
12.07.2015 00:04Если под аппаратным кодированием понимать только QuickSync — то да, это мусор какой-то.
Я у себя для конвертации выстроил ферму на GPGPU и получается, что чистое время конвертации видео в 4 качества (360p, 480p, 720p, 1080p) примерно равно половине продолжительности видео, притом что используется на порядок более дешёвое железо, нежели сервера общего назначения.erlyvideo
12.07.2015 13:40+1Вы сейчас про какое кодирование на GPU говорите: CUDA или nvenc?
YourChief
12.07.2015 14:38+1nvenc
erlyvideo
12.07.2015 23:37-1а как у вас nvenc получился дешевле обычных серверов?
Вы какими именно платами пользуетесь?YourChief
13.07.2015 01:13-2дешевыми ;-)
erlyvideo
13.07.2015 09:12Я не знаю, что такое «дешевая» плата с поддержкой nvenc. Вы можете как-то внятно сказать?
YourChief
13.07.2015 09:53+1erlyvideo
13.07.2015 14:28+1это разве не из тех карт, у которых ограничение на 3-4 канала?
Сколько у вас реально каналов на ней обрабатывается?YourChief
13.07.2015 14:32+12 канала там ограничение. по два и обрабатывается, на каждой
xaoc80
13.07.2015 15:02Вы не пробовали с Quick Sync сравнивать?
Просто тоже присматриваемся к этой технологии
У нас на i5 получается кодировать при помощи Quick Sync порядка 35 потоков
При этом i5 в плане стоимости получается очень либеральноYourChief
13.07.2015 15:35Если будет на чём, то попробую, конечно.
У меня есть большие сомнения насчёт эффективности именно транскодинга — на входе большое разнообразие форматов и пытаться использовать аппаратное ускорение для декодирования — занятие неблагодарное. Кроме того, после декодинга ещё нужно деинтерполировать кадр к нужному разрешению, применить фильтры.xaoc80
13.07.2015 16:35Скажем так, мы в тестовом режиме сделали модули, которые работают только на GPU. Там есть проблема — если кодировать в системной памяти, то при передачи от декодера к энкодеру имеются затраты на копирование памяти. Так вот мы написали модули, которые используют только внутренние Surface Quick Sync SDK и копируются только указатели. Там есть все необходимое для VPP (resize, colorspace, deinterlace). Таким образом мы разгружаем CPU и можем кодировать софтверно еще несколько качеств/битрейтов. Да и само кодирование работает быстрее (загрузка CPU не более 20%, нет задержек при копировании памяти)
xaoc80
13.07.2015 16:39Если мне не изменяет память, то при транскодировании FullHD (mpeg2->h264) чисто на GPU (без VPP) получается ~8 потоков. + еще один — два потока удается втиснуть на CPU. Это на i5. На серверном i7 немного другие цифры. На GPU получается те же 8-9, на CPU еще 4 (там процессор мощнее)
YourChief
13.07.2015 16:45Я не потоками меряю, у меня VOD — мне важнее получить каждый в отдельности как можно быстрее, поэтому для меня вполне приемлемо иметь множество недорогих воркеров. Говорят у Quick Sync качество страдает, но сам я в глаза не видел. На CPU в моём случае ничего не втиснуть — он занят декодированием входящего потока по максимуму.
erlyvideo
13.07.2015 17:31вы это делали под линуксом или под виндовсом?
Там вроде проблемы какие-то были.
xaoc80
13.07.2015 16:41Да, когда я написал «присматриваемся к этой технологии», я имел ввиду nvenc.
Смущает вот это ограничение в 2 потока
А профессиональная видеокарта стоит дорого (там вроде бы без ограничений)YourChief
13.07.2015 16:51Если конвертировать видео из очереди, то это ограничение особо не мешает — как раз хватает процессор делом занять. Если лайвстриминг, то возможно подойдёт Quadro K4200. Но я, правда, не измерял производительность GK104 для этих целей. Надо искать (или ждать) недорогие квадры на GM20*
YourChief
13.07.2015 16:52А вообще это ограничение, по-моему, вообще искуственное и наложено драйвером, может найдётся кто-то, кто разделается с ним.
xaoc80
13.07.2015 16:59Я смотрел SDK от NV — там же вроде есть decoder CUDA based?
То есть теоретически можно декодировать на CUDA, а кодировать на nvenc.
Не смотрели в эту сторону?YourChief
13.07.2015 17:21Смотрел — кодеки на входе все разные, ускорять каждый в отдельности трудно. Бывает такое, что приходит исходник ProRes 220 гигабайт — он и скачивается сам по себе долго, и тут уже диск недостаточно быстро читает. Но если решимся делать сервис конвертации дешевле, чем амазон и зенкодер, то, вероятно, применим.
erlyvideo
13.07.2015 17:32это абсолютно точно и 100% исключительно искуственное ограничение. В самой дешевой плате стоит точно такой же чип, как и в самой дорогой.
Какое-то время можно было подправить сам драйвер, потом стало надо перепаивать резисторы.YourChief
13.07.2015 17:42Я глубоко не копал, но первое что пришло в голову:
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
Может быть там всё сделано наивно и бесхитростно?
xaoc80
13.07.2015 17:43Для production это критично. Как потом продать железку с перепаянным резистором?
С драйверами такая же проблема.
А профессиональная железка стоит ровно как комп с i5
Хотя технология мне нравится
Есть возможность балансировки между CUDA, nvenc и CPU
Думаю, попробуем в ближайшее время это в деле хотя бы в тестовых целяхerlyvideo
13.07.2015 17:54продать очень просто — в рамках единой железки или программно аппаратного комплекса.
Вы же не собираетесь продавать сто тысяч штук ферм транскодирования за полгода =)
В теории, конечно, в 1U можно напихать 4 nvidia, один quicksync (если мать подойдет), т.е. получится что-то под 100 каналов в максимуме.
YourChief
13.07.2015 21:01+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 ролик тестовый — отконвертилось
erlyvideo
13.07.2015 15:25Так вы тратите на одной только плате 10 тыс рублей на канал, а ещё сам компьютер.
Почему вы посчитали, что это дешево?YourChief
13.07.2015 15:36Предложите вашу калькуляцию
erlyvideo
13.07.2015 17:55грубо говоря, один сервер с Xeon E3 сможет обработать 10 SD каналов. Его стоимость меньше 100 тыс рублей, т.е. меньше 10 тыс рублей на канал.
YourChief
13.07.2015 21:04+1Пошерудил GDB по libnvidia-encode.so — вроде убрал лимит (подробнее в комменте выше). Завтра потестирую детальнее.
ToSHiC
11.07.2015 12:55+3У вас всё смешалось: люди, кони… В смысле в тексте частенько x264, а в тексте командной строки x265. Не всегда до конца понятно, что там с чем сранивается. Четно говоря, из-за этой неразберихи я даже не понял, на скришотах то под h264 имеется в виду кадр из оригинального видео с BD-видео, или пережатый вами с «идеальными» настройками x264?
Mingun
11.07.2015 13:00+1x264 радует нас множеством готовых пресетов
ссылка:
http://x265.readthedocs.org/en/1.7/cli.html#cmdoption--preset
Чему верить?
И да, сколько не вглядывался, изменения в скриншотах заметил только по последней ссылке.
7313 Автор
11.07.2015 14:18ой… поправил цифры в двух местах и сравнивается везде с x264 и это не «идеальный» конечно вариант, но цель была сравнить именно 264 и 265
ValdikSS
11.07.2015 17:13+3Вы кодируете с одинаковым CRF и через x264, и через x265. Я не уверен, что диапазон значений вообще совпадает, и что корректно использовать одинаковое значение в обоих кодировщиках, ожидая, что они дадут одинаковое качество видео. С ходу проверенной информации не нашел.
И, кстати, надеюсь, что в конце сентября покажу уже сервис по распределенному кодированию видео, о концепции которого писал год назад. Сейчас, я считаю, самое время: людям нужно кодировать и в h.265, и в vp8, и в vp9, да еще и 4K-видео вот-вот пойдет потоком, а тот же ZenCoder — один из самых популярных сервисов по кодированию видео — возьмет с вас более $2 (!!!) за кодирование 3-минутного видеоролика в 4K в H.265. Мой же сервис будет не только позволять устанавливать все параметры кодирования для любого видеокодека, и использовать встроенные фильтры ffmpeg, но и будет заметно дешевле. Кодирование подобного видео обойдется примерно в 30 центов.
XaLBa
11.07.2015 21:23Поделитесь исходным y4m, пожалуйста?
7313 Автор
11.07.2015 21:58Только он 128 мб в архиве на 100 кадров…
yadi.sk/d/TgXowu6rhopunXaLBa
11.07.2015 22:50+3Решил посмотреть, что там с метриками будет, получилось вот так (x264 — синий, x265 — оранжевый).
yadi.sk/i/pYSlMRTwhorf6
Смотрел только файлы самого близкого битрейта.
Понятно, что при включённом psy-rdo значения метрик получаются искажённые. Но общая идея в том, что от кадра к кадру битрейт и качество могут существенно меняться — обычно B-кадры кодируются с меньшим качеством. Примерно с 25 по 40 кадрый «гребёнка» идёт в противофазе, и там особенно легко найти примеры в пользу любого из кодеков, если показывать только один кадр.
И у вас ещё последовательность достаточно специфичная получилась: компьютерная графика, медленное движение, мелкие детали. Возможно, если что-то из этого менять, расклад тоже будет меняться.
И, если честно, если не пиксели разглядывать, а фильм смотреть, я бы не заметил разницы. Думаю, что если у обоих кодеков битрейт раза в два-три раза занизить, там уже разница будет заметнее.
Turbo
12.07.2015 09:41+1На маленьких битрейтах x265 все же визуально лучше чем x264. Вот тут сравнивали:
x265.ru/x264-and-x265-anime-source
vintage
12.07.2015 13:48+2Итого, мы выяснили, что x264 пережатый в x264 даёт меньшее ухудшение качества, чем x264 пережатый в x265. А должно было быть иначе? :-)
Aquary
12.07.2015 14:52По теме также советую посмотреть выступление Роберта Рейнхарда — он сравнивает x265 и x264, и в целом рассказывает про все плюсы и минусы.
В целом, судя по отзывам компетентных людей, x265 ещё долго будет получать распространение, сравнимое с x264.
macik_spb
13.07.2015 00:03+1Сравнивать алгоритмы кодирования видео на основании сриншотов?
По-моему, это все равно, что сравнивать алгоритмы кодирования звука на основании картинок спектрограмм отдельных фреймов.
Т.е., как минимум, все очень условно. Как максимум бесполезно.
Во-первых…
На сколько я помню, большинство алгоритмов кодирования видео работают по принципу опорных (ключевых) кадров, на основе которых формируются промежуточные, т.е. по сути кодируется разница между опорным и последующими N-кадрами.
Поэтому, мне не понятно, что значит упомянутый параметр «постоянное качество» в настройках.
Означает ли это, что все кадры в видео последовательности являются ключевыми? И сравниваются именно они.
Во-вторых…
Как можно сравнивать бобра с ослом, без сравнения с исходной картинкой (пусть даже и изначально пережатой, о чем упомянули выше).
Т.е. где разностная картина одного и другого кодека? Хотя бы ради академического интереса.
Итого…
это равноценно тому, чтобы выложить аудио файл кодированный двумя разными кодеками и пытаться описывать свои ощущения после их прослушивания, предлагая сделать то же самое читателям статьи.
Может я очень резок, но в данном ключе напоминает:
Звук с этим кабелем получается глубоким и прозрачным, воздушным. Сразу заметны и хорошая детальность, и динамика. Очень неплох бас — аккуратный, структурированный и быстрый. Середина и верхние частоты ровные и открытые, без зажатости или резкости. Вообще какой-либо окраски, перекосов тонального баланса не ощущается. звук комфортный и неутомительный. Сцена широкая, глубокая, с точно очерченными образами и хорошо разделенными правильными соразмерно планами. присутствует и слитность, в том плане, что звук не разбирается на части и детальность, но без резкости. Одинаково ровно воспроизводятся разные жанры без каких-то слышимых предпочтений. С эмоциональной подачей также все в полном порядке, что предполагает музыкальное произведение, то и ощущается.
Aclz
14.07.2015 12:30Присоединяюсь к предыдущему оратору. Нужно больше синтетики в тесте, результат тоже должен быть оцифрован. Ламповость и вуальные дымки всё равно не померять, да и у каждого они всё равно свои.
RomanArzumanyan
14.07.2015 14:16+1Уважаемый автор.
Если вы сравниваете эффективность стандартов кодирования видео, то потрудитесь скачать референсный кодер того и другого стандарта (HM и JM), и пожмите raw видео. Заодно можно построить RD-кривые. В настоящий момент вы сравниваете две реализации от сторонних разработчиков на разных стадиях жизненного цикла.erlyvideo
14.07.2015 14:45+1Наверное человеку интересно, что он может получить в реальности сегодня, а не теоретически завтра.
RomanArzumanyan
14.07.2015 14:51Интернет завален рекламными хвалебными восторженными отзывами и обзорами, причем обозреватели, в зависимости от наглости безграмотности доверчивости, обещают улучшение сжатия на 30-50% по сравнению с h.264 при том же качестве картинки
Я считаю, что писать такие вещи про стандарт — это уже за гранью. Есть публикации в серьёзных изданиях, которые подтверждают заявления о 30-50% преимуществе.
не верю в кодирование видео с помощью CUDA и DXVA и считаю все реализации таких «кодировщиков» чистым шарлатанством
И всё в таком духе.
Если интересно узнать, что могут современные реализации — давайте так и писать. К чему столько пафоса и обвинений?7313 Автор
14.07.2015 15:03Не поверите, но фраза «современные реализации» даже в заголовок вынесена :)
7313 Автор
14.07.2015 14:49Удивительно, но я как раз и пытался сравнить 2 реализации с разным жизненным циклом — просто стало интересно чем физически обосновано заметное увеличение x265 рипов на трекерах
RomanArzumanyan
14.07.2015 14:56Ок — измерьте, пожалуйста, PSNR для сжатых кадров, и давайте поговорим конкретно. Определение количества «мыла» на глаз зависит от глаза.
VenomBlood
1) Ваш анализ становится неверным после вот этой фразы:
Т.е. с самого начала. Вы берете уже пожатый файл и пытаетесь его пережать.2) В последних сравнениях все не очень однозначно, картинка на x265 не столько более мыльная, сколько на мой взгляд содержит меньшее количество артефактов кодирования. Некоторые фрагменты смотрятся хуже, некоторые — лучше. Но опять же — учитывая изначальную ошибку сравнение некорректно.
7313 Автор
Это конечно да, но где взять более качественное тестовое видео как не с блюрей диска?
SleepingLion
Попробуйте взять рендеры проекта Blender. 4K, разного уровня насыщенности деталями сцены, отсутствие артефактов сжатия.
Я свои эксперименты по поиску оптимального BPS/resolution делал именно на них. Хотя можно и здесь придраться к тому, что такой тест будет синтетическим.
Dolios
Ищите не пожатый исходник в Apple ProRes, «киношники» часто с ним работают, как с оригиналом. Может примеры какие к Final Cut есть в нормальном качестве. 31 Mb/s это уже сильно пожато. Еще можно самому TIFF sequence наснимать :)
7313 Автор
Да… Виноват опять — не догадался с самого начала взять исходником что-то покачественней, а теперь уже лениво и я для себя вывод сделал. Не стоит оно пока 10-ти кратного увеличения времени кодирования. Посмотрим-попробуем что будет через год-полтора.
VenomBlood
Так время кодирования — вообще не аргумент. Добавить N часов кодирования для релиза фильма (бюджет измеряется миллионами) чтобы пользователь получил более качественную картинку — вообще не вопрос. Добавить N часов кодирования к сериалу чтобы пользователи могли стримить его на мобильники при более плохом интернете — тоже не проблема, цена подписки окупит. А домашнее видео — оно же вроде все равно пишется изначально пожатым практически любой камерой/фотоаппаратом/телефоном, разве нет?
erlyvideo
> Добавить N часов кодирования к сериалу чтобы
Тут как раз не надо так однозначно. Это очень тонкий баланс, который можно нарушить.
VenomBlood
С чего не однозначно? На съемку уходит денег и времени в разы больше.
erlyvideo
Вы исходите из того неверного предположения, что готовят для раздачи те же люди, которые и снимают.
VenomBlood
Т.е. Amazon, например, чтобы стримить видео покупает blu ray диск с фильмом/сериалом, пережимает его и стримит? Серьезно?
erlyvideo
Амазон. Стримить?
Разговор идет о том, чем пользоваться обычному OTT оператору. Единицы в самом топе типа нетфликса особого интереса не представляют, поскольку при их масштабах их опыт не повторяется.
VenomBlood
Amazon Instant Video, да, стримит видео.
mkarev
Для тестирования енкодеров, нужно использовать сырое исходное видео.
Взять его можно, например, здесь.
lifestar
Там какие то старые sd кадры, не актуально думаю.
Лучше брать здесь: www.arri.com/camera/alexa/learn/alexa_sample_footage
mkarev
Гляньте еще раз, там есть и 2К
Интел свой квик синк H265 в том числе на этих стримах тестирует.
erlyvideo
Только если вы не в курсе, но почти всё видео так и получается.
Доступ до оригинала есть только в телестудии (куда никого не пустят никогда и ни за что) и на IP камерах.
На IP камерах другие ориентиры, а 99% всего видео в интернете — это пережатое откуда-то ещё. Либо скачанное с торрентов, либо рипованное с блюрея, либо стянутое со спутника.
VenomBlood
И к чему это было сказано? Котик с телефона выложенный на ютуб может быть вообще в любом формате, там разнцу в качестве заметить тяжело будет. А вот возможность стримить качественное видео FullHD используя узкий канал или улучшить качество видео при том же объеме диска — это и есть цель кодека. Пережимать однажды сжатое — это не совсем цель.
erlyvideo
к тому, что вы неправильно представляете процесс подготовки видео для раздачи в интернете.
creker
А при чем здесь подготовка к раздаче ворованного контента и котиков на ютубе? h.264 это кодек, который используется в блюреях и для раздачи стримингового кино — т.е. жмется исходник. Так зачем сравнивать непонятно что, если h.265 призван его заменить? Такие статьи всегда весело читать, потому что они сравнивать не пойми что и из этого делают далеко идущие выводы о таких серьезных вещах как новый индустриальный стандарт кодирования видео.
erlyvideo
Вы не знакомы с реалиями подготовки и раздачи видео, если вы думаете, что только ворованный контент пережимается.
Доступ к сырому видео из телестудии есть очень у ограниченного числа людей.
creker
Так какие это реалии? Блюрей что ли готовят из уже пережатого? Стриминговое видео для iTunes, Netflix из уже пережатого готовят? А больше ничего интереса и не представляет в данном контексте.
erlyvideo
При чём тут нетфликс, если разговор идет о том, чем пользоваться людям?
VenomBlood
Люди нетфликсом и пользуются. Причем очень успешно.
creker
Вы лучше на вопрос ответьте.
erlyvideo
Ваш предыдущий комментарий просто смешон: «больше ничего интереса и не представляет».
Опыт нетфликса как раз интересен постольку поскольку, потому что его не повторить.
Во-первых, сырое видео им вряд ли дают. Какие-то ролики могут и приносить, но в целом маловероятно.
Я держу пари, но вы ни разу в жизни даже не видели, как выглядит сырой ролик. Я работаю с видео очень давно и много и видел только один раз. Когда я спросил, не оригинал ли это, меня выгнали из комнаты, а ролик заперли в сейф.
Сырое видео очень мало распространяется и поэтому для интернета интересны прежде всего вопросы пережатия из одних сжатых форматов в другие.
И чего там удобнее для нетфликса для всех остальных должно быть наплевать, потому что это проблема нетфликса.
lifestar
Работаешь с видео давно, а оперируешь странными терминами))
Что ещё за сырое видео? Больше похоже на исходники-равчики, нежели на готовый продукт.
Может речь про мастер-копию?
А вообще да, конечно стриминговое видео для iTunes, Netflix и прочих готовят из уже пережатого материала и это ок