Эталонный дизайн интерактивного видео от и до

Это инженерные рекомендации, а не юридическая консультация. Детали подтверждайте у профильных юристов.

Кратко

Эталонный дизайн интерактивного видео – это одна схема, на которой видно, как связаны все части интерактивного учебного видео: инструмент авторинга, хранение и доставка, плеер с оверлеями, которые делают видео интерактивным, небольшая память о действиях учащегося, мост, превращающий всё это в учебные записи, и система обучения, которая эти записи читает и строит по ним отчёты. Предыдущие статьи блока разбирали эти части по отдельности. Здесь они собраны в одну подсистему, которую можно показать и инженерам, и финансовому директору. Заодно проведена главная граница – место, где видео перестаёт быть просто видео и становится данными, которые LMS может оценить. Мы покажем всю архитектуру, контракт данных между её частями, три стандарта для связи с любой LMS – Experience API (xAPI) с Video Profile, cmi5 и Learning Tools Interoperability (LTI) – и три способа развёртывания, которые реально используют на российском рынке. В итоге вы сможете решить, что строить, что покупать и сколько примерно это стоит.

Зачем это читать

Если вы руководите корпоративным обучением, основали EdTech-продукт или отвечаете за продукт, то за словами «интерактивный видеоплеер» для вас стоит целая подсистема, которая должна встроиться в платформу обучения и пройти приёмку заказчика. Опасно видеть только часть картины. Команда выпускает красивый плеер с ветвлениями и квизами, а через полгода выясняется, что корпоративная LMS не получает трекинг в нужном виде, оценки не доходят до журнала, а вуз или госзаказчик отклоняет продукт: данные учащихся лежат в зарубежном облаке, ПО нет в реестре российского ПО или нет субтитров. Здесь вся карта собрана сразу. Вы увидите эти обязательства до того, как потратите бюджет, сможете ставить задачу инженерам по общей схеме и направите деньги туда, где продукт действительно выделяется. Это итоговая статья блока об интерактивном видео: здесь плеер, оверлеи, трекинг и система обучения наконец соединяются.

Что такое «эталонный дизайн» и зачем он вам

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

Интерактивному видео эталонный дизайн нужен потому, что оно стоит на стыке трёх дисциплин, которые редко сочетаются в одном человеке: видеоинженерии (воспроизведение, адаптация к сети), дизайна интеракций (квизы, хотспоты, ветвления) и инженерии учебных данных (трекинг, стандарты, журнал оценок). Команда, сильная в одном, обычно слабее в другом. Эталонный дизайн – общий документ, благодаря которому видеоинженер, методист и администратор LMS спорят об одной картинке, а не о трёх разных.

Дальше мы соберём эту картину: назовём семь подсистем, покажем их в одной архитектуре, проследим путь данных, подключим всё к системе обучения через реальные стандарты, разберём стоимость и закончим тремя самыми распространёнными моделями развёртывания.

Семь подсистем как одна архитектура

Вот полная картина. Любой продукт интерактивного учебного видео – собран он своими силами или из вендорских частей – содержит эти семь подсистем в таком порядке. Читайте схему слева направо как жизнь одного урока: его создают, хранят и доставляют, проигрывают и делают интерактивным, запоминают действия учащегося, превращают их в учебные записи, передают системе обучения и, наконец, строят по ним отчёты.

Нажмите, чтобы увеличить

Подсистема первая – авторинг. Здесь автор курса собирает интерактивное видео: загружает исходник, отмечает моменты, где должны появиться квиз, хотспот или развилка, и задаёт, что считать прохождением. Авторингом может быть ваш собственный инструмент, open-source-тип контента вроде интерактивного видео в H5P (бесплатном фреймворке для интерактивного контента) или коммерческая студия. На выходе – видеофайл плюс описание интеракций: небольшая структура данных вида «на 4:30 показать этот квиз; при таком ответе перейти на 7:10».

