nlve/BACKLOG.md

# Что отложено

Список того, что известно и сознательно не сделано. Не «когда-нибудь
починим», а «знаем, чего это стоит, и решили пока не платить».

## macOS: собирается, но работает наполовину

Сборка проверена. В тулчейне fpcupdeluxe уже стоит всё нужное:
кросс-компиляторы, Apple SDK (10.13, 11.0, 12.3) и виджетсет cocoa для
обеих архитектур. Обе цели собираются с первого раза:

    ./build.sh macos    →  nlve_intel (Mach-O x86_64)
                           nlve_arm   (Mach-O arm64)

Чего не будет, пока не сделано:

**Предпросмотра нет.** Встраивание mpv написано под два случая: X11 (под
gtk2 создаётся своё дочернее окно и его номер отдаётся mpv в `wid`) и
Windows (там у панели есть настоящий HWND). Под cocoa нужен третий путь —
отдать mpv указатель на NSView. Это не правка на десять строк: нужно
разобраться, как LCL под cocoa отдаёт NSView панели, и проверить, что mpv
рисует именно в неё.

**Окно зависимостей врёт.** Списки в `uDeps.pas` разделены на два случая:
Windows и всё остальное. Мак попадает во второй и получает совет
`sudo apt install ffmpeg`. Нужен свой список: `brew install ffmpeg mpv`
или готовые сборки.

**Проверить нечем.** У нас нет мака. Собранный, но ни разу не запущенный
файл — это предположение, а не сборка. Всё, что можно утверждать сейчас:
компилятор и компоновщик отработали без ошибок.

**Двух файлов может оказаться мало.** Intel и Apple Silicon сейчас
раздаются отдельно. Склеить их в один универсальный умеет `lipo`, но в
тулчейне он есть только для powerpc — для x86_64 и arm64 его надо
доставить.

**Обёртка .app не настроена.** lazbuild её создаёт, но внутри лежит
ссылка на файл с именем `nlve`, которого после переименования нет.
Сейчас она просто удаляется. Настоящему приложению нужны свой Info.plist,
значок и, для раздачи, подпись и нотаризация у Apple.

## Лицензия не выбрана

libmpv грузится в наш процесс, а её сборки — GPL (в Ubuntu GPL-3+ из-за
libsmbclient, у shinchiro тоже GPL). По толкованию FSF это делает
совместную работу производной, и при раздаче программа должна быть под
GPL-3+ или совместимой.

Пока ничего не раздаётся — вопрос не стоит. Решать его перед первой
раздачей сборок. Возможный обход: отказаться от libmpv в пользу своего
вывода кадров через ffmpeg, но это большая работа и заметно хуже по
плавности.

ffmpeg проблемой не является: он запускается отдельной программой.

## Настоящая прозрачность в исходном файле

Цветовой ключ выбивает цвет, но бывает и прозрачность, записанная в самом
файле: WebM с VP8/VP9, ProRes 4444, QuickTime Animation. ffmpeg их
распаковывает в кадр с альфа-каналом, и ключ таким файлам не нужен —
достаточно не выбрасывать альфу по дороге.

Что для этого потребуется, когда дойдут руки:

- при добавлении файла запоминать, есть ли у него альфа (`pix_fmt` с
  буквой «a»: yuva420p, yuva444p10le, argb);
- такой клип считать несплошным так же, как клип с ключом, — то есть
  собирать участок слоями;
- в цепочке фильтров следить, чтобы альфа не терялась: `scale` её
  сохраняет, а `pad` — только с прозрачным цветом полей;
- аппаратное декодирование к таким файлам не применять: альфа в VP9
  лежит отдельным потоком, и видеокарта его не отдаёт.

Чего не будет в любом случае: раздать готовый ролик с прозрачностью в
MP4/H.264 нельзя — контейнер и кодек альфу не хранят. Для этого нужен
отдельный вывод в VP9 или ProRes 4444.

## Предпросмотр не показывает кадрирование обычного клипа

Кадрирование и поворот видны в окне только у клипов с ключом или
прозрачностью: их плеер кладёт поверх основы сам и применяет к ним
цепочку фильтров. Обычный клип идёт списком кусков, а список фильтровать
нечем — он играется как есть, во весь кадр. В готовом ролике при этом всё
верно: такой кусок помечен на пересборку и обкладывается полями.

