# Что отложено Список того, что известно и сознательно не сделано. Не «когда-нибудь починим», а «знаем, чего это стоит, и решили пока не платить». ## 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, если он есть). Это разрозненно и не даёт увидеть общую цену. Нужно одно окно, где собрано всё, что можно выключить ради скорости: - ключ и прозрачность в предпросмотре (сейчас в меню «Вид»); - наложение в предпросмотре вообще — на слабой машине может не хватать и его, тогда честнее показывать одну основу; - кодировщик для пересборки: аппаратный или процессорный, и какой именно; - где держать кэш и когда его убирать; - прилипание клипов и курсора (сейчас кнопками, но им место и здесь). Почему это важно: разработка идёт на машине с быстрой видеокартой, и всё, что здесь считается «недорогим», на другой может оказаться неподъёмным. Пока цифры замеряны только на одной машине, у человека должна быть возможность выключить любую из этих трат. ## Мелочи, до которых не дошли руки **Вид дорожки не виден в её заголовке.** Дорожки картинки, звука и текста подписаны V1, A1, Т1, и по букве вид угадывается, но не более того. Клип, попавший на дорожку чужого вида, теперь не принимается и не теряется, но само различие стоило бы показать явно — значком или цветом полосы заголовка. **Значок файла программы под Windows.** Значок окна задаётся из `uIconData`, а значок самого `.exe` в проводнике берётся из ресурса при сборке — там он до сих пор стандартный. **Кэш наложений не убирается.** Каждая правка наплыва создаёт в кэше проекта новый файл; старые остаются лежать. Клипы с ключом и прозрачностью сюда больше не попадают — их показывает сам плеер, — так что расти кэшу теперь почти не с чего. **Окно кадрирования открывается около четырёх секунд.** Оно синхронно достаёт два кадра ffmpeg-ом (по 2.2 с каждый на шестигигабайтном файле) и только потом показывается. Лечится показом окна сразу и дорисовкой кадра по готовности, либо одним кадром вместо двух.