Comments 9
Честно говоря, статья читается как "машину почему-то трясло при езде; через неделю мы обнаружили, что оказывается, в колеса должен быть накачан воздух". В ответ на проблему типа "долгая перемотка, особенно если мотать надо далеко от начала" первой же мыслью должно было быть "а что у нас с индексами"?..
Вот именно. «Через неделю Зоркий Глаз заметил, что у амбара машины недостаёт одной стены одного колеса».
Впрочем, а чего Вы хотите от поколения ИИ?
Да, сейчас это выглядит очевидно. Видимо, существует два типа людей - те, кто сразу с рождения знают как устроен просмотр файлов по сети, и те, кому для этого сначала приходится словить баг. Я, к сожалению, оказался во второй категории. 🙂
До этой истории я с внутренностями WebM вообще не сталкивался. Поэтому сначала проверял то, что выглядело наиболее вероятным. Только когда эти версии отпали, пришлось лезть в спецификацию контейнера.
При чём тут просмотр файлов по сети? Вы ещё скажите, что условный file.mp4 в текстовом просмотровщке никогда не открывали и не удивлялись, «а что это тут за 20 страниц какой‑то подозрительно повторяющейся фигни???» (а это тот самый индекс, дети.)
С рождения никто не знает. Есть те, кто перед написанием кода немного погружаются в предметную область. И другие.
Но черт бы с ним, с собственным знанием; допустим манагеры сдернули первого попавшегося программиста чинить критичную багу в совершенно ему неизвестный проект; код видим впервые, про видео не знаем ничего, а работать как-то надо. Тогда да, можно узнать много нового и интересного в процессе слепого поиска.
Но у нас же теперь есть LLMки, которые знают за нас. Вот я в курсор закинул первые два абзаца из статьи и получил:
Похоже на проблему с индексом seek в WebM или с range-запросами.
Симптом очень типичный для WebM без нормального seek-индекса (Cues).
Что происходит
Браузерный
MediaRecorder/ захват из Телемоста часто пишет WebM «на лету»:
в файле нет полноценного элемента Cues (карта таймкод → offset), либо он неполный;
duration может быть неизвестен или некорректен;
clusters идут подряд без удобного индекса.
Поэтому:
старт с начала — ок (последовательное чтение);
короткая перемотка — ок (можно «досканировать» ближайшие clusters);
прыжок сразу на ~10-ю минуту — плеер не знает байтовый offset, начинает тянуть большой диапазон, буфер растёт, а воспроизведение не стартует, пока не найдётся нужный keyframe/cluster.
Ну и дальше - как посмотреть в webm и подтвердить (ffprobe/mkvinfo), и как перестроить webm через ffmpeg, чтобы индексы появились.
А если работать с mkv на низком уровне, можно изначально выделить пустое место под SeekHead и после завершения записи просто заполнить его без копирования всего файла, некоторые записывалки так делают
(Правда, Cues тогда останется в конце, но не уверен, плохо ли это, если HTTP Range работает)
Исправлять уже загруженные файлы мы не стали.
Таки непонятно, чем провинились участники проекта, просматривающие старые записи.
Как мы несколько дней искали проблему с перемоткой WebM