MiniDV → Apple Silicon

1. Стек

Физическая цепочка

Порядок сборки жёсткий: A1790 в Mac, в него A1463, в него FireWire-кабель. A1790 однонаправленный (TB2-устройство → TB3-хост), наоборот не работает. Внутри A1463 — PCIe-контроллер OHCI 1394, который пробрасывается в систему через Thunderbolt-туннель.

Точные идентификаторы

Состояние системы, необходимое для работы

Параметры сигнала

2. Что было сделано

Последовательность воспроизводима с нуля на любом Apple Silicon Mac с macOS 26 и таким же адаптером.

kmutil inspect --bundle-path /System/Library/Extensions/IOFireWireFamily.kext | grep -i fire
kmutil showloaded | grep -i IOFire
ioreg -p IOService -w0 | grep -i "11c1"

mkdir -p ~/Developer && cd ~/Developer
git clone https://github.com/mrmidi/ASFireWire.git
cd ASFireWire

sudo xcode-select -s /Applications/Xcode.app/Contents/Developer
sudo xcodebuild -license accept

./build.sh --config Release     # БЕЗ --scsi
./sign.sh

csrutil disable

csrutil status                          # System Integrity Protection status: disabled.
sudo systemextensionsctl developer on

cp -R build/DerivedData/Build/Products/Release/ASFW.app /Applications/
open /Applications/ASFW.app

systemextensionsctl list        # ждём [activated enabled]
ioreg -p IOService -w0 -l -r -n "pci11c1,5901" -d 2 | grep -Ei "ASFWDriver|IOUserServerCDHash"

sed -i '' 's/constexpr uint8_t kSpeedS400 = 0x02;/constexpr uint8_t kSpeedS400 = 0x00;  \/\/ S100 responses/' \
  ASFWDriver/Async/Tx/ResponseSender.cpp
./build.sh --config Release && ./sign.sh

systemextensionsctl uninstall - net.mrmidi.ASFW.ASFWDriver
rm -rf /Applications/ASFW.app
cp -R build/DerivedData/Build/Products/Release/ASFW.app /Applications/
open /Applications/ASFW.app        # ⌘I, одобрить, перезагрузиться

3. Найденные баги и наблюдения

Баг 1 — жёстко зашитая скорость S400 в исходящих ответах исправлен

ASFWDriver/Async/Tx/ResponseSender.cpp, строки 34 и 42:

