Заметки

Допустим, у нас есть каталог VOB файлов с видеодиска, из которых хочется получить один файл, например, для удобства просмотра на смарт-ТВ по сети.

1. Убираем с дороги файлы других расширений и VOB-файлы очень маленькой длины (единицы килобайт) - это какая-то магия видеодисков, нам они не нужны. В случае сомнений, посмотрите, что в них, с помощью видеоплеера - скорее всего, они не играются или там просто чёрный кадр. Если там короткое видео с какой-нибудь заставкой - можно оставить.
2. Выявляем разрезанные по размеру последовательности файлов. Допустим, для VTS_01 есть: VTS_01_0.VOB, VTS_01_1.VOB, VTS_01_2.VOB и мы видим, что файлы с номерами 0 и 1 имеют длину ровно 1024М, а номер 2 какой-то более короткий. Это значит, что их надо склеить:
   cat VTS_01_0.VOB VTS_01_1.VOB VTS_01_2.VOB > VTS_01.VOB.
   Примечание: этот шаг может быть не обязателен, но иногда ffmpeg на таких нарезках на следующем шаге падает.
   Исходные файлы после склейки убираем с дороги, оставляем склеенный.
3. Конвертируем VOB-ы в mp4:
   for X in *.VOB ; do ffmpeg -i $X -c copy $X.mp4 ; done
   VOB-файлы больше не нужны, убираем в другой каталог.
4. Создаём список файлов для склейки окончательного файла, вида:
   file VTS_01.VOB.mp4
   file VTS_02_0.VOB.mp4
   file VTS_02_1.VOB.mp4
   file VTS_03_1.VOB.mp4
   file VTS_04_1.VOB.mp4
   Можно это сделать так:
   (for X in *.mp4 ; do echo "file $X"; done) > list.txt
   Убедитесь, что список получился в правильном порядке, при необходимости отредактируйте.
5. Склеим файлы по списку в одно видео:
   ffmpeg -safe 0 -f concat -i list.txt -c copy output.mp4

Готово!
Примечание: необходимость шага 3 не проверял, обоснование не знаю

Года с 2008 я ленился обрабатывать накопленные raw-файлы, потому что от виндовой проги Canon для обработки у меня портится настроение и болят руки (а на Fuji я вообще не снимал равки, потому что там прога совершенно садистская), да и вообще у меня ни одного нормального компьютера с Виндовс давно нет, виртуальная машина отдельная мука сама по себе, а для Linux производители камер ничего не сделали (и Adobe тоже, насколько я знаю). И тут внезапно обнаружил, что уже есть вполне адекватный конвертер для Линукса: Darktable, причём он даже входит в репозиторий Убунту (sudo apt install darktable - и готово). А что ещё лучше, у него есть вариант для командной строки darktable-cli, которым можно одним махом перегнать целый каталог с raw-файлами в PNG или TIFF и просто свалить их в архив и выборочно (то что того стоит) редактировать уже привычным Гимпом. Уже проверил - результат после пары движений в Гимпе получается не хуже фирменного конвертера и намного лучше JPEG из камеры, по крайней мере для 40D, из которого у меня и лежит основная непроявленная масса. Для полного счастья не хватает только поддержки 16-битного вывода в darktable-cli в настоящий момент - если фотка сильно не попала по экспозиции то её всё-таки придётся обрабатывать самим Darktable. Сама прога успешно пишет в любой битности, так что, в принципе, можно просто гуёвым Darktable перегнать целый каталог в 16-битный TIFF - не совсем Linux-way, но пойдёт.

https://www.darktable.org/

Современный C++ всё-таки странная штука.
Как было в девяностые? Когда-то я выучил основу BASIC, прочитав книжку за вечер. Потом Pascal, прочитав книжку день-два. C и самые необходимые основные функции библиотеки - тоже за пару дней (спасибо отличной книжке от K & R). На C++ перешёл, осилив книжку "От C к C++" за пару подходов. Delphi - зная Pascal и C++, просто сразу начал писать и разбираться по ходу дела.
Вчера я с помощью сначала всех интернетов, а потом нескольких вопросов к ChatGPT 4 (она тоже с первого раза правильно не подсказала), два часа сначала ваял такой фрагмент, а потом разбирался, что тут написано и почему именно так. И эта конструкция функционально ничего не делает, она просто замедляет компиляцию приложения и позволяет избежать копипасты и сэкономить букв (возможно, меньше, чем она сама длиной). В общем, я на освоение малополезной фичи потратил столько времени, сколько раньше было нужно на половину языка. И я даже не напишу второй раз то же самое с первой попытки без шпаргалки.

template<typename Func, typename Obj, typename Arg, typename = void>
struct is_callable_with_arg : std::false_type {};
template<typename Func, typename Obj, typename Arg>
struct is_callable_with_arg<Func, Obj, Arg, std::void_t<decltype((std::declval<Obj>().*std::declval<Func>())(std::declval<Arg>()))>> : std::true_type {};
void call_impl(VAR_TYPE arg, std::true_type) { (clz_->*sig_)(arg); }
void call_impl(VAR_TYPE, std::false_type) { (clz_->*sig_)(); }
...
call_impl(var_, std::integral_constant<bool, is_callable_with_arg<MEMBER, CLASS, VAR>::value>{});

Симптомы - с определённой периодичностью виртуальная машина съедает на несколько минут 100% от каждого выданного ей процессора (т.е. на 4 ядра - загрузка 400% и т.п.), при этом хост притормаживает, а виртуалка вообще неуправляема, т.к. даже движения мышки отрабатываются с огромной задержкой. В это время внутри виртуалки нет процессов, занимающих столько CPU. При этом, на хостах AMD такой проблемы нет. После долгих мучений, рабочий ответ, наконец, найден тут:

This actually is an IOMMU issue and the solution involves enabling it at the kernel command line. Enabling VT-d (the Intel IOMMU kernel driver) in the firmware isn't enough and tinkering with compaction_proactiveness and swappiness only constrain this behavior without addressing the underlying cause.
...
So, for GRUB, edit /etc/default/grub to add the above string to GRUB_CMDLINE_LINUX_DEFAULT, e.g.,

GRUB_CMDLINE_LINUX_DEFAULT="intel_iommu=on"

Save and close the file, then run:

# update-grub

Reboot to take effect.

https://unix.stackexchange.com/a/713470/415520

Как отследить приложения, которые приводят к внезапному ворчанию винтов по ночам, не дают жёсткому диску уйти в спящий режим или регулярно будят его.

iotop

Если ввод-вывод активный и идёт прямо сейчас, достаточно просто посмотреть на sudo iotop -o
Если ввод-вывод идёт небольшими порциями, то используем: sudo iotop -bktoqqq -d .5
Пояснение: -b - пакетный режим вывода, -k - килобайты, -t - показывать время, -o - показывать только потоки, которые занимаются вводом-выводом, -qqq - отключить заголовки, -d 0.5 - период обновления в секундах.
Поймав, какой процесс занимается работой с диском, можно посмотреть на его открытые файлы: lsof -p $PID (замените $PID на номер интересующего процесса).

fatrace

Это намного более удобный способ для отслеживания редких операций (программа есть в репозитории Убунты). Сразу печатает кто, в какой файл лазит и какой доступ (чтение или запись).
cd /mnt/каталог_куда_смонтирован_винт
sudo fatrace -c -t

P.S. Типичные злодеи - индексаторы файловой системы, их можно выпилить так: sudo apt remove locate mlocate plocate. См. askubuntu. Также постоянным желанием писать на диск страдает Yandex.Disk - демона синхронизации можно гасить, когда он не нужен.