Поигрался с AV1 видеокодеком

Что: 07bddb0ed6a5d2276a10cf77b81e22da2d7c69e6

Когда: 2023-01-13 08:11:36+03:00

Темы: multimedia

Поигрался с AV1 видеокодеком

https://netflixtechblog.com/svt-av1-an-open-source-av1-encoder-and-decoder-ad295d9b5ca2
https://gitlab.com/AOMediaCodec/SVT-AV1
https://code.videolan.org/videolan/dav1d
Ибо говорили что конкретно этот кодировщик настолько быстр, что
сопоставим с HEVC-ом становится. Ну что ж, попробовал. Сразу же упал, на
попытке кодирования screencast-а, на том, что кодировщик поддерживает
только 4:2:0, никаких 4:4:4. Дальше прямо в примере запуска --help
указывается что CRF режим можно использовать в несколько проходов, но...
меня тоже сразу же послали что они только для VBR режима.

Сравнил с VP9 закодированным эпизодом Рика и Морти (960x540 8bpp),
который делался в жирных медленных настройках, в два прохода с CRF=24, а
это где-то полтора-два часа на 22мин эпизод. В AV1 указал такой же CRF
(шкала у них одинаковая) и по умолчанию preset=10, который кодировал со
скоростью на порядок выше чем real-time проигрывание. Плюс
распараллелился на все ядра. Размер файла вышел побольше, качество
чуть-чуть похуже, но это если всматриваться, не кардинально.

Попробовал закодировать с preset=2. Это уже не всегда параллелилось на
все ядра, скорость была где-то 3.5 FPS, но это всё равно существенно
быстрее чем я пробовал с libaom, в котором у меня фильм бы месяц
кодировался. Жрёт под два гигабайта памяти.

В итоге: примерно за то же время кодирования, с куда боль��ими
возможностями по распараллеливанию, я получаю на 8% меньшего размера
файл с ощутимо лучшим качеством картинки (почти не увидел ни одного
артефакта вглядывась). В принципе, наверное несколько десятков процентов
лучшего качества (или меньшего bitrate) действительно есть. SVT-AV1 прям
делает этот кодек полностью юзабельным даже для real-time кодирования с
отличным качеством. Прежде я думал что AV1 годен только с аппаратным
ускорением.

Декодирую я его используя VideoLAN-овский dav1d. Ни в SVT-AV1, ни в
dav1d никаких Rust-ов, всё без проблем собирается, интегрируется с
FFmpeg-ом.

Пока не вижу причин не переходить на него. Весь последний сезон Рика и
Морти вот как-раз надо будет перекодировать и там как-раз всем этим
кодекам очень не сладко приходилось с этой почти синтетической графикой.

оставить комментарий

комментарий 0:

From: localhost
Date: 2023-03-18 09:59:32Z

Кстати, раз AV1 на данный момент отличный кодек, а что скажете о
будущем x266 (aka AVC вроде). И что по поводу аудио кодеков, нет ли
чего лучше vorbis'а и opus?

комментарий 1:

From: Sergey Matveev
Date: 2023-03-18 10:20:21Z


>x266 (aka AVC вроде)

VVC. AVC это H.264.
Про него достаточен один факт: патентами всё обмазано и требуются
отчисления. Так было конечно и с MPEG-ами и H.26x всеми, но именно
поэтому Google начала внедрять (покупая конечно и сторонние компании)
VP8, потом развивать VP9 -- чтобы не платить отчислений, которые,
насколько слышал, огромны (особенно для таких поставщиков контента).
Аналогично и Netflix, которая тоже стала колоссальным поставщиком
контента, VP9 начала давно использовать. И все остальные компании,
увидев тот факт, что не только коммитеты с кучей патентов и требующих
из-за этого лицензионных отчислений, могут делать отличные, или, как
минимум, competitive кодеки, причём за даром, решили поддержать развитие
свободных кодеков и дальше. AV1 поддерживают и делают в AOMedia: Amazon,
Apple, ARM, Cisco, Facebook, Google, Huawei, Intel, Microsoft, Mozilla,
Netflix, Nvidia, Samsung Electronics, и т.д.. Кстати удивлён был увидеть
тут Apple. JPEG2000, который мне всем больше нравился чем JPEG -- не
взлетел из-за патентов/отчислений. Нет, он конечно во всех паспортах, во
всех кинотеатрах, много где ещё -- где с JPEG архаичностью и его
DCT-природой мириться нельзя, но в Интернете его не увидеть. H.265 не то
чтобы не взлетел, но используется нишево. С HEIC аналогичная история.
Гиганты ИТ выбрали путь открытых и свободных от отчислений кодеков и
форматов как де-факто уже давно. Поэтому VVC я думаю только нишево тоже
будет применяться. Какие-нибудь новые BluRay и DVB, где только
MPEG-based решения применяются.

