🏠: it

Рекомпрессия видеоархива

Более или менее разобравшись в доме с предметами материальными, я перешёл к более абстрактным вещам, а именно — наведению порядка в своём цифровом архиве. В нынешнем виде этот архив появился после продажи в 2010 году системного блока, в котором были DVD-приводы, и, как следствие, покупки первого сетевого хранилища, куда диски, которые уже негде было дома читать, были скопированы, по большей части, в виде образов ISO. Потом, конечно, объём данных рос, но по сути ничего не менялось — старые данные просто продолжали лежать, мигрируя с течением времени на новое железо.

В какой-то момент я решил держать на хранилище резервную копию домашнего неттопа, и выяснилось, что место уже забивается под завязку. Учитывая то, что цены на диски большого объёма сейчас довольно высокие (да и нет у меня желания устраивать у себя дома филиал Amazon Cloud им. Плюшкина), данными на хранилище я пользуюсь не очень часто и там давно не прибирались, я подумал, что неплохо было бы как-то сократить объём постоянно хранимых данных. В первую очередь следовало разобраться с видео, так как оно занимало больше всего места.

Общая идея заключалась в том, чтобы удалить что-то совсем уж ненужное и дубли одного и того же, если таковые найдутся, а остальное перекодировать в более компактные и высокоэффективные форматы H.264 и H.265, а их аудиодорожки — в aac, ogg или opus. Безусловно, перекодированное видео не должно выглядеть хуже в сравнении с оригинальным, то же касается и аудиодорожек. Для аудио нужно подбирать разумно высокий битрейт, желательно, обеспечивающий «прозрачность» (transparency), в основном это примерно 192 kb/s. Конечно, нужно действовать по ситуации — к примеру, если оригинальная аудиодорожка уже в mp3 128 kb/s, то нет смысла с ней что-то делать, нужно просто скопировать её в новый видеофайл как есть.

Данные я разделяю на три основных категории — легко восполнимые (известные и широко распространённые мультфильмы, художественные фильмы), труднодоступные (некоторые концерты, образовательные программы, документалистика и т. д.) и невосполнимые (в основном, личный архив). Исходя из этой классификации, подбирались и параметры кодирования. Всё кодирование делалось консольным медиаконвертером ffmpeg. Медиаконтейнером для всех файлов был выбран MKV как наиболее универсальный и свободный формат.

В общем случае, легко восполнимые видео кодировались в H.265 + ogg со стандартными параметрами — в основном это были мультфильмы. В принципе, львиную долю из этих файлов можно было просто стереть, но я кодировал их из спортивного интереса. Труднодоступные материалы и те фильмы, которые я не стёр — в H.265 (-crf 22 -preset slow) + aac 192 kb/s. Если видео было чересстрочным, использовался H.264 (-crf 20 -preset slow), так как он умеет корректно работать с чересстрочным сигналом — надо только не забывать правильно указывать порядок полей. Преобразование чересстрочного видео в прогрессивное путём деинтерлейса я не использую и никому не советую, так как это заметно ухудшает качество и далеко не всегда нормально отрабатывает; тем не менее, необходимо распознавать чересстрочный источник и не совершать ошибку, кодируя его как прогрессивный, так как это даст на выходе испорченное видео с «гребёнкой» при движении в кадре, которую уже невозможно убрать. Личные записи я в целом пока оставил в неизменном виде, перекодировал только некоторые короткие эпизоды, рассыпанные по нескольким файлам, которые от сборки их в единый файл только выиграли. Параметры были те же, что и для труднодоступных материалов.

