Что: 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-ом. Пока не вижу причин не переходить на него. Весь последний сезон Рика и Морти вот как-раз надо будет перекодировать и там как-раз всем этим кодекам очень не сладко приходилось с этой почти синтетической графикой. ------------------------------------------------------------------------ оставить комментарий: mailto:comment@blog.stargrave.org?subject=Re:%20%D0%9F%D0%BE%D0%B8%D0%B3%D1%80%D0%B0%D0%BB%D1%81%D1%8F%20%D1%81%20AV1%20%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE%D0%BA%D0%BE%D0%B4%D0%B5%D0%BA%D0%BE%D0%BC%20%2807bddb0ed6a5d2276a10cf77b81e22da2d7c69e6%29 ------------------------------------------------------------------------ комментарий 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 *** localhost [2023-03-18 12:59]: >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 *** David Rabkin [2023-04-13 00:30]: >Ты с ней знаком? И что бы ты про нее сказал? Впервые слышу. С ходу ничем не заинтересовала, ибо заточена под аппаратное кодирование. 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 *** David Rabkin [2023-04-13 15:40]: >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 *** David Rabkin [2023-04-13 22:51]: >Что это значит? Ну надо открывать документацию по 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 *** David Rabkin [2023-04-14 01:26]: >Плексу (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 *** David Rabkin [2023-04-14 01:26]: >утюг воспроизводил. А ещё можно разделять то что хранится долговременно и то что вот прям сейчас хочется проиграть. У меня звуковые файлы либо в 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 *** David Rabkin [2023-04-14 22:34]: >Идея — гениальная, свой Нетфликс! Запускаешь сервер со своими медиа >файлами, а потом смотришь и слушаешь на любом устройстве, в любой >точке мира. Ну... можно просто по NFS (поверх VPN, для авторизации и приватности) подмонтировать свой NAS и смотреть из любой точки мира :-). А можно просто по SSH дать команду на real-time перекодирование хоть в AVC, хоть в MPEG4 чтобы смотреть на утюгах. Как только чего не переусложнят... ------------------------------------------------------------------------ Сгенерирован: SGBlog 0.34.0