Подсистема вторая – хранение и доставка. Исходное видео и описание интеракций нужно где-то хранить и затем доставлять учащимся, часто в разном качестве под разные сети. Это слой стриминга – отдельная, давно решённая область: как работает адаптивная доставка, рассказано в разделе Video Streaming, а выбор кодека и лестницы битрейтов – в разделе Video Encoding. Эталонный дизайн использует доставку как готовый сервис и не строит её заново. Единственное решение, которое принимается на этом уровне, – упаковка: отдаётся урок как самостоятельное веб-приложение или в виде учебного пакета (об этом – в статье упаковка и доставка контента).

Подсистема третья – интерактивный плеер и движок оверлеев. Это сердце продукта и тема предыдущей статьи создание интерактивного видеоплеера. Плеер показывает видео и сообщает о событиях: воспроизведение, пауза, перемотка, окончание. Движок оверлеев слушает эти события и показывает нужную интеракцию в нужную секунду: карточку квиза, кликабельный хотспот, выбор ветки. Движок воспроизведения почти никогда не пишут сами – это делают браузер и библиотеки вроде Video.js, – а вот движок оверлеев как раз и отличает ваш продукт.

Подсистема четвёртая – хранилище интеракций. Когда учащийся отвечает на квиз или выбирает ветку, результат надо запомнить: сначала на время сессии, затем надёжно, чтобы после перезагрузки или возвращения прогресс не пропал. Хранилище интеракций – кратковременная память плеера: ответы, текущая ветка, реально просмотренные фрагменты, позиция для продолжения. Оно небольшое, но именно оно отличает плеер, который бережёт время учащегося, от плеера, который заставляет проходить модуль заново.

Подсистема пятая – xAPI-эмиттер (мост трекинга). В обучающем продукте это важнейшая подсистема: именно она превращает опыт учащегося в измеримые данные. Она слушает события плеера и хранилище интеракций и формирует утверждения Experience API – короткие стандартизированные записи вида «Мария верно ответила на вопрос на 4:30» – по правилам xAPI Video Profile. Ей посвящён отдельный раздел ниже: именно здесь эталонный дизайн окупает себя.

Подсистема шестая – граница стандартов с системой обучения. Это пунктир на схеме и самая важная граница во всём дизайне. Слева от неё – ваше приложение: плеер, оверлеи, данные. Справа – система управления обучением (LMS), которая зачисляет учащихся, ведёт журнал оценок и фиксирует прохождение, и её спутник Learning Record Store (LRS) – база данных, созданная специально для хранения xAPI-утверждений. Связь через эту границу не делают на коленке: она идёт по одному или нескольким стандартам (xAPI, cmi5, LTI или более старому SCORM), и выбор стандарта – центральное архитектурное решение. О нём ниже.

Подсистема седьмая – аналитика и отчётность. Когда учебные записи попали в LRS и LMS, их нужно превратить в ответы: кто прошёл курс, где учащиеся бросали просмотр, на каком вопросе ошибались все. Этим занимается слой аналитики: он читает данные из LRS (а часто и из отдельного хранилища данных) и строит дашборды для преподавателей, учащихся и бизнеса. Подробно об этих метриках – в статье основы метрик обучения и в блоке о метриках; здесь это последняя стадия конвейера.

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

Контракт данных: что передаётся через границу

Эталонный дизайн хорош ровно настолько, насколько точен его контракт данных – список того, что передаётся по каждой связи. Расплывчатые формулировки вроде «плеер шлёт данные трекинга в LMS» – верный способ провалить ревью проекта. Пройдём по системе вместе с одним учащимся.

Нажмите, чтобы увеличить

Плеер и движок оверлеев генерируют события двух видов. Первый – события видео: учащийся нажал play, поставил паузу, перескочил с 2:10 на 6:40, досмотрел до конца. Второй – результаты интеракций: учащийся верно ответил на квиз на 4:30, выбрал ветку B, поставил закладку.

xAPI-эмиттер переводит оба вида в xAPI-утверждения формата «актор – глагол – объект», который задаёт спецификация Experience API версии 1.0.3 (ADL Initiative, xAPI 1.0.3). Для событий видео он использует xAPI Video Profile (ADL / xAPI Video Community of Practice, v1.0.3). Профиль определяет три глагола, специфичных для видео, – played, paused, seeked – и берёт стандартные для остального: initialized, когда видео готово, completed, когда достигнут порог, и terminated, когда учащийся уходит. Детали передаются в расширениях результата time, time-from, time-to, progress и played-segments.