Для порядка и красоты я оставлял все аудиодорожки, если их было больше одной. Отбрасывал только те, которые, при одинаковом содержании, были менее качественными (например, DTS 1,5 Mb/s и AC3 384 kb/s — перекодируем первый вариант, второй отбрасываем), и были не на русском или английском языках. В некоторых случаях я обрезал чёрные поля по краям кадра, предварительно определяя их границы фильтром cropdetect. Добавлял субтитры, вытаскивая их из исходного DVD или скачивая из интернета, причём субтитры я всегда переделывал в текстовый формат, пользуясь программой Subtitle Edit. Сохранял или добавлял метаданные: названия аудиодорожек и субитиров, навигацию по файлу (главы) с именами эпизодов. Для извлечения навигационных меток из DVD я использовал программу ChapterXtractor, в конфигурационном файле которого прописал шаблон, генерирующий формат метаданных для ffmpeg:

Preset 7=For ffmpeg metadata
Format 7=\n[CHAPTER]\nTIMEBASE=1/1000\nSTART=%ams\nEND=\ntitle=\n
Header 7=;FFMETADATA1\ntitle=\nartist=\n
Footer 7=\n[STREAM]\ntitle=

Весь процесс, включая подбор параметров, пробы и ошибки, чтение документации, поиск необходимых инструментов для работы и т. п., шёл в неторопливом темпе где-то месяца полтора. Нужно сказать, что физически я стёр немного, сокращение количества файлов и папок в основном обусловлено тем, что DVD, лежавшие россыпью файлов, отдельно валяющиеся аудиодорожки и субтитры были преобразованы в один итоговый файл. Вот результаты.

Было:

Имя подкаталога Размер Файлы Папки
Концерты 181,1 ГБ 204 30
Мультфильмы 153,5 ГБ 717 43
Документальные фильмы 126,9 ГБ 189 27
Записи 87,1 ГБ 33 5
Художественные фильмы 55,2 ГБ 48 5
Детские фильмы 41,3 ГБ 39 3
Образование 30,4 ГБ 1250 59
Прочее 67,9 МБ 13 1
Всего: 675,7 ГБ 2493 181

Стало:

Имя подкаталога Размер Файлы Папки
Документальные фильмы 81,0 ГБ 177 23
Концерты 69,1 ГБ 106 9
Записи 54,8 ГБ 24 4
Мультфильмы 46,2 ГБ 707 38
Образование 27,8 ГБ 1250 59
Детские фильмы 15,6 ГБ 39 3
Художественные фильмы 9,7 ГБ 37 3
Прочее 67,9 МБ 13 1
Всего: 304,2 ГБ 2353 148

График использования дискового пространства на хранилище:

В итоге, без какой-либо потери функциональности и удобства пользования (в ряде случаев эти критерии даже повысились) и визуального качества видеоматериалов я выиграл 370 гигабайт свободного места, и это только на одном каталоге, пусть и самом крупном. По-моему, неплохо.

Собрал часы

Когда-то давно мой отец сделал настольные часы из каких-то останков «Электроники», которые работали без корпуса и выглядели примерно так:

Изображение без описания
Фото из Музея советской электроники

Заметная часть моего детства прошла среди развороченных телевизоров, магнитофонов и прочей техники, я играл с радиодетальками, поэтому вид электронных внутренностей был привычен, не вызывал никаких негативных эмоций, и работающие часы без корпуса смотрелись гораздо интереснее, чем в корпусе. А ещё они отлично светились ночью, озаряя комнату магически-зелёным светом своего ваккумно-люминесцентного индикатора.

Не то чтобы мне хотелось иметь дополнительный источник светового загрязнения у себя дома, но частенько, просыпаясь ночью, хотелось бы знать, который час. Сейчас для этого я вынужден включать экран телефона, который очень неприятно бьёт светом в глаза, или вставать с кровати и нажимать кнопку «стационарного» (на самом деле SIP) телефона, который тоже показывает правильное время.

Собственно, набор требований к часам такой:

  • Светятся в темноте, но неярко;
  • Дешёвые;
  • Сами синхронизируют время, т. е., не требуют ручной подводки;
  • Питание от сети, никаких батареек.