Даже если бы эти свободные кодеки и технически отставали бы от
MPEG-аналогов, то они всё равно стоят использования. Theora конечно не
сравнится с качественным MPEG4 ASP (XviD). VP8 конечно не сравнится с
хорошим AVC. Но разница не существенная, не кардинальная, как правило. А
вот VP9 уже показал что может быть очень достоен.

>И что по поводу аудио кодеков, нет ли чего лучше vorbis'а и opus?

Opus настолько хорош, причём как в hi-fidelity, так и low bitrate
задачах, что на него прям даже ярые проприетарщики в своих решениях все
перешли. Вроде бы в новостях я что-то слышал про какой-то кодек
основанный на нейросетях, обучении, ИИ и чём-то таком, который в разы
меньшие битрейты выдавал, но не слышал о каком-либо распространении на
практике.

комментарий 2:

From: David Rabkin
Date: 2023-04-12 21:32:03Z

Я пользуюсь вот такой тулзой:
 https://github.com/donmelton/other_video_transcoding

Ты с ней знаком? И что бы ты про нее сказал?

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

комментарий 3:

From: Sergey Matveev
Date: 2023-04-13 08:14:00Z


>Ты с ней знаком? И что бы ты про нее сказал?

Впервые слышу. С ходу ничем не заинтересовала, ибо заточена под
аппаратное кодирование. mpv/ffmpeg официально где-то у себя в
документации, в общем случае, не рекомендуют аппаратно ускоренные
решения, ибо может пострадать качество. Наверное это вопрос в том,
что именно делает аппаратная реализация, какую часть работ. Если
это ускорение просто некоторых инструкций/алгоритмов, где нет
никакого принятия решений, то наверное почему бы и нет. Но есть и
совсем высокоуровневые, которые чуть ли не полностью готовый кадр
могут отдать. По опыту в ivi, все они заведомо ощутимо проигрывают
по качеству добротным software реализациям. Они хороши для так себе
качества, для того чтобы дикое количество загружаемых видео кодировать
на YouTube, для real-time решений, но не для очень хороших
высококачественных (с битрейтом поменьше) решений. Найти что конкретно
"ускоряется" в том или ином аппаратном решении, чтобы понять будет ли
подпорчено качество или нет -- попробуй ещё найди.

Плюс в README этой утилиты особый упор на HEVC и EAC3 -- проприетарные
кодеки, в которые я никогда и не кодировал бы.

Ничего против не имею, но лично мне бы ничем не пригодилась, поэтому
ничего и не могу сказать.

Меня тоже бесило что зачастую нужно десятки опций было передать при
кодировании того или иного материала, чтобы получить отличный результат.
Но в современных реализациях и кодеках, благо, как минимум, есть
возможность указания не bitrate, а просто желаемого качества картинки
постоянного. В итоге я и в VP8, и VP9, и в AV1 уже перестал париться и
просто использую всё что у них по умолчанию, задавая желаемое качество и
скорость кодирования. Сейчас почти для всего в AV1 использую банальные
опции для FFmpeg, как указаны в документации:
    ffmpeg ... -codec:v libsvtav1 -crf 24 -preset 3
        -svtav1-params tune=0 -g 120 -pix_fmt yuv420p10le
Для не столь важного видео применяю -crf 32, ну и подправляю -g (размер
GOP-а в кадрах) в зависимости от FPS-а. Больше вообще ничего не трогаю.

комментарий 4:

From: David Rabkin
Date: 2023-04-13 12:41:59Z

Там кодирование и софтверное, и хардверное. Я так понимаю, утилита
выбирает оптимальные параметры для ffmpeg, исходя из источника. Don
Melton почти десять лет этим занимается, вот его предыдущий проект:
 https://github.com/donmelton/video_transcoding

До этого скрипты какие-то были. Чувак, кстати, стоял у истоков Safari,
сейчас на пенсии, свой видеоархив кодирует.