Два правила спецификации стоит назвать точно: на них спотыкается почти каждая первая реализация. Первое: по Video Profile свойство completion со значением true должно быть только в утверждении completed, а другие утверждения о видео его не содержат (xAPI Video Profile, v1.0.3, модель данных утверждения). Второе: прохождение измеряется относительно порога прохождения (completion threshold) – числа от 0 до 1, по умолчанию 1 (всё видео). Считается оно по played-segments, то есть по фрагментам, реально просмотренным учащимся с учётом всех попыток, а не по тому, дошла ли позиция воспроизведения до последней секунды (xAPI Video Profile, v1.0.3). Учащийся, который перетащил ползунок в конец, оказался на последней секунде, ничего не посмотрев; расширение played-segments существует, чтобы ваша система видела разницу. Это та же ловушка «просмотрел 100% ≠ прошёл», о которой говорится в статье основы метрик обучения.

Утверждения попадают в Learning Record Store, и дальше происходят две вещи. Аналитика читает сырые утверждения и строит дашборды вовлечённости: кривые отвала, тепловые карты повторных просмотров, долю верных ответов по каждому вопросу. А балл, рассчитанный по результатам квизов, уходит в журнал LMS; как именно – зависит от стандарта, выбранного для шестой подсистемы. Об этом следующий раздел.

Одна деталь контракта связана с законом, а не со спецификацией. Актор в каждом утверждении – это учащийся, так что LRS фактически становится базой персональных данных. С 1 июля 2025 года ч. 5 ст. 18 152-ФЗ запрещает собирать, записывать и хранить персональные данные граждан России с использованием баз данных за пределами РФ. Поэтому LRS, аналитическое хранилище и резервные копии должны находиться в российском контуре, а облачный LRS или аналитика зарубежного вендора не подходят. Дешёвая страховка на уровне архитектуры – псевдонимный актор: xAPI 1.0.3 позволяет идентифицировать агента через account (адрес системы плюс внутренний идентификатор). Тогда ФИО и e-mail в утверждения не попадают, а связь идентификатора с человеком остаётся в LMS.

Подключение к системе обучения: три стандарта

Пунктирную границу на рисунке 1 пересекает стандарт, и в 2026 году актуальны три варианта (плюс устаревший, который вам ещё встретится). Выбрать подходящий под вашу ситуацию – то самое архитектурное решение, ради которого и строится эталонный дизайн. Сначала опишем их простыми словами, затем разместим на карте.

Experience API (xAPI) – современный стандарт учебных данных, который курирует ADL Initiative. xAPI-утверждение – это фраза («Мария прошла модуль 3»), а LRS – журнал, куда такие фразы записываются. xAPI подходит, когда нужен подробный трекинг каждой интеракции внутри видео, включая события вне формального запуска курса. Слабое место xAPI в том, что сам по себе он не определяет, как курс запускается и как LMS узнаёт, что учащийся «закончил».

cmi5 – связующий стандарт, тоже от ADL. Это профиль xAPI, который добавляет недостающие правила: как LMS запускает урок, как передаёт учащемуся защищённый токен, и небольшой фиксированный словарь утверждений (launched, initialized, passed, failed, completed), понятный любой cmi5-совместимой LMS. Это свод правил, благодаря которому подробный xAPI-трекинг заодно даёт корпоративной LMS однозначный ответ «passed/failed/completed». Если видео живёт внутри корпоративной платформы и должно надёжно сообщать о прохождении, cmi5 – правильная граница там, где LMS его поддерживает. Оговорка для российского рынка: в публичных описаниях отечественных корпоративных LMS поддержку xAPI и cmi5 заявляют редко, поэтому спрашивайте вендора конкретно и закладывайте запасной путь через SCORM.

