Следующая модель уже крупнее, на ней линейка прекращается, более свежий аналог-флагман от Sharp - только в Японии, более свежие и ещё относительно компактные младшие модели от Sony - только в Японии.
Перебирать параметры для максимизации метрики качества (VMAF). Кодируем кусок, смотрим на VMAF, повторяем с другими настройками (QP в статье netflix)
Повторять для разных разрешений, выбирать куски по разным критериям ("minimizing bitrate for a given average quality or maximizing quality for a given average bitrate")
Первые два пункта реализованы в av1an, а третий вроде бы нужен только видеохостингу.
TL;DR: резать видео на куски - это нормальный подход, который должен хорошо работать в CRF-режимах и который используется для распараллеливания кодирования AV1. Только резать не по ключевым кадрам, а по scenecut'ам, как это делает утилита av1an.
___
Если при кодировании целиться в определённый уровень качества, а не в размер файла (не в средний битрейт), то тогда алгоритмы rate control'а не должны делать ничего важного на длинных промежутках.
Допустим, кодируем по отдельности 2 сцены с разной сложностью по 5 минут каждая.
Хотим получить файл в X мегабайт - придётся сцены кодировать в файлы X/2 мегабайт - битрейт распределяется неоптимально (сложная сцена недополучает, лёгкая - получает избыточный).
Хотим получить X единиц качества (--crf, --cq-level, VMAF) - тогда сцены друг от друга почти не зависят, раздельное кодирование почти никак не вредит.
Примерно поэтому разработчики x264 настаивали на том, что в их энкодере однопроходный CRF-режим - лучший по качеству. 2pass чуть-чуть выигрывает от того, что алгоритмы алгоритмы rate control'а видят весь файл (словно у нас CRF + ‑-rc‑lookahead ∞), но время, затраченное на второй проход, в x264 выгоднее потратить иначе (вместо 2pass выбрать CRF с более медленным пресетом).
Другая часть истории - гугл. Он стал делать кодеки. И эти его кодеки плохо параллелятся на все ядра. Поэтому в AV1 кодирование кусками (chunking) и склеивание - это чуть ли не ожидаемый сценарий использования. Поэтому появилась утилита av1an - она режет видео на куски по scenecut'ам и запускает пул из N штук ffmpeg'ов (ну и делает вид, что её работа гораздо сложнее, чем на самом деле).
___
Разрезание по ключевым кадрам автоматически достигается в ffmpeg через -noaccurate_seek: Previous behavior (seek only to nearest preceding keyframe, despite inaccuracy) can be restored with "-noaccurate_seek" - https://trac.ffmpeg.org/wiki/Seeking
___
Чтобы меньше вредить качеству, режут по переходам между сценами и shot'ами. Дальше можно выбирать наиболее резкие переходы и наложить ограничение на минимальную длину куска. Методы: использовать выхлоп встроенного ффмпеговского scene detector'а или использовать сторонний, как делает av1an.
___
А если мы в месте склейки вылезем за ограничения, которые важны аппаратным декодерам? Если мы заморачивались со всякими --level, --bluray-compat, --vbv-maxrate и хотим сохранить гарантии совместимости? То мы слишком много хотим, то это тонкие материи, наверное, есть платные инструменты для точного контроля совместимости. Нас бы и без склейки мог, например, обломать один из многочисленных багов с упоминанием VBV в истории версий x265.
Самое близкое, что сейчас есть - это Blackview A52, 164x62x9мм.
Если позаглядывать в китайские подвалы, найдётся на треть меньше. Кто-то-китайский "Xiaomi Duoqin" Qin 3 Ultra, 127x62x8.7 мм (@coresky, вот, +2 мм).
Предыдущий Qin 2 ещё меньше, но сильно урезан. Новый, впрочем, тоже с проблемами. Если смотреть на железо, то подвалом не назовёшь: Helio G99 + 8 ГБ оперативки, но всё-таки это малоизвестный китаец вроде вышеупомянутых Unihertz.
Недоступность максимальных ёмкостей и недоступность HAMR - нормальные явления.
Самые новые HDD, видимо, выгоднее сначала обкатывать на бизнесе, потом продавать оптом и только потом пускать в розницу.
Переносами массового производства HAMR Seagate страдает с 2019 года, какие-то у них были проблемы.
Розничный >26 ТБ, с HAMR, вообще говоря, есть, но в только странном виде "Factory Recertified" / "Refurbished by Seagate": ST28000NM000C[1][2]. И соль тут не в лоте на ebay, а в том, что эта линейка дисков (...NM000C, 22-28 ТБ) изначально появилась как "Factory Recertified" и в другом виде не существует.
30 ТБ год назад ждали в розницу, а у 32+ ТБ смертным мешает только HM-SMR.
Смертные могут купить себе WD Gold на 26 ТБ на амазоне (остальные потребительские у WD до 24 ТБ). 24 ТБ, 26 ТБ, 30 ТБ - принципиальной разницы нет, смертным будут давать всё больше и больше.
И двухсторонние Blu-ray на 200 ГБ. Никогда, жёсткие диски в SATA пока не упёрлись, но если вдруг - то PCIe к ним уже примеряли (WD 2014, Seagate 2021).
и Seagate выпустил на бумаге модели ST30TB00000 / ST32TB00000 ("Limited Availability").
Кончилось тем, что вместо них теперь перенаправление на "уже следующие диски".
И раз я это пишу, дополнение насчёт восстановленных дисков. На The HDD Platter Capacity Database есть комментарий с ещё одним аргументом за то, что это именно HAMR-диски.
Текст комментария
July 11, 2024
I know we don't do helium drives here, but I just discovered something worth bringing up.
A few weeks ago, a new 24TB model ST24000NM000C appeared in the wild. What's intriguing is that it has "Class 1 consumer laser product" and a registration model of STL026 on its label[я об этом], which is the same as Exos Xz (aka Mz), the SMR version of the Mozaic 3+ platform. So it appears like we have our first retail version of HAMR drives, though it may have several depoped bad heads as it's far from the full 30TB capacity and is labeled as recertified by Seagate. Nonetheless, I thought to get this bit of information out there in case someone finds it interesting.
Edit: the drive in question should be CMR as indicated by the "SNxx" firmware, and the full capacity model should be ST30000NM002F. No idea why they changed to the C suffix for the 24TB version though.
Но это всё равно онлайн-дедупликация с её негибкостью и оверхедом. Ни к чему не обязывающий оффлайн-дедуп (для которого в ZFS чего-то не хватает[1][2]) лучше, а ZFS'ный то ли создан для очень "горячих" данных, то ли старая архитектурная ошибка (скорее, второе).
Всё ложится на хост (Host-Managed SMR). Нет смысла рассуждать про "серверный" SMR, тут нет людей, работавших с ним*. Все просто по ошибке переносят свои впечатления от Device-Managed SMR, который встречается в дисках до 8 ТБ, "не-серверных".
В серии несколько десятков микросхем, сложно заблудиться.
Может и не 176ИД1, а его "коллега"
Но он в какой-то другой серии, видимо.
Напряжения в 12-15 В - тоже.
Уж не знаю, куда нас уводит разговор, но допустим.
Необходимость беречь микросхему от напряжений выше 15В ведёт нас к паразитной засветке, которая считается допустимой на смещениях погашенных катодов от 60В (у К155ИД1 нам смещение около 60В дают встроенные стабилитроны).
Какая будет засветка на 15В - надо проверять и смотреть, но вот рекомендации лучших собаководов... то есть таблицы объёмов красных резиновых мячей... то есть вся виденная литература на эту тему говорит такие низкие смещения не делать.
Понизить работу выхода. Люминисценция в тлеющем разряде газа возникает <...>
Всё-таки мы говорили о конкретном зелёном люминофоре. Зелёный - это, как известно, четвёртый цвет радуги...
калькуляторы
Они - на 155/133 серии из-за наборов калькуляторной логики в этой серии. Поэтому и "редкость"...
Редкость - те мифические зелёные ГРИ, а не катодный драйвер на (внутренних ключах) микросхемы 176 серии, что, впрочем, тоже выглядит ошибкой или редкостью.
Был вольтметр В7-27 на 133ИД1, например
---
Пусть будет заодно в комментарии:
Апноуты от Burroughs о ключах, смещениях, засветке.
О том, что 176 серия не для газоразрядных индикаторов, в ней нет специальных микросхем, которыми можно было бы напрямую коммутировать ГРИ.
Или то же самое другими словами: в 176 серии нет высоковольтных дешифраторов, если границу "высоковольтности" проводить между ВЛИ и ГРИ. К133ИД1 и К155ИД1 обязаны держать 60 вольт, К176ИД3 - нет.
МРБ 1193
В приборах на управлении индикаторами тлеющего разряда разряда стояли обычные позиционные дешифраторы без открытого стока. 176ИД1 или что-то типа того.
В них стояли созданные для этого К133ИД1 и К155ИД1, с открытым коллектором. Вообще говоря, от безвыходности туда можно поставить что угодно с внешними ключами, но такая безвыходность должна быть редким событием, судя по доступности К155ИД1 (как и с ГРИ, получился неадекватный перекос - плановая экономика запланировала снабдить пользователей из капиталистических стран далёкого будущего).
Индикаторы тлеющего разряда зелёного свечения - были точно. С покрытием на катодах. Маркировку не помню. То ли с лишней буквой, то ли с лишней цифрой.
А я говорю, что точно не было что если и были, то были огромной редкостью, неизвестной современным коллекционерам, что маловероятно. И не видно логики в покрытии именно на катодах.
Если они помнятся как индикаторы с фигурными катодами-цифрами (а не сегментами), то склоняюсь к "точно не было".
Были редкие тиратронные индикаторы с люминофором (как сегментный ИТС1А), но вряд ли люминофор там на катодах.
Реализовал я свою идею с Y'PbPr и сделал палитры с плавным нарастанием Y' от 0 до 255.
4 картинки
1 оборот спирали (начиная с разных углов: 0, 45 ... 315 градусов)
то же самое, но 2 оборота спирали
Y' везде одинаково линейно растёт от 0 до 255, но на красном и фиолетовом слева хорошо видно, что для глаза они по яркости различаются. Всё-таки это несерьёзная самодеятельность, потому что Y' из Y'PbPr - это вам не L* из CIELAB. В готовых палитрах (теперь ссылка на matplotlib) о равномерности больше подумали.
1-й градиент с 1-й картинки на RGB-кубе (спираль вокруг куба, спроецированная на его грани)
Спираль здорового человека (2 оборота и уменьшенный радиус)
Нет, одна из микросхем для ВЛИ, как было без купюр: "176 серия без высоковольтных дешифраторов намекает на ВЛИ", всё-таки совсем не то, что К155ИД1 и К133ИД1.
ИН-18, конечно, ошибся при вводе.
Тогда ещё перемешалось тут: "В ИН-18 без суффиксов люминофора на катоде нет" - ИН-18 есть только без суффиксов.
Остальное - не понял.
"Осыпался люминофор с не прошедшего цикл тренировки катода" - на катодах же нигде нет люминофора. Мы говорим то ли о малоизвестной экзотике наподобие ИТС1А (газоразрядник, сегментный, с люминофором где-то унутре), то ли о затуманенных воспоминаниях.
Что-то совсем всё перемешалось: нет ТН-18 (но есть ИВ-18 и ИН-18), нет люминофора на катодах (во ВЛИ он на анодах, а в ГРИ - точнее, в цветных неонках - на стенках баллона), 176 серия без высоковольтных дешифраторов намекает на ВЛИ, но в них не приходится говорить о напряжении пробоя, они вакуумные и низковольтные.
Ну, не изобрести, а скопировать откуда-нибудь код преобразования HSY->RGB.
Хм, где-то там (то есть там, где откуда-нибудь) у функции полезный комментарий, который вроде как сообщает, что HUSL и LCH решают ту же задачу. А анимация на сайте HUSL по ссылке, кстати, показывает, как решать проблему спиралей под спойлером, то есть как без искажения яркости (Y) "легализовать" значения YUV, вылезающие за пределы куба RGB - проецированием точки на границы сечения куба (сечения Y=const).
Первый нужен, если вдруг энкодер плохо параллелится.
Нужен второй или не нужен, но чтобы взять готовое-открытое-бесплатное решение по ссылке, много сил не надо.
Следующая модель уже крупнее, на ней линейка прекращается, более свежий аналог-флагман от Sharp - только в Японии, более свежие и ещё относительно компактные младшие модели от Sony - только в Японии.
Можно разбить задачу на три части:
Научиться резать, кодировать кусками и склеивать
Перебирать параметры для максимизации метрики качества (VMAF). Кодируем кусок, смотрим на VMAF, повторяем с другими настройками (QP в статье netflix)
Повторять для разных разрешений, выбирать куски по разным критериям ("minimizing bitrate for a given average quality or maximizing quality for a given average bitrate")
Первые два пункта реализованы в av1an, а третий вроде бы нужен только видеохостингу.
Не-не-не, истина
где-то рядомпосередине.TL;DR: резать видео на куски - это нормальный подход, который должен хорошо работать в CRF-режимах и который используется для распараллеливания кодирования AV1. Только резать не по ключевым кадрам, а по scenecut'ам, как это делает утилита av1an.
___
Если при кодировании целиться в определённый уровень качества, а не в размер файла (не в средний битрейт), то тогда алгоритмы rate control'а не должны делать ничего важного на длинных промежутках.
Допустим, кодируем по отдельности 2 сцены с разной сложностью по 5 минут каждая.
Хотим получить файл в X мегабайт - придётся сцены кодировать в файлы X/2 мегабайт - битрейт распределяется неоптимально (сложная сцена недополучает, лёгкая - получает избыточный).
Хотим получить X единиц качества (--crf, --cq-level, VMAF) - тогда сцены друг от друга почти не зависят, раздельное кодирование почти никак не вредит.
Примерно поэтому разработчики x264 настаивали на том, что в их энкодере однопроходный CRF-режим - лучший по качеству. 2pass чуть-чуть выигрывает от того, что алгоритмы алгоритмы rate control'а видят весь файл (словно у нас CRF +
‑-rc‑lookahead ∞), но время, затраченное на второй проход, в x264 выгоднее потратить иначе (вместо 2pass выбрать CRF с более медленным пресетом).Другая часть истории - гугл. Он стал делать кодеки. И эти его кодеки плохо параллелятся на все ядра. Поэтому в AV1 кодирование кусками (chunking) и склеивание - это чуть ли не ожидаемый сценарий использования. Поэтому появилась утилита av1an - она режет видео на куски по scenecut'ам и запускает пул из N штук ffmpeg'ов (ну и делает вид, что её работа гораздо сложнее, чем на самом деле).
___
Разрезание по ключевым кадрам автоматически достигается в ffmpeg через
-noaccurate_seek: Previous behavior (seek only to nearest preceding keyframe, despite inaccuracy) can be restored with "-noaccurate_seek" - https://trac.ffmpeg.org/wiki/Seeking___
Чтобы меньше вредить качеству, режут по переходам между сценами и shot'ами. Дальше можно выбирать наиболее резкие переходы и наложить ограничение на минимальную длину куска. Методы: использовать выхлоп встроенного ффмпеговского scene detector'а или использовать сторонний, как делает av1an.
___
А если мы в месте склейки вылезем за ограничения, которые важны аппаратным декодерам? Если мы заморачивались со всякими --level, --bluray-compat, --vbv-maxrate и хотим сохранить гарантии совместимости?
То мы слишком много хотим, то это тонкие материи, наверное, есть платные инструменты для точного контроля совместимости. Нас бы и без склейки мог, например, обломать один из многочисленных багов с упоминанием VBV в истории версий x265.Если вычеркнуть вариант "не включать дедупликацию", то да.
Если позаглядывать в китайские подвалы, найдётся на треть меньше.
Кто-то-китайский"Xiaomi Duoqin" Qin 3 Ultra, 127x62x8.7 мм (@coresky, вот, +2 мм).Предыдущий Qin 2 ещё меньше, но сильно урезан. Новый, впрочем, тоже с проблемами. Если смотреть на железо, то подвалом не назовёшь: Helio G99 + 8 ГБ оперативки, но всё-таки это малоизвестный китаец вроде вышеупомянутых Unihertz.
Недоступность максимальных ёмкостей и недоступность HAMR - нормальные явления.
Самые новые HDD, видимо, выгоднее сначала обкатывать на бизнесе, потом продавать оптом и только потом пускать в розницу.
Переносами массового производства HAMR Seagate страдает с 2019 года, какие-то у них были проблемы.
Розничный >26 ТБ, с HAMR, вообще говоря, есть, но в только странном виде "Factory Recertified" / "Refurbished by Seagate": ST28000NM000C[1][2]. И соль тут не в лоте на ebay, а в том, что эта линейка дисков (...NM000C, 22-28 ТБ) изначально появилась как "Factory Recertified" и в другом виде не существует.
Эта история тоже давно закончилась.
SSD упёрлись в скорость SATA
*переходный период, поиск решений*
победил вариант: PCIe, поверх него NVMe и как форм-фактор M.2
SATA SSD перестали развивать примерно в 2019, с тех пор только упрощают, удешевляют, выводят из продажи.
Вариант с кабелями назывался SATA Express и быстро проиграл M.2.
Но это не мешает подключать M.2 через переходники, кабели и PCIe-коммутаторы, только теперь вместо кабеля в коробке требуется фантазия пользователя.
30 ТБ год назад ждали в розницу, а у 32+ ТБ смертным мешает только HM-SMR.
Смертные могут купить себе WD Gold на 26 ТБ на амазоне (остальные потребительские у WD до 24 ТБ). 24 ТБ, 26 ТБ, 30 ТБ - принципиальной разницы нет, смертным будут давать всё больше и больше.
И двухсторонние Blu-ray на 200 ГБ. Никогда, жёсткие диски в SATA пока не упёрлись, но если вдруг - то PCIe к ним уже примеряли (WD 2014, Seagate 2021).Кончилось тем, что вместо них теперь перенаправление на "уже следующие диски".
И раз я это пишу, дополнение насчёт восстановленных дисков. На The HDD Platter Capacity Database есть комментарий с ещё одним аргументом за то, что это именно HAMR-диски.
Текст комментария
July 11, 2024
I know we don't do helium drives here, but I just discovered something worth bringing up.
A few weeks ago, a new 24TB model ST24000NM000C appeared in the wild. What's intriguing is that it has "Class 1 consumer laser product" and a registration model of STL026 on its label [я об этом], which is the same as Exos Xz (aka Mz), the SMR version of the Mozaic 3+ platform.
So it appears like we have our first retail version of HAMR drives, though it may have several depoped bad heads as it's far from the full 30TB capacity and is labeled as recertified by Seagate. Nonetheless, I thought to get this bit of information out there in case someone finds it interesting.
Edit: the drive in question should be CMR as indicated by the "SNxx" firmware, and the full capacity model should be ST30000NM002F. No idea why they changed to the C suffix for the 24TB version though.
Но это всё равно онлайн-дедупликация с её негибкостью и оверхедом. Ни к чему не обязывающий оффлайн-дедуп (для которого в ZFS чего-то не хватает[1][2]) лучше, а ZFS'ный то ли создан для очень "горячих" данных, то ли старая архитектурная ошибка (скорее, второе).
Здесь раскрывает, Exos M 32, 36 ТБ - SMR, 30 ТБ - CMR.
В источниках скромнее: "shipping samples".
Всё ложится на хост (Host-Managed SMR). Нет смысла рассуждать про "серверный" SMR, тут нет людей, работавших с ним*. Все просто по ошибке переносят свои впечатления от Device-Managed SMR, который встречается в дисках до 8 ТБ, "не-серверных".
* по крайней мере, они не отмечались.
В серии несколько десятков микросхем, сложно заблудиться.
Но он в какой-то другой серии, видимо.
Уж не знаю, куда нас уводит разговор, но допустим.
Необходимость беречь микросхему от напряжений выше 15В ведёт нас к паразитной засветке, которая считается допустимой на смещениях погашенных катодов от 60В (у К155ИД1 нам смещение около 60В дают встроенные стабилитроны).
Какая будет засветка на 15В - надо проверять и смотреть, но вот рекомендации лучших собаководов... то есть таблицы объёмов красных резиновых мячей... то есть вся виденная литература на эту тему говорит такие низкие смещения не делать.
Всё-таки мы говорили о конкретном зелёном люминофоре.
Зелёный - это, как известно, четвёртый цвет радуги...Редкость - те мифические зелёные ГРИ, а не катодный драйвер на (внутренних ключах) микросхемы 176 серии, что, впрочем, тоже выглядит ошибкой или редкостью.
Был вольтметр В7-27 на 133ИД1, например
---
Пусть будет заодно в комментарии:
Апноуты от Burroughs о ключах, смещениях, засветке.
О том, что 176 серия не для газоразрядных индикаторов, в ней нет специальных микросхем, которыми можно было бы напрямую коммутировать ГРИ.
Или то же самое другими словами: в 176 серии нет высоковольтных дешифраторов, если границу "высоковольтности" проводить между ВЛИ и ГРИ. К133ИД1 и К155ИД1 обязаны держать 60 вольт, К176ИД3 - нет.
В них стояли созданные для этого К133ИД1 и К155ИД1, с открытым коллектором. Вообще говоря, от безвыходности туда можно поставить что угодно с внешними ключами, но такая безвыходность должна быть редким событием, судя по доступности К155ИД1 (как и с ГРИ, получился неадекватный перекос - плановая экономика запланировала снабдить пользователей из капиталистических стран далёкого будущего).
А я говорю,
что точно не былочто если и были, то были огромной редкостью, неизвестной современным коллекционерам, что маловероятно. И не видно логики в покрытии именно на катодах.Если они помнятся как индикаторы с фигурными катодами-цифрами (а не сегментами), то склоняюсь к "точно не было".
Были редкие тиратронные индикаторы с люминофором (как сегментный ИТС1А), но вряд ли люминофор там на катодах.
Были зелёные стекла у приборов.
Чего только не было, но не такого.
Я тоже, у ВЛИ катод прямого накала, это одна проволочка.
Реализовал я свою идею с Y'PbPr и сделал палитры с плавным нарастанием Y' от 0 до 255.
4 картинки
Y' везде одинаково линейно растёт от 0 до 255, но на красном и фиолетовом слева хорошо видно, что для глаза они по яркости различаются. Всё-таки это несерьёзная самодеятельность, потому что Y' из Y'PbPr - это вам не L* из CIELAB. В готовых палитрах (теперь ссылка на matplotlib) о равномерности больше подумали.
Нет, одна из микросхем для ВЛИ, как было без купюр: "176 серия без высоковольтных дешифраторов намекает на ВЛИ", всё-таки совсем не то, что К155ИД1 и К133ИД1.
Тогда ещё перемешалось тут: "В ИН-18 без суффиксов люминофора на катоде нет" - ИН-18 есть только без суффиксов.
"Осыпался люминофор с не прошедшего цикл тренировки катода" - на катодах же нигде нет люминофора. Мы говорим то ли о малоизвестной экзотике наподобие ИТС1А (газоразрядник, сегментный, с люминофором где-то унутре), то ли о затуманенных воспоминаниях.
Что-то совсем всё перемешалось: нет ТН-18 (но есть ИВ-18 и ИН-18), нет люминофора на катодах (во ВЛИ он на анодах, а в ГРИ - точнее, в цветных неонках - на стенках баллона), 176 серия без высоковольтных дешифраторов намекает на ВЛИ, но в них не приходится говорить о напряжении пробоя, они вакуумные и низковольтные.
Хм, где-то там (то есть там, где откуда-нибудь) у функции полезный комментарий, который вроде как сообщает, что HUSL и LCH решают ту же задачу. А анимация на сайте HUSL по ссылке, кстати, показывает, как решать проблему спиралей под спойлером, то есть как без искажения яркости (Y) "легализовать" значения YUV, вылезающие за пределы куба RGB - проецированием точки на границы сечения куба (сечения Y=const).