комментарий 5:

From: Sergey Matveev
Date: 2023-04-13 13:07:46Z


>https://github.com/donmelton/video_transcoding

Понятно. Ну, опять же, лично мне такое не подошло бы. У него, судя по
README, всё отталкивается от bitrate-а. Он для целевого bitrate
старается делать максимальное качество, выставляя CRF=1 и ограничивая
bitrate сверху. Имеет право на жизнь конечно же, кому то это удобнее. Но
для кучи материала это означало бы избыточно хорошее качество и
потребление bitrate. Мне не нравится сам факт того, что CRF по сути на
выходе не является постоянным: для каких-то сцен целевого bitrate хватит
для достижения чересчур избыточного CRF=1, а для каких-то может не
хватить так, что даже в README он отмечает о возможных проблемах с
качеством. Для каких-нибудь Симпсонов или записей лекций -- большой
bitrate был бы тратой места впустую. У разных людей разные потребности и
хотелки. Этот инструмент явно не универсален. А для универсальности,
видимо, надо собственно просто напрямую использовать FFmpeg например.

комментарий 6:

From: David Rabkin
Date: 2023-04-13 19:53:17Z

Ну, вот, прямо сейчас на FreeBSD other_video_transcoding произвела и
запустила команду, кодирует:
ffmpeg -loglevel error -stats -i ../wip/video.mp4 -map 0:0 -c:v
libx264 -b:v 6000k -maxrate:v 20000k -bufsize:v 20000k -mbtree:v 0
-profile:v high -color_primaries:v bt709 -color_trc:v bt709
-colorspace:v bt709 -metadata:s:v title\= -disposition:v default -map
0:1 -c:a:0 copy -metadata:s:a:0 title\= -disposition:a:0 default -sn
-metadata:g title\= -default_mode passthrough video.mkv

Что это значит?

комментарий 7:

From: Sergey Matveev
Date: 2023-04-13 20:01:24Z


>Что это значит?

Ну надо открывать документацию по FFmpeg, секретов то тут нет никаких.
Всё что касается bt709 colorspace-а можно выкинуть -- это и так по
умолчанию цветовое пространство на большинстве контента (не HDR, не WCG).
-map 0:0 говорит что просто возьми видео трэк один. Bitrate в 6Mbps, как
он в README и пишет, но с burst-ами до 20. Кодируется в AVC (H.264) --
что, по моему, после 15+ лет то существования уже не стоит делать, ибо
более современные кодеки есть. Выставляет пустые title-ы в метаинформации.

Короче, по сути то просто запускает x264 кодирование, выставив два
значения bitrate-а (номинальный и burst), используя его "high" профиль.
Что он значит? Надо идти в его документацию. Насколько помню, то это
просто достаточно активно жрать CPU, стараться делать хорошо. Вот,
собственно и всё.

комментарий 8:

From: David Rabkin
Date: 2023-04-13 22:27:51Z

>Ну надо открывать документацию по FFmpeg, секретов то тут нет никаких.
В этом весь смысл, пусть Дон Мелтон открывает. Тебе спасибо за комментарии.

Мое использование похоже на автора задумку. Я кодирую блюреи во что-то
поменьше, плюс, скаченное невесть откуда видео, с Ютуба как правило.
Мультипликация, типа Симпсона, Парка, Рика, Морти не входит в мои
интересы. Конвертированное видео скармливаю Плексу (plex.tv), я не
помню, как ты к нему относишься. Я им заплатил за пожизненную лицензию
несколько лет назад. Аудио файлы тоже там. Доволен. Такое воркфлоу
покрывает на сто процентов мои запросы на видео и аудио. Плекс хорош.

>после 15+ лет то существования уже не стоит делать
А вот это, может быть из-за хардверных ускорений. А также, чтобы любой
утюг воспроизводил.

комментарий 9:

From: Sergey Matveev
Date: 2023-04-14 05:54:50Z


>Плексу (plex.tv), я не помню

Понятия не имею что это :-). Насколько вижу, что то проприетарное.

>А вот это, может быть из-за хардверных ускорений. А также, чтобы любой
>утюг воспроизводил.