constexpr uint8_t kSpeedS400 = 0x02;
...
uint32_t BuildQ0(uint8_t tLabel, uint8_t tCode) {
    return (static_cast<uint32_t>(kSrcBusID & 0x01) << 23) |
           (static_cast<uint32_t>(kSpeedS400 & 0x07) << 16) |   // ← всегда S400
           ...

Исходящие async-запросы используют скорость из speed map (драйвер корректно опускает узел до S100 после двух таймаутов), а ответы — нет. Камкордер i.LINK работает только на S100 и физически не принимает пакеты на S400. Результат — шторм AT-resp DROPPED ... event=0x03 (evt_missing_ack) и полный развал AV/C.

Почему баг не всплывал раньше: всё тестовое железо автора (Apogee Duet, Focusrite Saffire, PreSonus StudioLive, Midas Venice) — устройства S400. Камкордер S100 попал на этот драйвер впервые.

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

Правильное исправление для upstream: отзеркаливать скорость принятого запроса, как это делает Linux (fw_fill_response). Мешает баг 3.

Баг 2 — AT-completion не сопоставляется для блочных записей открыт

После исправления бага 1 транзакции на проводе проходят полностью — это видно в трассе диагностики:

TX ATReq 34 WrBlock S100 0xFFC0→0xFFC1 0xFFFFF0000B00  complete   ← AV/C-команда в FCP_COMMAND
RX ARReq 34 WrBlock      0xFFC1→0xFFC0 0xFFFFF0000D00  Ack 0x12   ← ответ камеры через 2.9 мс
TX ATRsp 34 WrResp S100  0xFFC0→0xFFC1                 complete   ← наш write-response

Но драйвер этого не видит и через 750 мс помечает транзакцию как TimedOut:

OnTimeout: tLabel=34 state=ATPosted ackCode=0x0
❌ FAILED: AT completion never arrived after 2 attempts
[AVC] AVCUnit: UNIT_INFO failed: result=8

Квадлетные чтения (Config ROM) сопоставляются нормально — ломаются именно блочные записи с payload. Подозреваемое место: ATContextBase::ExtractCompletionTLabel, где индекс дескриптора-заголовка вычисляется как (headIndex + capacity - 2) % capacity — для пакетов с payload геометрия дескрипторов другая.

Практическое следствие: AV/C-команды до камеры доходят и выполняются, интерфейс просто рапортует «no FCP response». Кнопки Play/Stop/Rewind, скорее всего, работают, несмотря на сообщение. Для захвата потока это вообще не критично.

Баг 3 — скорость принятого пакета теряется при разборе блокирует правильный фикс бага 1

В OHCI скорость приёма лежит в битах 21–23 трейлерного xferStatus (Linux: p.speed = (status >> 21) & 0x7). В ASFireWire структура ARPacketView (ASFWDriver/Async/Rx/PacketRouter.hpp) хранит uint16_t xferStatus — младшие 16 бит. Биты скорости отрезаются, отзеркалить скорость запроса в ответе невозможно. В PacketRouter.cpp:223 при этом стоит заглушка event.speed = 0; // S100.

Правильный фикс: расширить поле до 32 бит либо добавить uint8_t speed в ARPacketView и использовать его в ResponseSender::BuildQ0.

Наблюдение — gap count 44 при оптимальном 5

Gap Count: 44        Expected Gap: 5
Decision: SuppressedByRoleMode
Configured Role Mode: Client Only (no BM/IRM)
BM Node: none

Драйвер сознательно не претендует на роль Bus Manager, поэтому никто не оптимизирует gap count. Для шины из двух узлов 44 — это заметно раздутые арбитражные паузы. На нашем захвате это не помешало (0 переполнений кольца), но при длинных лентах или более загруженной шине сюда стоит вернуться первым делом. Цикл-мастером выступает камера — она root и CMC-capable, Remote Cycle Continuity: Yes.

Что имеет смысл отправить в upstream

• Патч бага 1 с трассой транзакций как доказательством.
• Описание бага 2 с той же трассой — там видно, что проблема в сопоставлении, а не на проводе.
• Баг 3 как первопричину, мешающую сделать баг 1 правильно.
• Отчёт об успешном DV-захвате: модель камеры, GUID, конфигурация, счётчики. В README автор прямо просит такие репорты, и камкордер на этом драйвере до сих пор никто не проверял.

4. Методика оцифровки

4.1 Подготовка лент

• Дайте кассетам сутки полежать в комнате, если они хранились в холоде или сырости — конденсат убивает и ленту, и головки.
• Перед первой кассетой прогоните чистящую кассету. Дальше — каждые 8–10 часов записи.
• Оцифровывайте той же камерой, которой снимали. Юстировка головок у каждого аппарата своя, «родная» камера читает свою ленту заметно чище.
• Не перематывайте на максимальной скорости до упора — это главный источник зажёвывания. Если нужна перемотка, доводите до конца плавно.
• Лента скрипит, слышен неровный ход, видно осыпание — не гоняйте туда-сюда. Ловите один чистый проход, второго может не быть.
• Сдвиньте на кассете защиту от записи в положение SAVE перед оцифровкой.

4.2 Настройка камеры

4.3 Процесс

1. Запустите caffeinate -d -i в отдельном окне терминала — ноутбук не должен уснуть посреди кассеты.
2. Убедитесь, что свободного места хватает: 13 ГБ на час ленты. 60-минутная кассета SP ≈ 13 ГБ.
3. ASFW → Controller Status → Connect → вкладка DV Capture.
4. Канал 63. Выберите выходной файл с осмысленным именем (см. 4.5).
5. Start Capture, затем Play. Захват идёт в реальном времени: час ленты = час ожидания, ускорить нельзя.
6. Следите за счётчиками (см. 4.4). Не сворачивайте окно надолго — приложение вычитывает кольцо на 30 Гц.
7. По окончании — Stop Capture. Только после этого файл закрыт и валиден.

4.4 Контроль качества во время захвата

Эталон нашего захвата: 1895 кадров, 1 dropped, 621 186 isoch, 568 554 DV source, 0 non-DV, 0 overruns, 272 880 000 байт. 568554 / 1896 = ровно 300 пакетов на кадр.

4.5 Проверка результата

F=~/Documents/tape01.dv
python3 -c "import os,sys;s=os.path.getsize(sys.argv[1]);print(s,'bytes |',s/144000,'frames | remainder',s%144000)" "$F"
ffprobe -hide_banner "$F"

Остаток от деления обязан быть 0. Это главный признак того, что кадры выровнены и файл не бит. ffprobe должен показать dvvideo, yuv420p, 720x576 [SAR 16:15 DAR 4:3], 25 tbr и звуковые дорожки.

Проверить, есть ли что-то на второй звуковой паре (12-битный режим пишет две, вторая обычно пуста):

ffmpeg -hide_banner -i "$F" -map 0:a:0 -af volumedetect -f null - 2>&1 | grep mean_volume
ffmpeg -hide_banner -i "$F" -map 0:a:1 -af volumedetect -f null - 2>&1 | grep mean_volume

Уровень около -91 dB = дорожка пустая.

4.6 Именование и хранение

Мастер .dv — это точная копия ленты. Его не редактируют, не пережимают и не удаляют никогда; всё остальное пересоздаётся из него одной командой.

2003-08_семейный-отпуск_кассета-04.dv
2003-08_семейный-отпуск_кассета-04.dv.md      ← заметки: что на ленте, состояние, число dropped

Правило 3-2-1: три копии, на двух разных носителях, одна вне дома. 13 ГБ на час — это дорого в облаке, но дешевле, чем потерять всё. Таймкод ленты сохраняется в метаданных файла, так что порядок и позиции восстановимы.

4.7 Производные файлы

Мастер для монтажа — ProRes HQ, обе звуковые дорожки, поля сохранены

ffmpeg -i "$F" -map 0 -c:v prores_ks -profile:v 3 -vf "setfield=bff" \
  -c:a pcm_s16le tape01_prores.mov

Для просмотра — деинтерлейс в 50p, квадратный пиксель 768×576

ffmpeg -i "$F" -filter_complex \
  "[0:v]bwdif=mode=send_field:parity=bff,scale=768:576:flags=lanczos,setsar=1[v]" \
  -map "[v]" -map 0:a:0 -c:v libx264 -crf 18 -preset slow -pix_fmt yuv420p \
  -c:a aac -b:a 192k tape01_view.mp4

bwdif=mode=send_field даёт 50 кадров в секунду — движение остаётся таким же плавным, как на ленте. Деинтерлейс применяется только к копии для просмотра; мастер и монтажный ProRes остаются чересстрочными.

5. Живой режим: камера и звук в реальном времени

5.1 Цепочка целиком

5.2 Что реализовано

5.3 Звук: он уже лежит внутри DV-потока

Отдельного аудиопути не нужно: в каждом кадре DV 12 DIF-последовательностей, в каждой 9 аудиоблоков, и звук жёстко привязан к кадру. Отсюда важное следствие — звук и видео синхронны по построению, и синхронность не надо восстанавливать: 48 кГц — 1920 сэмплов на канал на кадр, 32 кГц — 1280, 44,1 кГц — 1764.

Проверено. 16 бит/48 кГц — 250 кадров, побитовое совпадение с FFmpeg (480 000 сэмплов, max|d| = 0); 12 бит/32 кГц — тоже побитово (1280 сэмплов на канал, сверка с первым аудиопотоком FFmpeg); офлайн-рендер графа AVAudioEngine — побитово. Живой прогон в устройство: 50 буферов из 50, потерь 0.

# что вообще есть в системе
/Applications/ASFW.app/Contents/MacOS/ASFW --list-audio-devices

# тон 1 кГц слева / 3 кГц справа прямо в приёмник
/Applications/ASFW.app/Contents/MacOS/ASFW --audio-selftest 3

# прогон .dv через боевой путь в темпе 25 к/с + дамп PCM для сверки
/Applications/ASFW.app/Contents/MacOS/ASFW --dv-audio-selftest test48.dv --pcm-out out.pcm

# тот же граф офлайн-рендером (сверка с FFmpeg)
/Applications/ASFW.app/Contents/MacOS/ASFW --audio-render-selftest test48.dv --pcm-out render.pcm

Установка приёмника: brew install --cask blackhole-2ch (нужен пароль администратора). Другой приёмник задаётся флагом --audio-device <имя или UID>, выключить звук — --no-audio.

5.4 Геометрия: почему картинка была сжата

В DV пиксель неквадратный, а 16:9WIDE у Sony — анаморфная запись: мануал DCR-PC115E (стр. 59) прямо говорит «the picture … is compressed in the widthwise direction». Показывать кадр надо так:

Признак лежит в VAUX Video Control пакете (тег 0x61, позиции чередуются между DIF-последовательностями), условие то же, что в FFmpeg: (vsc[2] & 7) == 2 || (!apt && (vsc[2] & 7) == 7).

# проверка без камеры: режим, растяжка и PNG на выходе
/Applications/ASFW.app/Contents/MacOS/ASFW --dv-frame-selftest wide.dv --png wide.png
# → режим кадра: 16:9 (анаморфно); извлечено 720×576 → 1024×576

Тестовые потоки генерируются FFmpeg: -f dv с -aspect 16:9 даёт анаморфный 16:9 (SAR 64:45), без него — обычный 4:3 (SAR 16:15).

5.5 Ярлык MiniDV Live: один клик

Двойной клик — и поднимается всё. Ярлык лежит в /Applications/MiniDV Live.app, исходники — scripts/minidv-live/ (обычный bash + помощник на node), переустановка — ./install.sh.

1. проверяет, что драйвер ASFW загружен и BlackHole установлен;
2. останавливает прошлый живой захват (иначе два процесса дерутся за одно кольцо драйвера) и поднимает новый;
3. открывает OBS и через obs-websocket приводит сцену к рабочему виду: источник Sony DCR-PC115E (тип syphon-input), звуковой вход BlackHole 2ch, видео вписано в канву;
4. включает виртуальную камеру (StartVirtualCam) — без этого браузер видит устройство, но кадров не получает.

Лог: ~/Library/Logs/MiniDVLive.log. Отладка без окон: MINIDV_NO_DIALOG=1 "/Applications/MiniDV Live.app/Contents/MacOS/MiniDVLive".

5.6 OBS: сцена, виртуальная камера и одна ловушка

• Видео: источник Syphon Client → сервер Sony DCR-PC115E. Сервер выбирается по uuid, а когда uuid сменился (новый запуск ASFW) — по паре name + app_name. Ярлык прописывает все три поля на каждом запуске: с пустыми настройками (так создаётся источник по умолчанию) он остаётся чёрным.
• Звук: источник Audio Input Capture → устройство BlackHole 2ch.
• Канва 1920×1080: кадр 1024×576 — ровно 16:9, поэтому ложится без полей и без искажений.
• Виртуальная камера включается кнопкой Start Virtual Camera (ярлык делает это сам).

5.7 Браузер: Chrome и другие

Разрешения нужны на двух уровнях: macOS (Настройки → Конфиденциальность → Камера/Микрофон) и сам сайт (иконка камеры в адресной строке). В нашем случае у Chrome оба разрешения выданы, а проблема была в выключенной виртуальной камере.

Для быстрой диагностики есть страница camera-test.html (запускается через локальный сервер скриптом camera-test.command — на file:// Chrome иногда не даёт доступ к камере). Она показывает список устройств, превью, negotiated-формат и точную ошибку (NotAllowedError, NotReadableError, OverconstrainedError), плюс отдельные кнопки с frameRate ideal/ровно 30/ровно 60. Полезное рядом: chrome://media-internals — покажет, какой формат запрошен и на чём споткнулся.

5.8 Что осталось

6. Состояние системы, обслуживание и откат

Каким должно быть рабочее состояние

Как остановить живой режим

pkill -f -- "--syphon"          # выключить камеру и звук
# в OBS: Stop Virtual Camera; в браузере устройства исчезнут сами

Откат ярлыка и obs-websocket

rm -rf "/Applications/MiniDV Live.app"
# WebSocket: OBS → Tools → WebSocket Server Settings → снять Enable
#   либо вернуть конфиг из бэкапа, который ярлык сделал сам:
#   ~/Library/Application Support/obs-studio/plugin_config/obs-websocket/config.json.bak-minidv

Полный откат драйвера

Порядок обратный установке и его нельзя нарушать:

pkill -f -- "--syphon"
systemextensionsctl uninstall - net.mrmidi.ASFW.ASFWDriver
systemextensionsctl list                 # убедиться, что записи нет
sudo systemextensionsctl developer off

И только потом Recovery → csrutil enable → перезагрузка.

Что сохранить на будущее

• Каталог ~/Developer/ASFireWire с правками — git diff (в репозитории инструкций лежит готовый патч-сет).
• Собранный ASFW.app — ad-hoc-подпись не привязана к машине, тот же бандл поставится на любой Mac с выключенным SIP.
• Отчёт диагностики из вкладки 1394 Diagnostics — GUID, топология, скорости, трасса транзакций.
• Исходники ярлыка — scripts/minidv-live/; пересобрать: ./install.sh.
• Этот документ.

7. Шпаргалка

Живой режим — одной командой

open -a "MiniDV Live"                                   # ярлык: камера + звук + OBS + виртуалка
MINIDV_NO_DIALOG=1 "/Applications/MiniDV Live.app/Contents/MacOS/MiniDVLive"   # без окон, для отладки
tail -f ~/Library/Logs/MiniDVLive.log                   # что происходит

Состояние системы

csrutil status
systemextensionsctl list
ioreg -p IOService -w0 | grep -i "11c1"
ioreg -p IOService -w0 -l -r -n "pci11c1,5901" -d 2 | grep -Ei "ASFWDriver|IOUserServerCDHash"

Звук

/Applications/ASFW.app/Contents/MacOS/ASFW --list-audio-devices
/Applications/ASFW.app/Contents/MacOS/ASFW --audio-selftest 3
/Applications/ASFW.app/Contents/MacOS/ASFW --dv-audio-selftest test48.dv --pcm-out out.pcm
/Applications/ASFW.app/Contents/MacOS/ASFW --audio-render-selftest test48.dv --pcm-out render.pcm

Геометрия кадра

/Applications/ASFW.app/Contents/MacOS/ASFW --dv-frame-selftest wide.dv --png wide.png

# тестовые потоки: 4:3 и анаморфный 16:9
ffmpeg -y -f lavfi -i "testsrc2=size=720x576:rate=25" -c:v dvvideo -pix_fmt yuv420p -r 25 -t 2 -f dv four3.dv
ffmpeg -y -f lavfi -i "testsrc2=size=720x576:rate=25" -c:v dvvideo -pix_fmt yuv420p -r 25 -aspect 16:9 -t 2 -f dv wide.dv

OBS: что видит сам OBS

# статус виртуальной камеры и источника (нужен node и включённый obs-websocket)
node scripts/minidv-live/obs-sources.js        # привести сцену к рабочему виду
# в логе скрипта: outputActive, videoActive, videoShowing, список источников

Логи драйвера и приложения

log stream --style compact --predicate 'processImagePath CONTAINS[c] "ASFWDriver"
 OR eventMessage CONTAINS[c] "[Discovery]" OR eventMessage CONTAINS[c] "[Async]"
 OR eventMessage CONTAINS[c] "[AVC]" OR eventMessage CONTAINS[c] "[Isoch]"'

log show --last 10m --style compact --predicate 'subsystem CONTAINS "DVLive"' | tail -40
sudo log collect --last 10m --output ~/Desktop/asfw.logarchive

Пересборка после правки

cd ~/Developer/ASFireWire
./build.sh --config Release --no-bump && ./sign.sh
systemextensionsctl uninstall - net.mrmidi.ASFW.ASFWDriver
rm -rf /Applications/ASFW.app
cp -R build/DerivedData/Build/Products/Release/ASFW.app /Applications/
open /Applications/ASFW.app      # ⌘I → одобрить → перезагрузиться

Оцифровка ленты и проверка файла

python3 -c "import os,sys;s=os.path.getsize(sys.argv[1]);print(s,'bytes |',s/144000,'frames | remainder',s%144000)" tape.dv
ffprobe -hide_banner tape.dv
ffmpeg -hide_banner -i tape.dv -map 0:a:1 -af volumedetect -f null - 2>&1 | grep mean_volume

Транскод

# монтажный мастер
ffmpeg -i tape.dv -map 0 -c:v prores_ks -profile:v 3 -vf "setfield=bff" -c:a pcm_s16le tape_prores.mov

# просмотр
ffmpeg -i tape.dv -filter_complex "[0:v]bwdif=mode=send_field:parity=bff,scale=768:576:flags=lanczos,setsar=1[v]" \
  -map "[v]" -map 0:a:0 -c:v libx264 -crf 18 -preset slow -pix_fmt yuv420p -c:a aac -b:a 192k tape_view.mp4

Полезное во время сессии

caffeinate -d -i        # не давать Mac уснуть
df -h ~                 # 13 ГБ на час ленты