Learning Tools Interoperability (LTI) от 1EdTech (бывш. IMS Global) решает другую задачу: запускает ваш инструмент интерактивного видео внутри LMS как её собственную функцию и возвращает оценки. LTI 1.3 использует механизм безопасности на основе OpenID Connect и подписанный токен; единый вход (SSO) получается как следствие, без отдельного логина (1EdTech LTI 1.3 Core). Оценки передаются через Assignment and Grade Services (AGS) версии 2.0: ваш инструмент сам создаёт колонку в журнале LMS и записывает в неё баллы, от преподавателя ничего не требуется (1EdTech LTI Advantage, AGS v2.0). Набор дополняют два сервиса: Deep Linking позволяет преподавателю просмотреть ваш каталог видео прямо из LMS и встроить конкретный урок, а Names and Role Provisioning Services (NRPS) сообщает инструменту, кто зачислен на курс и в какой роли. Если ваш продукт – инструмент, который встраивают в LMS многих учебных заведений (типично для высшего образования и EdTech), ваша граница – LTI. В российских вузах стандарт де-факто – Moodle: он умеет подключать инструменты LTI Advantage и принимать от них оценки (Moodle Docs, External tool). Собственные электронные информационно-образовательные среды (ЭИОС) вузов проверяйте на поддержку LTI 1.3 отдельно.

Устаревший вариант – SCORM (ADL): стандарт упаковки курса, чтобы любая система обучения могла его воспроизвести и отследить, своего рода транспортный контейнер для урока. На SCORM 1.2 и SCORM 2004 до сих пор работает большая часть корпоративного контента, но они отслеживают фиксированную ограниченную модель данных внутри одного запуска в LMS и не умеют фиксировать подробные интеракции с видео. Используйте SCORM, когда LMS заказчика ничего другого не принимает (в российских корпоративных проектах это частый случай), и параллельно отправляйте подробные xAPI-утверждения в свой LRS. Там, где доступен cmi5, выбирайте его: он даёт и прохождение в стиле SCORM, и детализацию xAPI.

Нажмите, чтобы увеличить

Позиция эталонного дизайна сознательная: подробные утверждения xAPI Video Profile отправляются в LRS для аналитики всегда, а границу прохождения с LMS – cmi5, LTI AGS или SCORM – выбирают по тому, как продаётся продукт и что умеет LMS заказчика. Подробное сравнение стандартов – в статье SCORM, xAPI, cmi5 или LTI: какой стандарт и когда, практика подключения к отечественным системам – в статье интеграция с российскими LMS и ЭИОС вузов. Здесь задача – показать место каждого стандарта в архитектуре.

Что вы строите, а что покупаете

Теперь наложим границу «строить или купить» на архитектуру. Итог простой: нижнюю часть стека (воспроизведение, доставку) и подсистемы с сильными типовыми решениями покупайте или берите готовыми, а сами стройте тонкий слой, который отличает продукт. Ниже четыре реалистичных пути сборки всей подсистемы – с колонкой, которая решает исход большинства закупок в обучении: поддержкой стандартов.

Таблица показывает ловушку: вариант, который выглядит самым дешёвым (коммерческий SDK), со временем может оказаться самым дорогим, если его экспорт стандартов не совпадёт с вашей LMS, – мост трекинга всё равно придётся переписывать. Проверьте колонку поддержки стандартов до того, как вас впечатлит демо. И задайте вендору ещё два вопроса: где физически хранятся данные учащихся (персональные данные граждан РФ – только в российских базах) и есть ли продукт в реестре российского ПО. Второе важно при продажах образовательным организациям: п. 21 Правил применения электронного обучения и дистанционных образовательных технологий (ПП 1678) требует, чтобы системы управления обучением и сервисы в составе дистанционных технологий создавались и использовались в соответствии с законодательством РФ и (или) входили в реестр российского ПО. Госзаказчики трактуют эту норму строго.

Пример расчёта стоимости

Оценим сборку той части, которая отличает продукт: движка оверлеев, хранилища интеракций и корректного по стандартам xAPI-эмиттера поверх open-source-плеера. Это самый частый вариант, а цифры взяты из нашего проектного опыта и опубликованных диапазонов (Фора Софт, разработка кастомных видеоплееров, 2026).