Проверено опытом: у клипа выключен только ключ, кадрирование оставлено —
окно показывает его во весь кадр.

Как это делается тем же механизмом, что и наложение: провести такой клип
через ту же дорожку наложения, а под ним заставить основу быть чёрной —
непрозрачный клип с полями в готовом ролике именно так и закрывает всё,
что ниже. Значит, уплощению нужно понятие «здесь дыра, даже если ниже
что-то есть».

Чего это стоит: ветка масштабирования в цепочке работает на каждом кадре,
а не только там, где клип виден. Для накладки в 512 точек это пустяк, для
куска 2688x1512 — уже нет. Поэтому сначала замер, потом решение.

## Окно настроек программы

Переключателей, которые стоят машинного времени, становится больше, а
живут они кто где: прилипание и схлопывание — кнопками внизу, ключ в
предпросмотре — в меню «Вид», выбор кодировщика вообще нигде (берётся
NVENC, если он есть). Это разрозненно и не даёт увидеть общую цену.

Нужно одно окно, где собрано всё, что можно выключить ради скорости:

- ключ и прозрачность в предпросмотре (сейчас в меню «Вид»);
- наложение в предпросмотре вообще — на слабой машине может не хватать и
  его, тогда честнее показывать одну основу;
- кодировщик для пересборки: аппаратный или процессорный, и какой
  именно;
- где держать кэш и когда его убирать;
- прилипание клипов и курсора (сейчас кнопками, но им место и здесь).

Почему это важно: разработка идёт на машине с быстрой видеокартой, и
всё, что здесь считается «недорогим», на другой может оказаться
неподъёмным. Пока цифры замеряны только на одной машине, у человека
должна быть возможность выключить любую из этих трат.

## Сборка потоком: чего она не даёт

Ролик собирается потоком — куски идут сразу в готовый файл, кэш не
создаётся. За это заплачено тремя вещами, и все три известны заранее.

**Продолжение стоит места.** Дописать в конец существующего MKV нельзя:
Matroska этого не даёт. Продолжение всегда пишется в новый файл, куда
сперва переливается целая часть старого, так что на диске в этот момент
лежат оба — места нужно вдвое больше готового ролика. Обойти это можно
только разбором и правкой самого контейнера, а это уже своя маленькая
библиотека Matroska.

**Отступ назад — до целого куска.** Продолжают не с последнего
записанного кадра, а с границы последнего целого куска: кусок — это
неделимая единица, у него свои метки времени и своё число кадров. На
замерах терялось от нуля до нескольких секунд работы. Мельче отступать
можно было бы, храня рядом с файлом карту стыков, но выигрыш в секундах
не стоит нового файла, который надо держать в согласии с роликом.

**MP4 продолжать нельзя вовсе.** Оглавление пишется в конец, оборванный
файл не открывается — `moov atom not found`. Программа предупреждает об
этом до начала сборки и предлагает MKV. Теоретически недописанный MP4
можно восстановить, собрав оглавление по кускам самому (так делают
untrunc и подобные), но это отдельная задача другого размера.

**Потоком идёт не всё.** MPEG-TS несёт не любой кодек, и пересборка
всего ролика под площадку требует списка кусков. В этих случаях сборка
идёт по-старому, через кэш — со всеми его 110 ГБ на часе материала.

## Мелочи, до которых не дошли руки

**Вид дорожки не виден в её заголовке.** Дорожки картинки, звука и текста
подписаны V1, A1, Т1, и по букве вид угадывается, но не более того.
Клип, попавший на дорожку чужого вида, теперь не принимается и не
теряется, но само различие стоило бы показать явно — значком или цветом
полосы заголовка.

**Значок файла программы под Windows.** Значок окна задаётся из
`uIconData`, а значок самого `.exe` в проводнике берётся из ресурса при
сборке — там он до сих пор стандартный.

**Кэш наложений не убирается.** Каждая правка наплыва создаёт в кэше
проекта новый файл; старые остаются лежать. Клипы с ключом и
прозрачностью сюда больше не попадают — их показывает сам плеер, — так
что расти кэшу теперь почти не с чего.

**Окно кадрирования открывается около четырёх секунд.** Оно синхронно
достаёт два кадра ffmpeg-ом (по 2.2 с каждый на шестигигабайтном файле) и
только потом показывается. Лечится показом окна сразу и дорисовкой кадра
по готовности, либо одним кадром вместо двух.