- комментарий 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 чтобы смотреть на утюгах. Как только чего не переусложнят...