По моему, всему должен быть разумный предел. С одной стороны хорошо чтобы
утюги это воспроизводили. Но именно поэтому до сих пор куча фильмов
пиратами кодируется в MPEG4 (даже не AVC!). Безумие. Это как
использовать MP3, на фоне того, что имеются кодеки которые в 2-3 раза
лучше сжимают. Ведь всё это lossy сжатие же для экономии места. Согласен
что 20-30% лучшего сжатия приятны (которые даст например HEVC), но не
столь весомы. Но 2-3 раза лучше, как это например мог бы сделать AV1 vs
AVC -- уже кардинально по другому. Перекодировал я тут недавно Final
Fantasy: Spirits Within в 1080p с качеством таким, что, даже имея
оригинальную (20-30Mbps) картинку, разницу даже под лупой фиг увидишь. И
вот у него bitrate в куче сцен менее 1Mbps, а в активных ну до 3Mbps
может доходить. То есть это точно в три раза лучше жмёт (и качественнее,
из-за константного CRF!) чем com/donmelton/video_transcoding. Для меня
это уже достаточно большой перевес чтобы задуматься "так ли мне нужна
совместимость с утюгом?". Ведь через n-лет всё равно все утюги смогут и
AV1 проигрывать.

Аппаратное ускорение конечно приятно, не поспоришь. Но в домашних
условиях, когда вряд ли куда спешишь, никакого real-time ну нужно, то
можно и программные реализации подождать. В разумных пределах конечно, а
то оригинальный encoder AV1 кодировал фильмы бы месяц -- это не вариант
конечно уже.

комментарий 10:

From: Sergey Matveev
Date: 2023-04-14 06:26:21Z


>утюг воспроизводил.

А ещё можно разделять то что хранится долговременно и то что вот прям
сейчас хочется проиграть. У меня звуковые файлы либо в Opus, либо в
WavPack (либо Vorbis или MP3, если лучшего источника не находил), но
прямо перед засовыванием в MP3-плеер (ну да, до сих пор такие
существуют, которые ничего новее не поддерживают) я перекодирую в MP3.
Качество будет хуже, но кто это заметит в *MP3* плеере? Аналогично и с
видео. Локально хранится одно, но если надо посмотреть с родителями на
их ТВ, который умеет AVC с флешек проигрывать, то можно, перед записью
на флешку, перекодировать в какой-нибудь 50Mbps AVC и незначительным
использованием CPU, чтобы во много раз быстрее чем real-time всё
перекодировалось. Из-за огромного bitrate качество будет всё равно
отличным. Занимать будет дофига, но какая разница, если это временный
файл для единичного просмотра? Когда мой прошлый ноутбук не мог 1080p
HEVC декодировать в real-time, то я его перегонял в MPEG2 вообще с дико
высоким bitrate-ом во временный файл.

комментарий 11:

From: David Rabkin
Date: 2023-04-14 19:35:53Z

>Понятия не имею что это :-). Насколько вижу, что то проприетарное.
Скажем так, не до конца свободное, типа Red Hat, где я работаю :-)
Идея — гениальная, свой Нетфликс! Запускаешь сервер со своими медиа
файлами, а потом смотришь и слушаешь на любом устройстве, в любой
точке мира. И не надо ничего перекодировать «для родителей». Кстати,
есть более другие свободные решения, Kodi, например.

>Ведь через n-лет всё равно все утюги смогут и
>AV1 проигрывать.
Вообще, не обязательно. Столько этих кодеков.

>Аппаратное ускорение конечно приятно
Я даже не уверен, что оно используется в приведенном примере. Я
ожидал, что это можно видеть в параметрах ffmpeg. FreeBSD бежит на
Dell воркстейшн, года так 2012-ого, без внешней видео карты.

>Но в домашних
>условиях, когда вряд ли куда спешишь, никакого real-time ну нужно, то
>можно и программные реализации подождать.
Полностью согласен.

комментарий 12:

From: Sergey Matveev
Date: 2023-04-14 19:41:00Z


>Идея — гениальная, свой Нетфликс! Запускаешь сервер со своими медиа
>файлами, а потом смотришь и слушаешь на любом устройстве, в любой
>точке мира.

Ну... можно просто по NFS (поверх VPN, для авторизации и приватности)
подмонтировать свой NAS и смотреть из любой точки мира :-). А можно
просто по SSH дать команду на real-time перекодирование хоть в AVC, хоть
в MPEG4 чтобы смотреть на утюгах. Как только чего не переусложнят...

Сгенерирован: SGBlog 0.34.0