Начал поиски готовых вариантов. Удивительно, но под такие, казалось бы, простые требования найти готовые недорогие часы я так и не смог. Часы, в которых есть wi-fi или которые умеют получать время по GPS, есть, но стоят они каких-то неприличных денег и называются «умными», т. е., обладают большим количеством никому не нужных функций. Оказалось, что часы с автосинхронизацией как отдельный прибор, а не как встроенный функционал чего-то большего — это редкость и, судя по ценникам, роскошь.

Во время поиска подходящего варианта узнал от коллеги, что есть так называемые часы с радиоконтролем, а именно — умеющие синронизировать время по протоколу DCF77, но стоят они тоже недёшево, к тому же, передатчик расположен в Германии, и Москва находится фактически на самом краю области приёма сигнала. Я прочёл на форумах, что синхронизация таких часов здесь — это вопрос везения, в основном она проходит ночью, когда меньше радиопомех, а ещё желательно жить повыше и иметь окна, обращённые на запад. Так как окна у меня обращены на юг, живу я за пределами Москвы, да ещё и на востоке, и высотой этажа похвастаться не могу, поэтому я оставил эту идею. Интересно, что и в России есть много служб точного времени — RWM, RBU, RTZ, но часов, способных использовать эти службы, я в продаже не обнаружил.

Остался единственный вариант — сделать часы самому. Идея заключается в том, что нужно найти какой-то микрокомпьютер, который умеет подключаться к интернету по wi-fi, по протоколу NTP получать оттуда точное время и показывать его на подключаемом экранчике, отсчитывая секунды самостоятельно до следующего сеанса синхронизации. Так как вычислительной мощности от этого микрокомпьютера не требуется, поэтому такой вариант, как Raspberry Pi, отпадает: здесь нужно что-то более миниатюрное и дешёвое.

Экран должен быть маленьким — всё-таки, я не на вокзал часы делаю. Мне очень нравятся часы на газоразрядных лампах (nixie tubes), которые смотрятся просто великолепно:

Но для моих познаний в электронике собрать такое слишком сложно, к тому же, эти лампы ярко светят и кушают относительно много электричества, да и корпус для такого великолепия нужно делать посерьёзнее, и блок питания нужен какой-то особый, то есть, задача сильно усложняется. Я обнаружил проект часов в интернете, которые мне подошли бы (Nixie Tap), но этот проект уже давно находится в подвешенном состоянии и неизвестно, будет ли он реализован вообще.

В результате, нашёл ровно то, что мне было нужно, на сайте arduinolab.pw, заказал железки, которые там рекомендуют, на AliExpress:

  1. Сам микрокомпьютер: LoLin NodeMcu V3 WIFI IoT development board based on ESP8266 — в районе 200 руб.
  2. Светодиодный дисплей: RobotDyn 4-Digit LED Display Tube, 7-segments, TM1637, 30x14 mm — примерно 100 руб.

Вид готовых часов без корпуса

Питается это хозяйство от стандартного зарядного устройства для телефона с проводом USB-microUSB. Я хотел собрать вариант 2.0, который с часами реального времени, и заказал их тоже, но впоследствии с ними у меня не заработало, к тому же оказалось, что микрокомпьютер прекрасно и сам справляется со счётом секунд. Код я взял на сайте Стива Кемпа, немного изменив его параметры. В частности, там часы синхронизируются с интернет-серверами каждые 5 минут, что безумно часто и так в принципе нехорошо делать, да и ни к чему.

В Правилах предоставления сервиса кластера серверов точного времени pool.ntp.org не рекомендуется синхронизация чаще, чем раз в полчаса, и вообще — чем реже, тем лучше. Я поставил 36 часов (129600 секунд), как там советуют делать, и за этот интервал вообще не заметно, чтобы часы отклонялись от эталонного времени — точность хода прекрасная. В коде также реализована возможность обновлять встроенную программу прямо через wi-fi (ArduinoOTA), но мне так и не удалось её задействовать — может быть, код устарел, да и в данном случае эта функция не очень нужна, в принципе. Прочие технические подробности можно прочитать в моём Карманном справочнике.