Начнём с разработки. Слой интеракций и трекинга – это примерно 10–20 инженеро-недель на надёжную первую версию. Возьмём середину, 15 недель, и среднюю ставку команды, допустим, 188 000 ₽ за инженеро-неделю (4 700 ₽/ч × 40 часов; это ориентир, подставьте ставку своей команды или подрядчика):

15 инженеро-недель × 188 000 ₽/нед = 2 820 000 ₽  (первая версия слоя интеракций)

Добавим границу стандартов. Интеграция по cmi5 (запуск и прохождение) или инструмент LTI 1.3 с возвратом оценок через AGS – обычно ещё 4–8 инженеро-недель: механизм безопасности и работу с журналом нужно проверить на каждой целевой LMS. Возьмём 6 недель:

6 инженеро-недель × 188 000 ₽/нед = 1 128 000 ₽  (одна граница стандартов с тестированием)

Итого первая рабочая версия слоя интерактива с одной интеграцией с LMS – около 3,9 млн ₽ (2 820 000 + 1 128 000 = 3 948 000 ₽). Дальше заложите сопровождение: браузеры, версии LMS и сами стандарты меняются, поэтому обычно это 25–30% стоимости разработки в год:

3 948 000 ₽ × 0,27 ≈ 1 070 000 ₽ в год (сопровождение)

Сравните с коммерческим SDK или платформой с лицензией, допустим, 2,6–6,8 млн ₽ в год и ограниченным контролем над данными. Своя разработка окупается, когда сэкономленные лицензионные платежи за вычетом сопровождения покроют разовые 3,9 млн ₽:

разница в год = лицензия − сопровождение
  6 800 000 − 1 070 000 = 5 730 000 ₽   (лицензия у верхней границы)
  2 600 000 − 1 070 000 = 1 530 000 ₽   (лицензия у нижней границы)
срок окупаемости = разработка / разница в год
  3 948 000 / 5 730 000 ≈ 0,7 года (около 8 месяцев)
  3 948 000 / 1 530 000 ≈ 2,6 года

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

Три модели развёртывания

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

Нажмите, чтобы увеличить

Модель первая – встроенный инструмент (LTI). Интерактивное видео – функция, которую преподаватели запускают изнутри своей LMS (Moodle или собственной ЭИОС вуза). Журналом и зачислением управляет LMS. Граница – LTI 1.3: LMS запускает ваш инструмент с подписанным токеном, NRPS сообщает состав группы, AGS возвращает балл. Это основная модель для продуктов, которые продают вузам. Со школами и колледжами иначе: если обрабатываются персональные данные учеников, школа и организация СПО обязаны работать через государственные информационные системы и национальный мессенджер MAX (ч. 3.1 ст. 16 273-ФЗ, п. 9 ПП 1678). Поэтому продукт для школы должен вписаться в требования этих систем: свободно выбрать LMS школа не может.

Модель вторая – упакованный урок (cmi5 или SCORM). Интерактивное видео экспортируется пакетом, который корпоративная LMS или HR-система с модулем обучения импортирует и запускает как любой курс. Граница – cmi5 (современный стандарт на базе xAPI, предпочтителен там, где поддерживается) или SCORM (когда LMS заказчика принимает только его). Вы отдаёте файл, LMS его воспроизводит и фиксирует прохождение. Это основная модель для обязательного корпоративного обучения и онбординга.

Модель третья – самостоятельная платформа (xAPI + свой LRS). Ваш продукт сам является платформой обучения: зачисление, журнал и Learning Record Store принадлежат вам. Граница проходит внутри: плеер отправляет утверждения xAPI Video Profile прямо в ваш LRS, а аналитику вы строите поверх. Так получаются самые подробные данные и максимум контроля – но и полная ответственность оператора персональных данных, включая размещение LRS в России. Это модель для MOOC, маркетплейсов репетиторов и когортных платформ; их эталонные архитектуры подробно разобраны в блоке 9.

