В два раза, на МКС 240 кВт (и Внешний Источник Тени, который уменьшил это число в 2 раза в вашем комменте)
Там стоит говно мамонта с 30 Вт/кг.
Японцы что-то себе считают исходя из 1800 Вт/кг, вообще говорят о 500-4300 Вт/кг. Это 100-1000 кг на 500 кВт. Кто-то пишет о 2200 Вт/кг как о реальном товаре.
А вот если сплошные "проверить бит -- установить бит", то на асме, как по мне, даже лучше оказаться в плане читаемости может
Стопудово.. Я иногда скучаю о асмовских командах установки/тестирования битов. Особенно на портах ввода/вывода
Вы серьёзно? Они при желании доступны через inline-ассемблер, его (или версию на C) можно завернуть в макрос, можно в функцию, можно заменить функцией или макросом из HAL-библиотеки к железке или самостоятельно написать такую (некого Аскольда Волкова интернет не помнит, а его макросы помнит).
Вряд ли. Там шаблонные скобки не возвращали вручную, их штук 50 в статье. Их не хватает только в unordered_set и в 2 случаях из 3 их можно опустить, полагаясь на вывод типов.
Там ещё вёрстка кода поехала. На его сайте статья висит исправленная (unordered_set<string>) и дополненная (I wanted Lines read as lines) и всё равно с ошибками (в скобках:{...)).
Хм, на godbolt.org нет ни одного компилятора, который бы запустил код. У msvc есть поддержка нужной фичи (__cpp_lib_containers_ranges), но в тамошней версии нет поддержки модулей и ещё from_range-конструктор unordered_set'а не берёт istream_iterator в качестве аргумента (старый компилятор или ошибка у Страуструпа - не знаю).
Для защиты прихожан от чужаков есть простой линусовский жест: "*YOU* are full of bullshit. $LangName is a horrible language". Но это не иноверцы, два креста носящие, Rust в ядро приглашён. Линус проблемы мягко обрисовывает как конфликт поколений: есть у них "old-time kernel developers", которые Rust не знают и знать не хотят (а когда закончатся - вступайте в наследство).
К тому же в этот раз могут надавить государство и корпорации. В старой истории с C++ у них интереса не было, а сейчас ОАО "Красная шляпа" и прочие могут напомнить, на чьей земле монастырь стоит.
У меня Ryzen 7800x3D, а до этого у меня был 5 1500x. Разницы нет вообще
Для какой-то видеокарты и каких-то предпочтений в играх - вполне может быть, но обобщения как в начале ветки из этого опасно делать.
Ryzen 5 1500X не лучше i7-7700, слабее последних народных зионов (там есть 6-8 более быстрых ядер, на уровне Zen+), слабее приставочных процессоров (8 ядер на уровне десктопных Zen+).
В приставках стоят процессоры в 2+ раза мощнее. Их производители что-то знают.
Игры любят 6-8 максимально быстрых ядер (и одноядерную производительность любят больше, чем переход от 6 к 8) с поправкой на то, что можно упереться в видеокарту. Видеокарта вообще важнее, но
не настолько, чтобы ставить к 4090+ процессор второй свежести
Воистину. У techpowerup есть диаграммы на тему скорости запуска игр, где два PCIe Gen5 SSD (выделены цветом), 970 EVO Plus и прочие вплоть до SATA QLC.
Может чуть подождали бы и стандарт сразу был бы лучше, уровня IP v6, без проблем с дефицитом IP адресов.
Оффтоп: если бы они сделали стандарт уровня IPv6, то его бы сейчас внедрили примерно наполовину. Да и в проблеме дефицита адресов большая часть вины на IPv6, ИМХО. Знали бы, чем обернётся принятие IPv6, смотрели бы в сторону RFC 1385 и т.д.
Следующая модель уже крупнее, на ней линейка прекращается, более свежий аналог-флагман от 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 ТБ - принципиальной разницы нет, смертным будут давать всё больше и больше.
В два раза, на МКС 240 кВт (и Внешний Источник Тени, который уменьшил это число в 2 раза в вашем комменте)
Там стоит говно мамонта с 30 Вт/кг.
Японцы что-то себе считают исходя из 1800 Вт/кг, вообще говорят о 500-4300 Вт/кг. Это 100-1000 кг на 500 кВт. Кто-то пишет о 2200 Вт/кг как о реальном товаре.
Вы серьёзно? Они при желании доступны через inline-ассемблер, его (или версию на C) можно завернуть в макрос, можно в функцию, можно заменить функцией или макросом из HAL-библиотеки к железке или самостоятельно написать такую (некого Аскольда Волкова интернет не помнит, а его макросы помнит).
Вряд ли. Там шаблонные скобки не возвращали вручную, их штук 50 в статье. Их не хватает только в unordered_set и в 2 случаях из 3 их можно опустить, полагаясь на вывод типов.
Там ещё вёрстка кода поехала. На его сайте статья висит исправленная (
unordered_set<string>) и дополненная (I wanted Lines read as lines) и всё равно с ошибками (в скобках:{...)).https://stroustrup.com/21st-Century-C++.pdf
Хм, на godbolt.org нет ни одного компилятора, который бы запустил код. У msvc есть поддержка нужной фичи (
__cpp_lib_containers_ranges), но в тамошней версии нет поддержки модулей и ещё from_range-конструктор unordered_set'а не берёт istream_iterator в качестве аргумента (старый компилятор или ошибка у Страуструпа - не знаю).Для защиты прихожан от чужаков есть простой линусовский жест: "*YOU* are full of bullshit. $LangName is a horrible language". Но это не иноверцы, два креста носящие, Rust в ядро приглашён. Линус проблемы мягко обрисовывает как конфликт поколений: есть у них "old-time kernel developers", которые Rust не знают и знать не хотят (
а когда закончатся - вступайте в наследство).К тому же в этот раз могут надавить государство и корпорации. В старой истории с C++ у них интереса не было, а сейчас ОАО "Красная шляпа" и прочие могут напомнить, на чьей земле монастырь стоит.
А еще иногда бывает, что смотришь на звук, а видишь телевизор. Иногда даже два.
15.625 кГц - строчная частота PAL
15.73426 кГц - NTSC
Для какой-то видеокарты и каких-то предпочтений в играх - вполне может быть, но обобщения как в начале ветки из этого опасно делать.
Ryzen 5 1500X не лучше i7-7700, слабее последних народных зионов (там есть 6-8 более быстрых ядер, на уровне Zen+), слабее приставочных процессоров (8 ядер на уровне десктопных Zen+).
В приставках стоят процессоры в 2+ раза мощнее. Их производители что-то знают.
Игры любят 6-8 максимально быстрых ядер (и одноядерную производительность любят больше, чем переход от 6 к 8) с поправкой на то, что можно упереться в видеокарту. Видеокарта вообще важнее, но
не настолько, чтобы ставить к 4090+ процессор второй свежести
Воистину. У techpowerup есть диаграммы на тему скорости запуска игр, где два PCIe Gen5 SSD (выделены цветом), 970 EVO Plus и прочие вплоть до SATA QLC.
Оффтоп: если бы они сделали стандарт уровня IPv6, то его бы сейчас внедрили примерно наполовину. Да и в проблеме дефицита адресов большая часть вины на IPv6, ИМХО. Знали бы, чем обернётся принятие IPv6, смотрели бы в сторону RFC 1385 и т.д.
Ниже вон про него вспомнили как про более человечный интерфейс к CRIU.
Считайте, что я этого не говорил, это глупость.
Поизучать поведение можно на тестовом файле, где I/P/B-кадры стоят на удобных timestamp'ах и на видео наложен тип и номер кадра.
Опасно
Переносы (
^) и экранирование (%->%%) виндовые, не для bash.-vfнакладывает на кадр свойства%{pict_type},%{frame_num},%{pts} через 3 вызова drawtext.ffmpeg совсем не годится для такого, выглядит и отлаживается отвратительно, это работа для vapour/avisynth, но зато без лишних зависимостей
Если кратко:
интервал работает так: [-ss; -to), -t тоже задаёт открытый интервал
но только не с
-c copy, тогда интервалы работают... как-то сложноконец интервала с
-c copyможет быть P-кадром, может быть битым (выкинул 5 B-кадров перед последним P-кадром)-noaccurate_seek -ss _ -i _делает фигню (у меня добавление опции захватывает ещё один кадр перед -ss, независимо от типа кадра)автопоиск ключевых кадров для обоих концов интервала есть разве что в
-f segment -segment_times _,_,... -c copyПервый нужен, если вдруг энкодер плохо параллелится.
Нужен второй или не нужен, но чтобы взять готовое-открытое-бесплатное решение по ссылке, много сил не надо.
Следующая модель уже крупнее, на ней линейка прекращается, более свежий аналог-флагман от 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 ТБ - принципиальной разницы нет, смертным будут давать всё больше и больше.