В итоге, я получил точнейшие и дешёвые часы, на которых нет ни одной кнопки. Всё, что им нужно — это питание и доступ к интернету через wi-fi. В качестве корпуса я использовал упаковку от велосипедного ремкомплекта, который я отмыл от наклеек и прорезал в нём необходимые отверстия канцелярским ножом.

Часы в сборе

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

Нормализация громкости

Меня всегда интересовало, существуют ли какие-то критерии правильной нормализации громкости аудиодорожек. Ну, что обычно подразумевается под нормализацией, так сказать, в быту? Простой пересчёт пиков до отметки в 0 дБ. Однако, результат чаще всего неудовлетворителен — динамический диапазон, т. е., разница между самым громким и самым тихим звуками вроде бы сохраняется (хотя ещё вопрос, так ли это в действительности при простом пересчёте), но сама по себе общая громкость может не повыситься совсем или повыситься незначительно из-за того, что самые громкие звуки, которых может быть один-два на всю запись, уже нормализованы и их повышать уже некуда, а остальной материал так и остался где-то снизу, и слышно его всё так же плохо.

Понятно, что простая линейная нормализация не подходит и нужна какая-то динамическая (в сочетании с компрессией), причём желательно основанная на каких-то объективных критериях. Последнее время я увлёкся изучением возможностей совершенно прекрасного консольного медиаконвертера ffmpeg, где я обнаружил аудиоплагин loudnorm, как раз занимающийся нормализацией аудиосигнала по стандарту Европейского вещательного союза EBU R128.

Какими основными критериями оперирует loudnorm?

  1. Общая громкость (Integrated loudness), измеряемая в единицах абсолютного значения громкости (Loudness units relative to full scale, LUFS). Общая громкость вычисляется на основании анализа звуковых частот и уровня сигнала, применимое к чувствительности человеческого слуха к ним.
  2. Точный пик сигнала (True peak), измеряемый в децибелах (dB). Это одномоментное наивысшее значение пика сигнала во всём звуковом материале, то есть, грубо говоря, самый громкий звук. По этому критерию как раз и делается линейная нормализация, описанная мной в начале статьи.
  3. Диапазон громкости (Loudness Range, LRA), измеряемый в единицах громкости (Loudness units, LU). Разница между самым громким и самым тихим звуками.
  4. Порог (Threshold). Я до конца не понял, что это за критерий, но вероятно, ниже этого порога сигнал не обрабатывается.

Чтобы повысить качество обработки аудиодорожки, loudnorm предусматривает обработку в два прохода. Первый — сбор данных, второй — непосредственно обработка с параметрами, полученными во время первого прохода. В интернете есть статья автора loudnorm, где он показывает на примере, как это работает. За основу там взят документ американского Сообщества аудиоинженеров AES TD1004.1.15-10 Recommendation for Loudness of Audio Streaming and Network File Playback, где в рекомендациях сказано, что общая громкость (Integrated loudness) не должна быть выше -16 LUFS и ниже -20 LUFS, а максимальный пик (True peak) не должен превышать -1.0 dB.

Что касается диапазона громкости (Loudness Range, LRA), то здесь нужно действовать по ситуации. Я нашёл на сайте AudioKinetic рекомендации по максимальному уровню LRA, там даны примерные значения для разных условий:
- Домашний кинотеатр — 20 единиц - Гостиная — 18 единиц - Кухня — 15 единиц - Гостиная (поздний вечер) — 9 единиц - Общественный транспорт, мобильное устройство — 6 единиц

Чем шумнее вокруг, тем меньший динамический диапазон нужно выставлять, чтобы расслышать все звуки в записи. Чем больше и громче динамики, тем больший LRA возможен. В общем, однозначного критерия здесь быть не может, хотя некоторые значения мы выяснили.