Большинство зрелых продуктов со временем поддерживают две модели из трёх – например, самостоятельная платформа заодно экспортирует пакеты SCORM или cmi5 для корпоративных заказчиков. Эталонный дизайн это допускает: xAPI-эмиттер во всех трёх моделях один и тот же, меняется только граница справа от него.

Частая ошибка, которая губит проекты интерактивного видео

Самая дорогая ошибка во всей архитектуре – считать границу стандартов второстепенной: сначала построить плеер и оверлеи, а трекинг «добавить потом». Трекинг – не финишное покрытие: он определяет устройство каждой подсистемы слева от себя. Если хранилище интеракций не записывает, какие фрагменты просмотрены и почему была поставлена каждая пауза, xAPI-эмиттер не сможет сформировать достоверное утверждение completed или обоснованное значение played-segments. Никакая доработка потом не вернёт данные, которые плеер не собрал. Команды, которые прикручивают трекинг в конце, регулярно обнаруживают, что цифры прохождения неверны, повторные попытки задваивают оценки в журнале, а корпоративный заказчик не принимает продукт. Сначала спроектируйте контракт данных, затем стройте всё, что слева от него.

К тем же предупреждениям относятся две ловушки доступности. Кастомные контролы оверлеев, которыми нельзя управлять с клавиатуры, нарушают критерий 2.1.1 (Keyboard) из WCAG 2.1, а видео без субтитров – критерий 1.2.2 (Captions, Prerecorded). Оба относятся к уровню A, то есть к минимальным требованиям (W3C WCAG 2.1). В России на WCAG 2.1 основан ГОСТ Р 52872-2019. Сам по себе он добровольный, но заказчик может включить его в техническое задание, а образовательная организация по ст. 79 273-ФЗ обязана создавать специальные условия для обучающихся с ограниченными возможностями здоровья. Добавлять доступность в готовый движок оверлеев намного дороже, чем сразу заложить её в эталонный дизайн.

Где здесь Фора Софт

Провести границу «строить или купить», о которой эта статья, мы и помогаем командам. Фора Софт с 2005 года разрабатывает видеостриминг, видеоконференции в реальном времени и интерактивное обучающее ПО, поэтому одна команда разбирается и в воспроизведении, и в движке оверлеев, и в границе стандартов – трёх дисциплинах, которые редко встречаются вместе. Мы полезны, когда интерактив и учебные данные – основа продукта, а универсальный SDK всё равно заставил бы переписывать мост трекинга. Мы расширяем проверенный open-source-плеер, строим слои оверлеев и интеракций, которые действительно отличают ваш продукт, и проводим корректную по стандартам границу xAPI, cmi5, LTI или SCORM с вашей платформой обучения – с LRS и аналитикой в российском контуре. Если правильнее купить, мы так и говорим. Во всех наших направлениях – e-learning, видеоконференции, стриминг, OTT, телемедицина и AR/VR – основа одна: видео в реальном времени и интерактивное видео.

Главное

• Интерактивное видео – конвейер из семи подсистем; самая важная граница в нём – граница стандартов.
• Всегда отправляйте утверждения xAPI Video Profile в LRS для аналитики; cmi5, LTI или SCORM для прохождения выбирайте по модели продаж и возможностям LMS заказчика.
• Считайте прохождение по просмотренным фрагментам и порогу, а не по тому, дошла ли позиция воспроизведения до конца.
• LRS – база персональных данных: держите её в России и используйте псевдонимного актора.
• До покупки проверьте у вендора экспорт стандартов (xAPI / cmi5 / LTI / SCORM), место хранения данных и наличие в реестре ПО.
• Сборка слоя, который отличает продукт (оверлеи + трекинг + одна граница с LMS), – около 21 инженеро-недели и порядка 3,9 млн ₽; полностью своё воспроизведение почти никогда не окупается.

Что читать дальше

• Создание интерактивного видеоплеера: архитектура и компромиссы
• Трекинг видео через xAPI: Video Profile и что отслеживать
• SCORM, xAPI, cmi5 и LTI: какой стандарт и когда выбрать