Перейдём, наконец, к практике. Имеется DVD-Video с полукустарно записанным концертом классической музыки, имеющий стандартные проблемы: громкие аплодисменты, тихая музыка и речь ведущей концерта. Графически аудиодорожка выглядит так:

Оригинальная аудиодорожка до обработки loudnorm

Делаем первый проход для сбора данных. Берём среднее значение из рекомендуемых для общей громкости -18 LUFS и рекомендуемый максимальный пик -1.0 dB. Диапазон громкости и порог, как значения неизвестные или приблизительные, пусть высчитываются автоматически.

ffmpeg -i in.wav -af loudnorm=I=-18:TP=-1:print_format=json -f null -

После окончания анализа получаем следующие данные:

[Parsed_loudnorm_0 @ 000000eef2eeea80]
{
"input_i" : "-22.27",
"input_tp" : "0.03",
"input_lra" : "20.10",
"input_thresh" : "-33.99",
"output_i" : "-19.39",
"output_tp" : "-1.00",
"output_lra" : "13.20",
"output_thresh" : "-30.08",
"normalization_type" : "dynamic",
"target_offset" : "1.39"
}

Запускаем второй проход в соответствии с полученными данными. Параметр -ar 48k нужен для сохранения результата в файл с частотой сэмплирования 48000 Гц. Если этого не сделать, то на выходе будет файл с нечеловеческими 192000 Гц. Это преобразование связано с наиболее точным поиском точного пика сигнала (True peak), но полагаю, что в данном случае этим можно пренебречь.

ffmpeg -i in.wav `
-af loudnorm=I=-16:TP=-1:measured_I=-22.27:measured_TP=0.03:measured_LRA=20.10:measured_thresh=-33.99:offset=1.39:print_format=summary `
-ar 48k out.wav

После окончания обработки получаем следующую картину:

[Parsed_loudnorm_0 @ 0000003e678ee8c0]
Input Integrated: -22.3 LUFS
Input True Peak: +0.0 dBTP
Input LRA: 20.1 LU
Input Threshold: -34.0 LUFS

Output Integrated: -16.2 LUFS
Output True Peak: -1.0 dBTP
Output LRA: 13.0 LU
Output Threshold: -26.8 LUFS

Normalization Type: Dynamic
Target Offset: +0.2 LU

Видно, что общая громкость стала на 6,1 выше, несмотря на то, что максимальный пик снизился на единицу, в соответствии с рекомендованным значением. Динамический диапазон стал уже на 7,1 — это привело к более ровному звучанию без резких перепадов громкости, но и сохранило динамику.

Результат обработки в графическом виде:

Обработанная аудиодорожка

Субъективно могу сказать, что стало гораздо лучше. Приведу отрывки из записи, где есть большой перепад громкости.

— - До обработки (—, —)

Upd: Всё же, нужно задавать динамический диапазон вручную, чтобы автомат не зажимал его слишком сильно. В итоге, более-менее универсальные параметры получились следующие: -af loudnorm=I=-16:TP=-1:LRA=18. Если LRA уже узкий, то он обратно не разжимается, насколько я успел заметить.

Красота на работе

Недавно научился прошивать микропрограммы в сетевых устройствах фирмы APC, теперь прошиваю всё, до чего могу дотянуться.

Сегодня на очереди были распределители питания в серверной (говоря проще, это такие длинные «пилоты» для серверных стоек, но только жутко умные, сетевые и с экранчиком).

Было Стало

Наконец-то

Хорошие новости — появились более-менее стабильные сборки Armbian на свежем ядре для моего нового сервера Orange Pi PC 2. Красноглазие продолжается!

First stable test images (CLI or desktop) with a modern #64bit kernel 4.13.5 for H5 based #OrangepiPC2
https://t.co/5LTv523zaS #docker #iot pic.twitter.com/y6KZJkD7ZU
— armbian (@armbian) October 9, 2017

https://twitter.com/armbian/status/917440345880834053