Wiki - Факультет компьютерных наук - Вклад [ru]

Файл:Deniskorolev.jpg

2018-08-20T18:10:11Z

Dkorolev:

Участник:ДенисКоролев

2018-08-20T18:07:59Z

Dkorolev:

[[Файл:deniskorolev.jpg|мини|справа|Вот так выглядит Денис Королев]]
{{Карточка_ментора
|categorize = yes
}}

'''Королев Денис Александрович'''

==Образование==
* МИЭМ, 2002, Инженер. Вычислительные машины, комплексы, системы и сети

* МИЭМ, 2002, ППК Управление качеством

* МИЭМ, 2007, к.т.н. Компьютерные сети и телекоммуникации

* МИЭМ, 2008, доцент.

==Области знаний и интересов==
* Видеотехнологии, видеовещание в интернет.

* Онлайн-поддержка обучения.

==Место работы==
* МИЭМ НИУ ВШЭ, Департамент компьютерной инженерии

* МИЭМ НИУ ВШЭ, "Цифровой университет" (проект НИУ ВШЭ).

==Контакты==
* E-mail: ''d.korolev@gmail.com''

* Mobile/Telegram/Whatsapp: ''+7 903 610 3290''

* VK: ''http://vk.com/dkorolev79''

* Facebook: ''https://www.facebook.com/denis.korolev.msk''

Участник:ДенисКоролев

2018-08-20T18:07:06Z

Dkorolev: Новая страница: «Вот так выглядит Денис Королев {{Карточка_ментора |categorize = yes }…»

[[Файл:deniskorolev.jpg|мини|справа|Вот так выглядит Денис Королев]]
{{Карточка_ментора
|categorize = yes
}}

'''Королев Денис Александрович'''

==Образование==
* МИЭМ, 2002, Инженер. Вычислительные машины, комплексы, системы и сети

* МИЭМ, 2002, ППК Управление качеством

* МИЭМ, 2007, к.т.н. Компьютерные сети и телекоммуникации

* МИЭМ, 2008, доцент.

==Области знаний и интересов==
* Видеотехнологии, видеовещание в интернет.

* Онлайн-поддержка обучения.

==Место работы==
* МИЭМ НИУ ВШЭ, Департамент компьютерной инженерии

* МИЭМ НИУ ВШЭ, "Цифровой университет" (проект НИУ ВШЭ).

==Контакты==
* E-mail: ''d.korolev@gmail.com''

* Mobile/Telegram/Whatsapp: ''+79036103290''

* VK: ''http://vk.com/dkorolev79''

* Facebook: ''https://www.facebook.com/denis.korolev.msk''

Разработка сети доставки статического контента (проект)

2017-10-19T19:22:52Z

Dkorolev:

{{Карточка_проекта
|name=Разработка сети доставки статического контента
|mentor=Королев Денис
|mentor_login={{URLENCODE:Dkorolev|WIKI}}
|semester=Осень 2017
|course=2
|summer=on
|number_of_students=5-10
|categorize=yes
}}

=== Что это за проект? ===
Статический CDN -- это распределение нагрузки для обеспечения доступа множества пользователей к файлам. Используется для нагруженных веб-ресурсов, чтобы все зрители, пришедшие смотреть новую серию популярного сериала, получили ее на достойной скорости и без падения сервера от перегрузки. Для этого используется распределенное хранение, балансировка между серверами и каналами связи.

В данном проекте предлагается в качестве уже существующей распределенной среды хранения и передачи файлов использовать хранилище GoogleDrive, которое так удачно предлагает безлимитные аккаунты для корпоративных и академических доменов. Суть разработки состоит в решении задачи подстановки контента напрямую с серверов GoogleDrive, чтобы не пропускать трафик через серверы проекта.

Второй вопрос для решения -- лимит на количество обращений к файлу на GoogleDrive. Решается он путём создания копии файла и подмены ссылки на новый файл.

=== Чему вы научитесь? ===
* Погружение в работу с GoogleDrive

* Разработка UI/REST API

=== Какие начальные требования? ===
* Навыки веб-разработки.

=== Какие будут использоваться технологии? ===
* GoogleDrive API

=== Темы вводных занятий ===
1. Архитектура проекта. API, внешние связи и зависимости.

2. Специфические технологии и используемые инструменты.

3. Доступные ресурсы, организация доступа.

4. Разделение ролей

=== Направления развития ===
Это же немного хак. Есть "магический камень" (GoogleDrive), к нему нужен особый подход, чтобы использовать его не только как хотят авторы, но и немного иначе. Сколько ещё можно придумать интересных применений для этого ресурса -- жизнь покажет. Пока же туда успешно сохраняются записи трансляций с сервера (есть такой сервис on-air.pro), аккаунты используются для хранения многотерабайтных архивов медиаданных (очень удобно для ТВ и продакшенов) и т.д. Получится то, что в этом проекте описано, -- там же и хостинг для фото/видеогалерей и т.д.

=== Критерии оценки ===
Про работу и оценки почитайте здесь: https://d.pr/143bq

Постарайтесь отнестись к этому с пониманием. Очень часто бодрое начало длится 3-4 недели и потом наступает тишина. Очень хочется, чтобы проекты доводились до запуска, а вы получали опыт успешной разработки и, возможно, работу в этих проектах уже в другом статусе. Но пока это для вас учебная работа, поэтому будем придерживаться описанных по ссылке правил и критериев. Спасибо!

===Как записаться?===

В общем доступе есть порядка двадцати проектов, относящихся к области видеотехнологий (стриминг, доставка потоков и т.д.). Чтобы всем было проще, эти проекты объединим в четыре группы и при записи на проект выбирайте группу, а конкретный проект и вашу роль в нем мы обсудим уже в рабочем порядке.

http://wiki.cs.hse.ru/images/thumb/f/f0/Projects.PNG/800px-Projects.PNG

=== Ориентировочное расписание занятий ===
Более точное расписание будет ясно после утверждения графика факультативов, пока ориентируемся на вторник, среду или пятницу во второй половине дня (после 15-16 часов).

На самом деле, для общения (как индивидуального, так и группового) удобно использовать средства видеосвязи -- это не заменяет очных встреч, но отлично дополняет их за счет возможности оперативно решать задачи "здесь и сейчас", сидя за удобным вам рабочим местом. Практически все темы проектов подразумевают работу в сети.

Денис Королев,

https://www.hse.ru/staff/dkorolev (там есть ссылки на соцсети)

+7 903 610 3290 (месенджеры по вкусу)

d.korolev@gmail.com

Разработка сервиса воспроизведения Video on Demand (проект)

2017-10-19T19:22:42Z

Dkorolev:

{{Карточка_проекта
|name=Разработка сервиса воспроизведения Video on Demand
|mentor=Королев Денис
|mentor_login={{URLENCODE:Dkorolev|WIKI}}
|semester=Осень 2017
|course=2
|summer=on
|number_of_students=5-10
|categorize=yes
}}

=== Что это за проект? ===
Задача -- разработать сервис, который будет воспроизводить видеозаписи, хранящиеся на Google Drive или указанном WebDAV/FTP сервере по команде или по расписанию, и формировать из них поток RTSP/RTMP. К этому сервису нужен веб-интерфейс и REST API для автоматического взаимодействия. Помимо этого, он должен поддерживать управление через ONVIF, определяясь для остальных устройств как NVR.

Сервис нужен для следующих типовых задач:

1. Воспроизведение в поток по расписанию заготовленных записей. Это нужно для публикации стримов в соцсети (если залить файл, то соцсеть это событие никак не продвигает, а если отправить стрим, то такой контент имеет приоритет для соцсети и его проще продвигать в массы.

2. При воспроизведении по расписанию (по времени, по триггеру) совместно с потоковым микшером можно формировать канал постоянного вещания, переключая микшер на записи по плейлисту и запуская их. При этом хранение контента -- в облаке.

3. При работе с облачным видеомикшером любые записи из архива могут быть включены в эфир.

4. Дополнение к сервису видеозаписи потоков (вместе они образуют полноценный "магнитофон").

Сервис предназначен для формирования видеопотока из видеозаписей. Хранение записей: GoogleDrive, работа по расписанию, по нажатию кнопки. Интерфейс загрузки, каталог пользовательских записей, представление на таймлайне и в календаре (API Google Calendar). Пригодятся: Ruby on Rails, OAuth, соответствующие API. Дополнительно: headless браузер с передачей данных для ввода на странице для формирования потоков с веб-страниц (вебинары и тд). Проект групповой. Правила работы: https://d.pr/143bq

=== Чему вы научитесь? ===
Сам по себе процесс запуска воспроизведения из файла в поток -- дело нехитрое: ffmpeg одной простой командой отправит на нужный адрес поток RTMP, а FFSERVER, VLC или аналогичный сервер сформирует RTSP поток, который в реальном времени может забрать любой потребитель (микшер, матрица, монитор и тд). Прочитать файл с аккаунта на GoogleDrive тоже задача не выдающаяся, хотя и полезная в жизненных ситуациях, учитывая, что этот сервис предлагает безлимитные аккаунты.
Здесь важно обеспечить управляемость и низкую задержку выполнения команды, а также совместимость с ONVIF. К пользовательскому интерфейсу, если его делать "со всеми удобствами", тоже довольно серьезные требования по отзывчивости (хотя, в минимальной версии этот сервис может иметь весьма аскетичный интерфейс).

=== Какие начальные требования? ===
* Навыки или страстное желание освоить веб-разработку, крайне желательно придерживаться Ruby on Rails.

* Владение Linux (придется работать с сервером на виртуальной машине),

* API соцсетей (опционально)

=== Какие будут использоваться технологии? ===
* Стриминг RTSP/RTMP

* GoogleDrive API, WebDAV, FTP

* ONVIF

* OAuth

=== Темы вводных занятий ===
Не в порядке изложения:

1. Архитектура проекта. API, внешние связи и зависимости.

2. Специфические технологии и используемые инструменты.

3. Доступные ресурсы, организация доступа.

4. Разделение ролей

=== Направления развития ===
Это специфический инструмент. Есть системы управления контентом, типа XIBO, есть playout-серверы для телевизионного вещания или для indoor-TV (панели в супермаркетах и других общественных местах), но здесь решается узкая задача: как контент из облака или своего сервера отправить в поток для дальнейшего использования.
Как аналог одного из применений, можно назвать BufferApp - сервис отложенного постинга сообщений в соцсети. Здесь тоже по расписанию, но отправка видеопотоков (интеграция с API сетей может быть вынесена в отдельный проект).

Если рассматривать развитие проекта как самостоятельного сервиса, то он может объединиться с рекордером и работать с облачным хранилищем. Полезно не только для телевизионного применения, но и в более обширной области видеонаблюдения (обычно для этого используют локально установленные сетевые видеорекордеры) и в связанных с ней задачах -- наблюдение с выводом в публичный доступ и т.д. Бывали заказы на timelapse строящихся объектов.

=== Критерии оценки ===
Про работу и оценки почитайте здесь: https://d.pr/143bq

Постарайтесь отнестись к этому с пониманием. Очень часто бодрое начало длится 3-4 недели и потом наступает тишина. Очень хочется, чтобы проекты доводились до запуска, а вы получали опыт успешной разработки и, возможно, работу в этих проектах уже в другом статусе. Но пока это для вас учебная работа, поэтому будем придерживаться описанных по ссылке правил и критериев. Спасибо!

===Как записаться?===

В общем доступе есть порядка двадцати проектов, относящихся к области видеотехнологий (стриминг, доставка потоков и т.д.). Чтобы всем было проще, эти проекты объединим в четыре группы и при записи на проект выбирайте группу, а конкретный проект и вашу роль в нем мы обсудим уже в рабочем порядке.

http://wiki.cs.hse.ru/images/thumb/f/f0/Projects.PNG/800px-Projects.PNG
===Как записаться?===

В общем доступе есть порядка двадцати проектов, относящихся к области видеотехнологий (стриминг, доставка потоков и т.д.). Чтобы всем было проще, эти проекты объединим в четыре группы и при записи на проект выбирайте группу, а конкретный проект и вашу роль в нем мы обсудим уже в рабочем порядке.

http://wiki.cs.hse.ru/images/thumb/f/f0/Projects.PNG/800px-Projects.PNG

=== Ориентировочное расписание занятий ===
Более точное расписание будет ясно после утверждения графика факультативов, пока ориентируемся на вторник, среду или пятницу во второй половине дня (после 15-16 часов).

На самом деле, для общения (как индивидуального, так и группового) удобно использовать средства видеосвязи -- это не заменяет очных встреч, но отлично дополняет их за счет возможности оперативно решать задачи "здесь и сейчас", сидя за удобным вам рабочим местом. Практически все темы проектов подразумевают работу в сети.

Денис Королев,

https://www.hse.ru/staff/dkorolev (там есть ссылки на соцсети)

+7 903 610 3290 (месенджеры по вкусу)

d.korolev@gmail.com

Разработка сервиса Speech-to-text на базе существующего API (проект)

2017-10-19T19:22:13Z

Dkorolev:

{{Карточка_проекта
|name=Разработка сервиса Speech-to-text на базе существующего API
|mentor=Королев Денис
|mentor_login={{URLENCODE:Dkorolev|WIKI}}
|semester=Осень 2017
|course=2
|summer=on
|number_of_students=5-10
|categorize=yes
}}

=== Что это за проект? ===
Разработка в уже действиующем проекте, направления работы -- от UI/UX до предобработки потоков и анализа и обработки результатов распознавания и перевода.

Суть проекта: пользователь загружает видео- или аудио-файл, файл преобразуется для отправки в один или несколько сервисов распознавания, далее результат высылается на электронную почту пользователя.

Сервисов распознавания и перевода существует много, но всилу специфики их назначения и произвольного характера поступающих от пользователей исходных файлов, требуется предобработка и последующая сборка результатов. Взаимодействие со сторонними сервисами -- через API. При этом, различные сервисы по-разному воспринимают особенности исходных записей. Например, одни не любят телефонные разговоры, а другие -- многоголосые записи. Стоимость обработки также различается.

Отдельное направление -- разработка личного кабинета со статистикой, сохранением результатов ранее проведенных распознаваний и исходных файлов (файлы сохраняются на аккаунте GoogleDrive). В том числе, требуется поддержка обработки папок (GoogleDrive, FTP, WebDAV) в качестве источников файлов и места сохранения результатов.

Также отдельный подпроект -- подключение не только распознавания, но и перевода (также через API).

Результаты распознавания и перевода могут быть представлены как простым текстом, так и размеченным таймкодами, облаком тегов и т.д.

Заметим, что операции распознавания и перевода доступны в реальном времени и одной из задач (на практике уже проверено -- работает) будет реализовать для пользователей возможность давать на вход сервиса не только файлы, но и потоки, а на выходе -- поток субтитров, в т.ч. автоматически стримить в Yotube.

Разработка на Ruby on Rails.

=== Чему вы научитесь? ===
В зависимости от выбранного направления работы:

* работа с API сторонних сервисов

* предобработка потоков (gstreamer, ffmpeg)

* UI/UX разработка

* OAuth, работа с платежной системой

* Работа с хранилищами файлов (GoogleDrive, WebDAV, FTP)

Задачи разносторонние, поэтому каждый найдет себе что-то по вкусу.

=== Какие начальные требования? ===
В зависимости от выбранного направления -- владение соответствующими технологиями и языками. Очевидно, потребуется знать или изучить большинство используемых инструментов и языков.

=== Какие будут использоваться технологии? ===
* API сервисов распознавания и перевода, Google Drive и Youtube, ЯндексКассы.

* Ruby on Rails, Java Script

* Анализ видео- и аудиофайлов, их предобработка

* Анализ текстов и их обработка

=== Темы вводных занятий ===
Не в порядке изложения:

1. Архитектура проекта. API, внешние связи и зависимости.

2. Специфические технологии и используемые инструменты.

3. Доступные ресурсы, организация доступа.

4. Разделение ролей

=== Направления развития ===
Сейчас этот сервис работает лишь для распознавания голосовых записей, может работать с потоками (но для пользователей эта возможность закрыта, а так титры в Youtube делаются на лету), при этом выдача распознанных файлов приходит пользователю с таймкодами. Но это пока очень сырой проект, выросший из прошлогодней курсовой работы в МИЭМ. В развитие видятся следующие направления:

* Повышение качества распознавания -- не только подбором провайдера сервиса распознавания (сейчас Google, тестируются два других), но и предобработкой (особенно шумных и искаженных сжатием) записей и анализом результирующего текста, возможно, по дублирующему результату от альтернативного провайдера;

* Введение распознавания графических образов из видео (про это есть отдельный проект). Актуально для мониторинговых компаний, которые распознают телевизионный эфир (а там много интересного пишут в lower third и не только);

* Пользовательский интерфейс для всего этого. Сейчас его можно сказать что нет.

Помимо этого предстоит много сделать для интеграции в рабочие процессы заказчиков. Например, обработку папок в облачных дисках и по адресам ftp/webdav вместо загрузки файлов непосредственно на сайте.

=== Критерии оценки ===
Про работу и оценки почитайте здесь: https://d.pr/143bq

Постарайтесь отнестись к этому с пониманием. Очень часто бодрое начало длится 3-4 недели и потом наступает тишина. Очень хочется, чтобы проекты доводились до запуска, а вы получали опыт успешной разработки и, возможно, работу в этих проектах уже в другом статусе. Но пока это для вас учебная работа, поэтому будем придерживаться описанных по ссылке правил и критериев. Спасибо!

===Как записаться?===

В общем доступе есть порядка двадцати проектов, относящихся к области видеотехнологий (стриминг, доставка потоков и т.д.). Чтобы всем было проще, эти проекты объединим в четыре группы и при записи на проект выбирайте группу, а конкретный проект и вашу роль в нем мы обсудим уже в рабочем порядке.

http://wiki.cs.hse.ru/images/thumb/f/f0/Projects.PNG/800px-Projects.PNG

=== Ориентировочное расписание занятий ===
Более точное расписание будет ясно после утверждения графика факультативов, пока ориентируемся на вторник, среду или пятницу во второй половине дня (после 15-16 часов).

На самом деле, для общения (как индивидуального, так и группового) удобно использовать средства видеосвязи -- это не заменяет очных встреч, но отлично дополняет их за счет возможности оперативно решать задачи "здесь и сейчас", сидя за удобным вам рабочим местом. Практически все темы проектов подразумевают работу в сети.

Денис Королев,

https://www.hse.ru/staff/dkorolev (там есть ссылки на соцсети)

+7 903 610 3290 (месенджеры по вкусу)

d.korolev@gmail.com

Разработка редактора компоновок для сервиса потокового видеовещания (проект)

2017-10-19T19:21:54Z

Dkorolev:

{{Карточка_проекта
|name=Разработка редактора компоновок для сервиса потокового видеовещания
|mentor=Королев Денис
|mentor_login={{URLENCODE:Dkorolev|WIKI}}
|semester=Осень 2017
|course=2
|summer=on
|number_of_students=5-10
|categorize=yes
}}

=== Что это за проект? ===
Редактор компоновок позволяет из нескольких видеопотоков собрать на одном экране композицию, загрузить/выбрать фон, добавить текстовые и графические элементы. Используется в прямых трансляциях, записи, подключается к микшеру потоков или непосредственно к источнику трансляции. Это не видеомикшер в обычном понимании (про видеомикшер есть отдельная тема), а отдельный модуль, использующий тот же движок, но для формирования составной картинки, использоваться выходной поток может как сам по себе (сразу в трансляцию/запись), так и в микшере среди прочих входов.
Основная область применения -- трансляция лекций и других мероприятий, где одновременно нужно показывать выступающего и экран, при этом, нет ресурсов на режиссуру в эфире. Здесь важно иметь возможность сделать 2-3 компоновки, заставку и переключать их время от времени в зависимости от происходящего. Высоких требований к скорости выполнения, как в микшере, нет (2-3 секунды задержки не критичны). С другой стороны, здесь требуется создать конструктор компоновок и интерфейс управления ими во время эфира, и всё это на том же движке, что микшер.
В развитие проекта для интересующихся соответствующими направлениями можно предложить автопереключение компоновок (анализ потоков на изменения и принятие режиссерских решений).

=== Чему вы научитесь? ===
Как и в Микшере, работа связана с движком на базе gstreamer -- само по себе познавательное дело, т.к. применимость gstreamer'а не ограничивается сведением пото созданием отзывчивого пользовательского интерфейса.

В зависимости от комплектации группы, будет разрабатываться больше или меньше возможностей. Например, полезный в этой области навык -- анализ потоков для дальнейшего принятия режиссерских решений. Интересующимся этой темой может быть полезно заглянуть в проекты про автоматическую съёмку и автоматическую режиссуру.

Коротко о связи с реальностью: изначально именно компоновки были соновной идеей On-air.pro, который строился как публичный сервис для трансляции лекций с нескольких источников. Но всилу ограничений используемого движка компоновки не стали киллер-фичей, зато сервис увлеченно транслирует в соцсети. Тем не менее, как только созреет микшер, редактор компоновок и другие модули, выставленные на проработку, они займут своё место в проекте.

=== Организация работы (Как студенты будут работать в команде?) ===
Роли и точный состав работ формируется по итогам регистрации желающих участвовать (команда может быть смешанной, в т.ч. со студентами МИЭМ и других факультетов, аналогичная тема заявлена на ярмарке проектов.

Далее организуется slack и трекер (обычно trello), где ведется рабочее общение и трекинг задач.
Встречи -- по договоренности (на первых порах это понадобится точно) на Кочновском, альтернативный и более частый вариант -- аудио/видеосвязь. Удобно, т.к. можно собираться по актуальному вопросу безотлагательно и в любое время в любом составе.

=== Какие начальные требования? ===
В любом случае понадобятся навыки программирования (будь то веб-разработка или работа с движком GStreamer/Snowmix), работы с Linux (потому что виртуалка в сети). Остальное -- специфика, с которой можно познакомиться по ходу проекта. Веб-часть на Ruby on Rails -- для унификации с базовым проектом.

Ожидается, что разработчики умеют пользоваться поисковыми системами и stackoverflow. Руководитель может консультировать вас по предметной области (видео/тв), но не по программной разработке.

Разработка обычно имеет недельный цикл трекинга, встречи (как индивидуальные, так и групповые) по умолчанию -- по видеосвязи, но порой надо и очно (на факультете). Необходимые технические и серверные ресурсы предоставляются.

=== Какие будут использоваться технологии? ===
* Gstreamer и с ним Snowmix/Voctomix, возможно -- ffmpeg

* Виртуальные машины linux, nginx и сопутствующие инструменты

* Ruby on Rails (для унификации) и необходимые средства для UI (например, meteor, это ещё нужно обоснованно решить).

* Опционально: ONVIF для управления камерами (переход по предустановленным позициям)

=== Темы вводных занятий ===
Не в порядке изложения:

1. Архитектура проекта. API, внешние связи и зависимости.

2. Специфические технологии и используемые инструменты.

3. Доступные ресурсы, организация доступа.

4. Разделение ролей

=== Направления развития ===
Редактор компоновок -- это компонент потокового видеомикшера, причём, этот проект актуален безотносительно того, в каком виде будет реализован видеомикшер -- в "скромном", для скрытого выполнения операций с видеопотоками (поставить логотип/титры, переключиться на заставку при пропадении входного потока, переключиться на другой источник), или в "полноценном", то есть, с пользовательским интерфейсом видеомикшера, со всеми подобающими кнопками, экранами и т.д. В любом случае, мультиэкранное изображение нужно,а для этого, помимо движка микшера, нужно иметь интерфейс для его создания: как с нуля, так и из готовых пресетов. В свою очередь, конструктор компоновок и титровальня -- это лишь с виду простые программы, на деле же там может быть заложено много интересных возможностей, вплоть до автоматического распознавания лиц на крупном плане, чтобы рекомендовать правильные титры.

=== Критерии оценки ===
Про работу и оценки почитайте здесь: https://d.pr/143bq

Постарайтесь отнестись к этому с пониманием. Очень часто бодрое начало длится 3-4 недели и потом наступает тишина. Очень хочется, чтобы проекты доводились до запуска, а вы получали опыт успешной разработки и, возможно, работу в этих проектах уже в другом статусе. Но пока это для вас учебная работа, поэтому будем придерживаться описанных по ссылке правил и критериев. Спасибо!

===Как записаться?===

В общем доступе есть порядка двадцати проектов, относящихся к области видеотехнологий (стриминг, доставка потоков и т.д.). Чтобы всем было проще, эти проекты объединим в четыре группы и при записи на проект выбирайте группу, а конкретный проект и вашу роль в нем мы обсудим уже в рабочем порядке.

http://wiki.cs.hse.ru/images/thumb/f/f0/Projects.PNG/800px-Projects.PNG

=== Ориентировочное расписание занятий ===
Более точное расписание будет ясно после утверждения графика факультативов, пока ориентируемся на вторник, среду или пятницу во второй половине дня (после 15-16 часов).

На самом деле, для общения (как индивидуального, так и группового) удобно использовать средства видеосвязи -- это не заменяет очных встреч, но отлично дополняет их за счет возможности оперативно решать задачи "здесь и сейчас", сидя за удобным вам рабочим местом. Практически все темы проектов подразумевают работу в сети.

Денис Королев,

https://www.hse.ru/staff/dkorolev (там есть ссылки на соцсети)

+7 903 610 3290 (месенджеры по вкусу)

d.korolev@gmail.com

Разработка программного модуля управления ONVIF-совместимыми IP PTZ камерами (проект)

2017-10-19T19:21:43Z

Dkorolev:

{{Карточка_проекта
|name=Разработка программного модуля управления ONVIF-совместимыми IP PTZ камерами
|mentor=Королев Денис
|mentor_login={{URLENCODE:Dkorolev|WIKI}}
|semester=Осень 2017
|course=2
|summer=on
|number_of_students=5-10
|categorize=yes
}}

=== Что это за проект? ===
Для управления цифровыми камерами видеонаблюдения существует ряд программ и устройств, использующих единый стандарт ONVIF. Но ни одна из этих программ и ни одно устройство не предназначены для управления камерами в "операторской манере", когда движения совершаются плавно и сразу по трем измерениям (поворот/наклон/увеличение -- PTZ). Также, камеры могут настраиваться по многим параметрам изображения, в некоторых камерах есть поддержка звука, но эти параметры не регулируются устройствами, предназначенными для видеонаблюдения.

Нужно разработать сервис управления ONVIF PTZ камерами. Взаимодействие с пользователем через веб-интерфейс с поддержкой наборов камер в личном кабинете, с сохранением пресетов.

Специфические особенности, отличающие от существующих программ и веб-интерфейса самих камер:

1. "Операторское" движение камеры (одновременное и плавное перемещение по всем трём осям)

2. Настройка "на лету" параметров изображения, звука и потока.

3. Предусмотреть возможность подключения автоматического трекера и автоцветокоррекции (см. соседние проекты и проекты на Ярмарке проектов: https://pf.hse.ru/208027417.html https://pf.hse.ru/208027466.html)

Для локального использования предусмотреть установку под Windows, по умолчанию установка на linux-сервере с VPN, экспериментально -- на роутерах с прошивкой OpenWRT.

=== Чему вы научитесь? ===
* Тонкое управление устройствами (IP PTZ камерами) по протоколу ONVIF

* Имитация работы оператора-человека

* Создание сервиса управления, работающего на различных платформах

* Создание отзывчивого веб-интерфейса для управления камерой.

=== Какие начальные требования? ===
Иметь представление о веб-разработке. при этом, больше внимания уделить JS и отзывчивому пользовательскому интерфейсу.

Работа с ONVIF возможна на разных языках, язык выбирается так, чтобы результат запускался на указанных платформах.

=== Какие будут использоваться технологии? ===
* ONVIF

* Разработать REST API

* AJAX и другие элементы разработки отзывчивого UI

=== Темы вводных занятий ===
1. Архитектура проекта. API, внешние связи и зависимости.

2. Специфические технологии и используемые инструменты.

3. Доступные ресурсы, организация доступа.

4. Разделение ролей

=== Направления развития ===
Это один из проектов, имеющих в будущем общее будущее: объединение возможностей управления PTZ IP камерами, включая автоматическую съёмку (в т.ч. с трекингом человека), автоцвето/экспокоррекцию и т.д. сделает дешевые и вполне качественные IP камеры серьезным конкурентом современным дорогостоящим телевизионным камерам, требующим не менее дорогостоящих компонентов для сборки съёмочных комплексов. Здесь же мы обходимся обычными компьютерами и локальной сетью, при этом можем строить полностью распределенные съёмочные комплексы, где режиссер, камеры и операторы могут находиться в разных местах.

=== Критерии оценки ===
Про работу и оценки почитайте здесь: https://d.pr/143bq

Постарайтесь отнестись к этому с пониманием. Очень часто бодрое начало длится 3-4 недели и потом наступает тишина. Очень хочется, чтобы проекты доводились до запуска, а вы получали опыт успешной разработки и, возможно, работу в этих проектах уже в другом статусе. Но пока это для вас учебная работа, поэтому будем придерживаться описанных по ссылке правил и критериев. Спасибо!

===Как записаться?===

В общем доступе есть порядка двадцати проектов, относящихся к области видеотехнологий (стриминг, доставка потоков и т.д.). Чтобы всем было проще, эти проекты объединим в четыре группы и при записи на проект выбирайте группу, а конкретный проект и вашу роль в нем мы обсудим уже в рабочем порядке.

http://wiki.cs.hse.ru/images/thumb/f/f0/Projects.PNG/800px-Projects.PNG

=== Ориентировочное расписание занятий ===
Более точное расписание будет ясно после утверждения графика факультативов, пока ориентируемся на вторник, среду или пятницу во второй половине дня (после 15-16 часов).

На самом деле, для общения (как индивидуального, так и группового) удобно использовать средства видеосвязи -- это не заменяет очных встреч, но отлично дополняет их за счет возможности оперативно решать задачи "здесь и сейчас", сидя за удобным вам рабочим местом. Практически все темы проектов подразумевают работу в сети.

Денис Королев,

https://www.hse.ru/staff/dkorolev (там есть ссылки на соцсети)

+7 903 610 3290 (месенджеры по вкусу)

d.korolev@gmail.com

Разработка программного адаптера ONVIF устройств для видеомикшера VMix (проект)

2017-10-19T19:21:32Z

Dkorolev:

{{Карточка_проекта
|name=Разработка программного адаптера ONVIF устройств для видеомикшера VMix
|mentor=Королев Денис
|mentor_login={{URLENCODE:Dkorolev|WIKI}}
|semester=Осень 2017
|course=2
|summer=on
|number_of_students=5-10
|categorize=yes
}}

=== Что это за проект? ===
Небольшой проект для решения узкой, но актуальной задачи. Для монтажа многокамерной видеосъёмки и трансляции используют как аппаратные, так и программные видеомикшеры. Один из наиболее удобных и функциональных программных микшеров -- VMix, он не только поддерживает работу с различным оборудованием захвата сигнала с камер, но и прекрасно работает с RTSP-потоками от IP-камер, а значит, с ним совместимы все камеры видеонаблюдения при их низкой стоимости и гибкости настройки. В частности, из VMix можно задать несколько позиций поворота одной камеры и переходить между ними в прямом эфире, как между разными камерами (virtual input), что облегчает работу режиссера (и исключает необходимость в операторе) в прямом эфире. Но разработчики VMix ориентировались на рынок профессионального телевизионного оборудования и для управления камерами включили только проприетарные стандарты дорогих камер, в то время как системы видеонаблюдения давно используют единый открытый стандарт для всех видов используемого оборудования -- ONVIF. Задача: сделать прокси-адаптер, который будет транслировать команды VMix в команды ONVIF. Прототип такой программы уже сделан, но довести его до продукта, сделать локальную версию для Windows (как службу + интерфейс управления) и сетевую для Linux-сервера -- это ещё предстоит.

Минимальный проект: Помимо 11 команд и 2 настроек для управления PTZ, понадобится управлять Alarm-статусами камеры (так можно зажигать индикатор "камера в эфире", его называют Tally).

Расширенный проект: Настройка камер включает экспо- и цветокоррекцию, причём, не коррекцию потоков, а настройку самих камер через ONVIF. Эта задача вынесена в отдельный проект (здесь и в ярмарке проектов), но может быть реализована в рамках данного проекта.

=== Чему вы научитесь? ===
* Управление видеокамерами IP PTZ через ONVIF

* Автоматизация рутинных процедур в видеопроизводстве

* Интеграция ПО с видеомикшером VMix, оптимизация рабочего процесса

В расширенном проекте:

* Анализ видеопотоков

=== Какие начальные требования? ===
Существующая версия написана на C# в VisualStudio, но это несколько странно для работы на Linux-сервере. Особых требований по языку разработки нет, исходить нужно из оценки пригодности выбранных инструментов для работы с ONVIF и названными ОС.

Для управления можно использовать веб-интерфейс, иначе придется делать приложение "в трее" для Windows.

=== Какие будут использоваться технологии? ===
* ONVIF -- управление оборудованием видеонаблюдения

* Служба для Windows и аналогичной версии для сервера под Linux.

=== Темы вводных занятий ===
Не в порядке изложения:

1. Специфические технологии и используемые инструменты.

2. Доступные ресурсы, организация доступа.

3. Разделение ролей

=== Направления развития ===
От небольшой утилиты-адаптера (или небольшого служебного сервиса) эта программа может вырасти в полноценный продукт для IP-video продакшена. IP-камеры в последние годы стали снимать вполне качественно и могут конкурировать с классическими, при этом имея массу преимуществ по управляемости. Проект в будущем должен объединить в себя возможности управления, монитоирнга, конфигурирования этих камер (включая трекинг людей и автосъёмку вообще, автокоррекцию параметров изображения при многокамерной съёмке и т.д.).

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

=== Критерии оценки ===
Про работу и оценки почитайте здесь: https://d.pr/143bq

Постарайтесь отнестись к этому с пониманием. Очень часто бодрое начало длится 3-4 недели и потом наступает тишина. Очень хочется, чтобы проекты доводились до запуска, а вы получали опыт успешной разработки и, возможно, работу в этих проектах уже в другом статусе. Но пока это для вас учебная работа, поэтому будем придерживаться описанных по ссылке правил и критериев. Спасибо!

===Как записаться?===

В общем доступе есть порядка двадцати проектов, относящихся к области видеотехнологий (стриминг, доставка потоков и т.д.). Чтобы всем было проще, эти проекты объединим в четыре группы и при записи на проект выбирайте группу, а конкретный проект и вашу роль в нем мы обсудим уже в рабочем порядке.

http://wiki.cs.hse.ru/images/thumb/f/f0/Projects.PNG/800px-Projects.PNG

=== Ориентировочное расписание занятий ===
Более точное расписание будет ясно после утверждения графика факультативов, пока ориентируемся на вторник, среду или пятницу во второй половине дня (после 15-16 часов).

На самом деле, для общения (как индивидуального, так и группового) удобно использовать средства видеосвязи -- это не заменяет очных встреч, но отлично дополняет их за счет возможности оперативно решать задачи "здесь и сейчас", сидя за удобным вам рабочим местом. Практически все темы проектов подразумевают работу в сети.

Денис Королев,

https://www.hse.ru/staff/dkorolev (там есть ссылки на соцсети)

+7 903 610 3290 (месенджеры по вкусу)

d.korolev@gmail.com

Разработка модуля распознавания текста из видеоизображения (проект)

2017-10-19T19:21:12Z

Dkorolev:

{{Карточка_проекта
|name=Разработка модуля распознавания текста из видеоизображения
|mentor=Королев Денис
|mentor_login={{URLENCODE:Dkorolev|WIKI}}
|semester=Осень 2017
|course=2
|summer=on
|number_of_students=5-10
|categorize=yes
}}

=== Что это за проект? ===
Распознавание текста из видео/фото изображений дополняет сервис распознавания голоса из аудио и видео (как файлов, так и потоков).

Основная область применения -- мониторинг телевизионных программ различными мониторинговыми службами. Основной объект для распознавания -- бегущие строки и субтитры (lower thirds), но на деле объекты могут быть не только текстовыми (вылавливать логотипы и другие эталонные изображения и надписи, регистрировать их размер).

=== Чему вы научитесь? ===
Обработка видеопотоков, файлов и фотоизображений с целью распознавания текстов и изображений по заданным шаблонам.

=== Какие начальные требования? ===
В зависимости от роли в проекте:

* OpenCV и навыки работы с распознаванием изображений.

* Веб-разработка на Ruby on Rails

=== Какие будут использоваться технологии? ===
* Разработка на Ruby on Rails, JavaScript

* Распознавание -- OpenCV + C++/Python

* API GoogleDrive, работа с хранилищами FTP/WebDAV

=== Темы вводных занятий ===
Не в порядке изложения:

1. Архитектура проекта. API, внешние связи и зависимости.

2. Специфические технологии и используемые инструменты.

3. Доступные ресурсы, организация доступа.

4. Разделение ролей

=== Направления развития ===
Графическая часть сервиса распознавания дополняет голосовую (изначально это сервис распознавания голоса в текст), также там предусмотрено подключение перевода. Комплексная услуга позволяет покрывать значительную часть запросов, но требует и более тщательной разработки интерфейса пользователя, и сами "распознаватели" зачастую требуется дублировать и перепроверять возможными автоматическими способами, чтобы снизить уровень ошибок. Проект развивается в настоящее время в сторону комплексного сервиса, обслуживающего как запросы частных клиентов, так и интегрируемого в корпоративный рабочий процесс, в т. ч. для профильных компаний (медиаизмерители, HR, колцентры, журналисты, продакшены и тд).

=== Критерии оценки ===
Про работу и оценки почитайте здесь: https://d.pr/143bq

Постарайтесь отнестись к этому с пониманием. Очень часто бодрое начало длится 3-4 недели и потом наступает тишина. Очень хочется, чтобы проекты доводились до запуска, а вы получали опыт успешной разработки и, возможно, работу в этих проектах уже в другом статусе. Но пока это для вас учебная работа, поэтому будем придерживаться описанных по ссылке правил и критериев. Спасибо!

===Как записаться?===

В общем доступе есть порядка двадцати проектов, относящихся к области видеотехнологий (стриминг, доставка потоков и т.д.). Чтобы всем было проще, эти проекты объединим в четыре группы и при записи на проект выбирайте группу, а конкретный проект и вашу роль в нем мы обсудим уже в рабочем порядке.

http://wiki.cs.hse.ru/images/thumb/f/f0/Projects.PNG/800px-Projects.PNG

=== Ориентировочное расписание занятий ===
Более точное расписание будет ясно после утверждения графика факультативов, пока ориентируемся на вторник, среду или пятницу во второй половине дня (после 15-16 часов).

На самом деле, для общения (как индивидуального, так и группового) удобно использовать средства видеосвязи -- это не заменяет очных встреч, но отлично дополняет их за счет возможности оперативно решать задачи "здесь и сейчас", сидя за удобным вам рабочим местом. Практически все темы проектов подразумевают работу в сети.

Денис Королев,

https://www.hse.ru/staff/dkorolev (там есть ссылки на соцсети)

+7 903 610 3290 (месенджеры по вкусу)

d.korolev@gmail.com

Разработка модуля автоматизации видеомонтажа в прямом эфире (проект)

2017-10-19T19:21:00Z

Dkorolev:

{{Карточка_проекта
|name=Разработка модуля автоматизации видеомонтажа в прямом эфире
|mentor=Королев Денис
|mentor_login={{URLENCODE:Dkorolev|WIKI}}
|semester=Осень 2017
|course=2
|summer=on
|number_of_students=5-10
|categorize=yes
}}

=== Что это за проект? ===
Если вы снимаете какое-нибудь событие (конференцию, защиты выпускных работ или другое разговорное событие) на одну камеру, то запись, монтаж и трансляция особой проблемы не представляют -- просто нечего монтировать, разве что подрезать. Транслировать такое событие тоже просто. Стоит добавить к этой одной камере хотя бы захват экрана презентации, начинаются сложности. А если камер несколько, выступающий общается с залом, из президиума что-то комментируют -- здесь обычно нужен режиссер. На входе у режиссера несколько потоков, он выбирает, какой из потоков пойдет в запись/трансляцию в каждый момент времени.
Критерии выбора потока зависят от а) его содержательности и актуальности для зрителя в данный момент и б) от технической и эстетической готовности. Содержательность -- это значит, что показывают обычно либо говорящего, либо то, о чём он говорит (презентацию), либо и то и другое сразу (картинка в картинке). Техническая пригодность -- значит, камера в фокусе, не дрожит и готова передавать поток без помех. Эстетическая готовность -- камера наведена на объект съёмки с соблюдением требуемой композиции кадра и в допустимых пределах экспозиции и цветопередачи.

Переключение источников видеопотоков может быть автоматизировано и это реализовано в конференц-системах, где камеры поворачиваются на говорящего в микрофон на определенном месте. Но такие системы имеют простой алгоритм, основанный на предварительной настройке позиций камер на оснащённые места с индивидуальными микрофонами. В нашем случае нет возможности использовать дополнительные датчики и заранее настраивать камеры на определенные точки, задачу автоматизации режиссуры нужно решать для абстрактного случая "разговорного события".
Если общие правила монтажа и съёмки довольно легко описываются (например, длительность кадров в пределах 5-20 секунд, переходы по крупности плана -- через один, съёмка по правилу третей, при этом поворот головы к центру кадра, и т.д.), то выбор источников для включения и конкретных моментов для переходов -- это задача творческая и для ее решения могут привлекаться как обычные формальные методы (изменение содержания слайда, детекция говорящего человека на крупном плане и т.д.), так и нейросеть.

=== Чему вы научитесь? ===
* Распознавание движений и мимики человека

* Практика в OpenCV

* Составление формальных критериев для съёмки и монтажа

* Амбициозная задача -- лишить режиссеров работы, где это возможно! Пусть кино снимают, а здесь и машина управится.

=== Какие начальные требования? ===
* Программирование C++ или Python, желательно OpenCV

=== Какие будут использоваться технологии? ===
* Распознавание образов (OpenCV)

* Возможно: нейросети

=== Темы вводных занятий ===
1. Архитектура проекта. API, внешние связи и зависимости.

2. Специфические технологии и используемые инструменты.

3. Доступные ресурсы, организация доступа.

4. Разделение ролей

=== Направления развития ===
Автомонтаж -- это даже не технология, а мечта одних и ужас других (кому потом придется искать себе работу). По сути, большинство "режиссеров" днями напролет выполняют работу, с которой компьютер справится не хуже, а зачастую -- лучше. Никакого творчества в съёмке разговорных мероприятий обычно нет (речь не о топовых проектах крупных телеканалов, а о всевозможных конференциях, семинарах и тд -- их по количеству часов снимается подавляющее большинство). Развитие проекта востребовано в двух очевидных направлениях, в которых ныне существует классический монтаж:

* Линейный автомонтаж -- вместо линейного монтажа, это прямые эфиры и записи "телевизионным" способом (такой же прямой эфир, только в запись, потом можно подкорректировать).

* Нелинейный автомонтаж -- вместо обычного нелинейного мотнажа. Элементы такой автоматики уже кое-где встречаются, достаточно вспомнить, какие ролики время от времени подкидывает вам Facebook и Google+. Здесь полагаться приходится имеющийся материал, не всегда есть сведения о его синхронизации (многокамерную съёмку можно синхронизировать по звуку и по движениям в кадре), но для нелинейного монтажа обычно важнее сделать ролик с самым важным из имеющегося материала, а не собрать хронологически выстроенные записи и переключать планы, как в многокамерной телевизионной съёмке. Здесь есть время подумать, но и задачи более творческие.

Одной технологией пользоваться невозможно, поэтому важно "завернуть" алгоритмы в продукт. И здесь есть хороший шанс выйти на благодатную почву, т.к. этот (как и многие соседние в этом списке предлагаемых проектов) проект разрабатывается для уже действующего и постоянно развивающегося сервиса интернет-трансляций.

=== Критерии оценки ===
Про работу и оценки почитайте здесь: https://d.pr/143bq

Постарайтесь отнестись к этому с пониманием. Очень часто бодрое начало длится 3-4 недели и потом наступает тишина. Очень хочется, чтобы проекты доводились до запуска, а вы получали опыт успешной разработки и, возможно, работу в этих проектах уже в другом статусе. Но пока это для вас учебная работа, поэтому будем придерживаться описанных по ссылке правил и критериев. Спасибо!

===Как записаться?===

В общем доступе есть порядка двадцати проектов, относящихся к области видеотехнологий (стриминг, доставка потоков и т.д.). Чтобы всем было проще, эти проекты объединим в четыре группы и при записи на проект выбирайте группу, а конкретный проект и вашу роль в нем мы обсудим уже в рабочем порядке.

http://wiki.cs.hse.ru/images/thumb/f/f0/Projects.PNG/800px-Projects.PNG

=== Ориентировочное расписание занятий ===
Более точное расписание будет ясно после утверждения графика факультативов, пока ориентируемся на вторник, среду или пятницу во второй половине дня (после 15-16 часов).

На самом деле, для общения (как индивидуального, так и группового) удобно использовать средства видеосвязи -- это не заменяет очных встреч, но отлично дополняет их за счет возможности оперативно решать задачи "здесь и сейчас", сидя за удобным вам рабочим местом. Практически все темы проектов подразумевают работу в сети.

Денис Королев,

https://www.hse.ru/staff/dkorolev (там есть ссылки на соцсети)

+7 903 610 3290 (месенджеры по вкусу)

d.korolev@gmail.com

Разработка модулей ретрансляции видеопотоков на стриминговые платформы (проект)

2017-10-19T19:20:48Z

Dkorolev:

{{Карточка_проекта
|name=Разработка модулей ретрансляции видеопотоков на стриминговые платформы
|mentor=Королев Денис
|mentor_login={{URLENCODE:Dkorolev|WIKI}}
|semester=Осень 2017
|course=2
|summer=on
|number_of_students=5-10
|categorize=yes
}}

=== Что это за проект? ===
Потоковое вещание с 2016 года поддерживается практически всеми соцсетями, это модная тема и эффективное средство продвижения контента. Есть различные сервисы и приложения (как от самих сетей, так и сторонние), обеспечивающие вещание как в отдельные сети, так и в несколько одновременно. Для одного из таких сервисов (On-Air.Pro) требуется разработка связки с API соцсетей и сетей доставки контента. Это отдельные фрагменты кода, они должны пройти соответствующие тесты, далее они включаются в основной проект. Список сетей и конкретные задачи определяются на момент согласования темы, т.к. проект живой и развивается безотносительно участия студентов. В качестве примера можно привести Youtube streaming API -- новая версия вышла весной 2017 года, потребуется реализовать новые возможности.

Разработка на Ruby on Rails.

=== Чему вы научитесь? ===
Потоковое вещание с 2016 года поддерживается практически всеми соцсетями, это модная тема и эффективное средство продвижения контента. Есть различные сервисы и приложения (как от самих сетей, так и сторонние), обеспечивающие вещание как в отдельные сети, так и в несколько одновременно. Для одного из таких сервисов (On-Air.Pro) требуется разработка связки с API соцсетей и сетей доставки контента. Это отдельные фрагменты кода, они должны пройти соответствующие тесты, далее они включаются в основной проект.
Список сетей и конкретные задачи определяются на момент согласования темы, т.к. проект живой и развивается безотносительно участия студентов.
В качестве примера можно привести Youtube streaming API -- новая версия вышла весной 2017 года, потребуется реализовать новые возможности.

Разработка на Ruby on Rails.

=== Какие начальные требования? ===
Навыки программирования под веб (если вы планируете изучить Ruby on Rails по ходу работы, то ещё и способность быстро обучаться).

=== Какие будут использоваться технологии? ===
* REST API сторонних сервисов,

* Ruby on Rails,

* Разработка по тестам

=== Темы вводных занятий ===
Не в порядке изложения:

1. Архитектура проекта. API, внешние связи и зависимости.

2. Специфические технологии и используемые инструменты.

3. Доступные ресурсы, организация доступа.

4. Разделение ролей

=== Направления развития ===
Модули для интеграции с внешними сетями -- часть большого проекта, одной из ключевых возможностей которого является стриминг соцсети и планируется более плотное взаимодействие с ними. Здесь важнейшую роль играет интеграция через API и решение задач, возникающих при этом, а возможно, и, порой, обход ограничений (парсингом страниц, например).

На ярмарке проектов данная тема явно не выделена, но входит в этот проект: https://pf.hse.ru/208012056.html.

=== Критерии оценки ===
Про работу и оценки почитайте здесь: https://d.pr/143bq

Постарайтесь отнестись к этому с пониманием. Очень часто бодрое начало длится 3-4 недели и потом наступает тишина. Очень хочется, чтобы проекты доводились до запуска, а вы получали опыт успешной разработки и, возможно, работу в этих проектах уже в другом статусе. Но пока это для вас учебная работа, поэтому будем придерживаться описанных по ссылке правил и критериев. Спасибо!
===Как записаться?===

В общем доступе есть порядка двадцати проектов, относящихся к области видеотехнологий (стриминг, доставка потоков и т.д.). Чтобы всем было проще, эти проекты объединим в четыре группы и при записи на проект выбирайте группу, а конкретный проект и вашу роль в нем мы обсудим уже в рабочем порядке.

http://wiki.cs.hse.ru/images/thumb/f/f0/Projects.PNG/800px-Projects.PNG

=== Ориентировочное расписание занятий ===
Более точное расписание будет ясно после утверждения графика факультативов, пока ориентируемся на вторник, среду или пятницу во второй половине дня (после 15-16 часов).

На самом деле, для общения (как индивидуального, так и группового) удобно использовать средства видеосвязи -- это не заменяет очных встреч, но отлично дополняет их за счет возможности оперативно решать задачи "здесь и сейчас", сидя за удобным вам рабочим местом. Практически все темы проектов подразумевают работу в сети.

Денис Королев,

https://www.hse.ru/staff/dkorolev (там есть ссылки на соцсети)

+7 903 610 3290 (месенджеры по вкусу)

d.korolev@gmail.com

Разработка мобильного приложения "ONVIF камера" (проект)

2017-10-19T19:20:32Z

Dkorolev:

{{Карточка_проекта
|name=Разработка мобильного приложения "ONVIF камера"
|mentor=Королев Денис
|mentor_login={{URLENCODE:Dkorolev|WIKI}}
|semester=Осень 2017
|course=2
|summer=on
|number_of_students=5-10
|categorize=yes
}}

=== Что это за проект? ===
Любопытная особенность камер видеонаблюдения, которую призвано имитировать разрабатываемое приложение, -- это то, что они полностью контролируются дистанционно по стандартному протоколу. Если вы когда-нибудь снимали на обычные бытовые камеры, то знаете, что к чему их ни подключи, а настроить параметры изображения можно только с самой камеры, запустить запись -- тоже. И только в телевизионных комплексах оператор камеру направляет, а остальное настраивается со специального пульта, и это позволяет при съёмке с нескольких камер получать одинаковые параметры изображения (по цвету, свету, параметрам сигнала). Мобильный телефон уже давно стал устройством для стриминга, но стриминга "сырого" видео и обычно сразу к зрителю. От этого любительские трансляции в ВК и Фейсбуке выглядят хуже, чем любительское VHS в 90х: ни монтажа, ни смены планов.

Существует множество мобильных приложений для видеостриминга, но требуется специфическая разработка, которая превратит для внешнего наблюдателя обычный смартфон или планшет в камеру видеонаблюдения с присущими ей возможностями: поддержкой стандарта ONVIF (управление потоками, параметрами изображения и тд), формированием как минимум двух потоков RTSP со звуком AAC, веб-интерфейсом управления.

Таким образом, любой совместимый смартфон или планшет станет полноценным источником видеопотока для потокового микшера (например, VMix. Или для того, что разрабатывается в одном из соседних проектов). При использовании VPN можно использовать потоки от устройств, находящихся в любой точке мира, подключенной к интернет.

=== Чему вы научитесь? ===
* Разработка мобильного приложения (если ещё нет такого опыта). По умолчанию -- Android, если есть желающие работать под IOS, это тоже хорошо, проекты могут идти параллельно.

* Работа с камерой мобильного устройства для формирования RTSP потоков.

* Разработка ONVIF-совместимого ПО (используется всей инфраструктурой систем видеонаблюдения).

=== Какие начальные требования? ===
Навыки или желание освоить разработку мобильных приложений.

=== Какие будут использоваться технологии? ===
* JAVA (для Android)

* ONVIF

* RTSP сервер

* OpenVPN (опционально)

* Web-сервер для создания простого веб-интерфейса (опционально)

=== Темы вводных занятий ===
Не в порядке изложения:

1. Архитектура проекта. ONVIF, внешние связи и зависимости.

2. Специфические технологии и используемые инструменты.

3. Доступные ресурсы, организация доступа.

4. Разделение ролей

=== Направления развития ===
Существует программный видеомикшер VMix и он поддерживает проприетарный и относительно молодой протокол NDI, через который по сети можно легко передавать потоки с компьютера и даже с мобильника. Но они используют потоки в десятки мегабит/с и совместимых устройств (камер, например) единицы и цены на них -- "телевизионные". В нашем случае строится связка из мобильного приложения, микшера, сервиса стриминга в соцсети и CDN, при этом, рассчитанная на работу с доступными каналами связи (1-8 вместо 40 мбит/с). Проект имеет смысл и развитие и безотносительно самодельных микшеров, т.к. RTSP-камера может использоваться в программных микшерах (в том же Vmix).

=== Критерии оценки ===
Про работу и оценки почитайте здесь: https://d.pr/143bq

Постарайтесь отнестись к этому с пониманием. Очень часто бодрое начало длится 3-4 недели и потом наступает тишина. Очень хочется, чтобы проекты доводились до запуска, а вы получали опыт успешной разработки и, возможно, работу в этих проектах уже в другом статусе. Но пока это для вас учебная работа, поэтому будем придерживаться описанных по ссылке правил и критериев. Спасибо!
===Как записаться?===

В общем доступе есть порядка двадцати проектов, относящихся к области видеотехнологий (стриминг, доставка потоков и т.д.). Чтобы всем было проще, эти проекты объединим в четыре группы и при записи на проект выбирайте группу, а конкретный проект и вашу роль в нем мы обсудим уже в рабочем порядке.

http://wiki.cs.hse.ru/images/thumb/f/f0/Projects.PNG/800px-Projects.PNG

=== Ориентировочное расписание занятий ===
Более точное расписание будет ясно после утверждения графика факультативов, пока ориентируемся на вторник, среду или пятницу во второй половине дня (после 15-16 часов).

На самом деле, для общения (как индивидуального, так и группового) удобно использовать средства видеосвязи -- это не заменяет очных встреч, но отлично дополняет их за счет возможности оперативно решать задачи "здесь и сейчас", сидя за удобным вам рабочим местом. Практически все темы проектов подразумевают работу в сети.

Денис Королев,

https://www.hse.ru/staff/dkorolev (там есть ссылки на соцсети)

+7 903 610 3290 (месенджеры по вкусу)

d.korolev@gmail.com

Разработка микшера видеопотоков RTSP/RTMP (проект)

2017-10-19T19:20:21Z

Dkorolev:

{{Карточка_проекта
|name=Разработка микшера видеопотоков RTSP/RTMP
|mentor=Королев Денис
|mentor_login={{URLENCODE:Dkorolev|WIKI}}
|semester=Осень 2017
|course=2
|summer=on
|number_of_students=5-10
|categorize=yes
}}

=== Что это за проект? ===
Все, наверное, видели, как в телевизионной аппаратной режиссер эфира сидит за пультом,смотрит в стену с мониторами и жмет кнопки. И рядом сидят его коллеги и тоже что-то напряженно делают. Прямой эфир -- это всегда напряжение и ответственность, для его проведения требуются опыт и квалификация. А ещё -- дорогостоящее оборудование и провода до камер (или спутниковые каналы связи). Так было и так есть сейчас. Наша задача -- перенести возможности профессионального телевидения в реальность, где нет таких бюджетов, зато есть доступная цифровая техника, интернет и уже существуют все необходимые компоненты, чтобы сделать телевизионную аппаратную в облаке, а управлять ею с обычного компьютера. Тогда вы уже не привязаны к месту съёмки, перед вами мощности всех датацентров мира за очень разумные деньги, вы решаете задачи, для которых классическому телевидению пришлось бы задействовать массу дорогостоящих ресурсов.

Ключом к успеху здесь является быстрая доставка видеопотоков через интернет (а не сигналов по проводам)от камер к "микшеру" и оттуда -- к режиссеру. Задержки всё портят. Другое отличие -- камеры мы будем использовать тоже необычные. Точнее, самые обычные,но не телевизионные и не бытовые, а камеры видеонаблюдения.

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

Проект групповой, движок видеомикшера есть, техника и специально под эти задачи построенная VPN тоже есть. Потребуется его интеграция в рабочий процесс на удаленном сервере, real-time отображение потоков режиссеру, создание отзывчивого фронтенда.

=== Чему вы научитесь? ===
Любопытно, но прямых аналогов нет. Движки, причем, функционально богатые, есть, а в явном виде облачный микшер видеопотоков не предлагают. Есть шанс сделать "скайп" для многокамерной съёмки/трансляции. Кто не помнит, скайп в своё время сделал видеосвязь обыденным делом, до него требовалось много приготовлений.
Работа связана с движком на базе gstreamer -- само по себе познавательное дело, т.к. применимость gstreamer'а не ограничивается сведением потоков.
Помимо этого, здесь предстоит столкнуться с двумя проявлениями отзывчивости: минимизацией задержки видеопотоков (сам по себе RTSP передается почти мгновенно, но как его показать без задержки?) и созданием отзывчивого пользовательского интерфейса. Разумеется, первые версии могут быть аскетичными по возможностям, но отзывчивость будет важна.
В зависимости от комплектации группы, будет разрабатываться больше или меньше возможностей. Например, полезный в этой области навык -- управление камерами (ONVIF). Есть смежные проекты, где эта тема получает развитие в трекинг человека или, коррекцию параметров изображения, в имитацию работы оператора (плавные движения, правильная композиция кадра).

=== Какие начальные требования? ===
В любом случае понадобятся навыки программирования (будь то веб-разработка или работа с движком GStreamer/Snowmix), работы с Linux (потому что виртуалка в сети). Остальное -- специфика, с которой можно познакомиться по ходу проекта. Веб-часть на Ruby on Rails -- для унификации с базовым проектом.

Ожидается, что разработчики умеют пользоваться поисковыми системами и stackoverflow. Руководитель может консультировать вас по предметной области (видео/тв), но не по программной разработке.

Разработка обычно имеет недельный цикл трекинга, встречи (как индивидуальные, так и групповые) по умолчанию -- по видеосвязи, но порой надо и очно (на факультете). Необходимые технические и серверные ресурсы предоставляются.

=== Какие будут использоваться технологии? ===
* Gstreamer и с ним Snowmix/Voctomix, возможно -- ffmpeg

* Виртуальные машины linux, nginx и сопутствующие инструменты

* Быстрая доставка потоков режиссеру -- возможно, WebRTC, но это не догма.

* Ruby on Rails (для унификации) и необходимые средства для UI (например, meteor, это ещё нужно обоснованно решить).

* Опционально: ONVIF для управления камерами (переход по предустановленным позициям)

=== Темы вводных занятий ===
Не в порядке изложения:

1. Архитектура проекта. API, внешние связи и зависимости.

2. Специфические технологии и используемые инструменты.

3. Доступные ресурсы, организация доступа.

4. Разделение ролей

=== Направления развития ===
Как микшер -- ядро телестудии, так и потоковый микшер связывает несколько разработок в мощный набор инструментов для организации полного цикла производства медиаконтента практически без капитальных вложений (не нужна закупка дорогостоящего оборудования, используется сервисная модель и облачные серверы).
Сам видеомикшер имеет два основных пути развития: как движок для непритязательных (выполняет монтажные функции, но не имеет выраженного "микшерного" интерфейсы, и как полноценный видеомикшер со всеми инструментами профессионального назначения. Этот проект может развиваться долго и стать стандартом де-факто для режиссеров потоковых эфиров. В такого рода проектах есть богатое поле для автоматизации и интеллектуализации рабочих процессов, есть множество рутинных процедур, которые могут быть сняты с человека, вплоть до разработки "автопилота" эфира (про это есть отдельный проект).

=== Критерии оценки ===
Про работу и оценки почитайте здесь: https://d.pr/143bq

Постарайтесь отнестись к этому с пониманием. Очень часто бодрое начало длится 3-4 недели и потом наступает тишина. Очень хочется, чтобы проекты доводились до запуска, а вы получали опыт успешной разработки и, возможно, работу в этих проектах уже в другом статусе. Но пока это для вас учебная работа, поэтому будем придерживаться описанных по ссылке правил и критериев. Спасибо!
===Как записаться?===

В общем доступе есть порядка двадцати проектов, относящихся к области видеотехнологий (стриминг, доставка потоков и т.д.). Чтобы всем было проще, эти проекты объединим в четыре группы и при записи на проект выбирайте группу, а конкретный проект и вашу роль в нем мы обсудим уже в рабочем порядке.

http://wiki.cs.hse.ru/images/thumb/f/f0/Projects.PNG/800px-Projects.PNG

=== Ориентировочное расписание занятий ===
Более точное расписание будет ясно после утверждения графика факультативов, пока ориентируемся на вторник, среду или пятницу во второй половине дня (после 15-16 часов).

На самом деле, для общения (как индивидуального, так и группового) удобно использовать средства видеосвязи -- это не заменяет очных встреч, но отлично дополняет их за счет возможности оперативно решать задачи "здесь и сейчас", сидя за удобным вам рабочим местом. Практически все темы проектов подразумевают работу в сети.

Денис Королев,

https://www.hse.ru/staff/dkorolev (там есть ссылки на соцсети)

+7 903 610 3290 (месенджеры по вкусу)

d.korolev@gmail.com

Разработка матрицы видеопотоков (проект)

2017-10-19T19:20:04Z

Dkorolev:

{{Карточка_проекта
|name=Разработка матрицы видеопотоков
|mentor=Королев Денис
|mentor_login={{URLENCODE:Dkorolev|WIKI}}
|semester=Осень 2017
|course=2
|summer=on
|number_of_students=5-10
|categorize=yes
}}

=== Что это за проект? ===
Матрица -- это узел, куда в телевизионном центре сходятся все сигналы и оттуда распределяются по потребителям. Технически это коробка с N входами и M выходами. И каждый выход m может быть сопоставлен входу n, при этом, на один вход может быть скоммутировано сколько угодно выходов. Ко входам подключаются камеры, выходы пультов, спутниковые приёмники с сигналами от выездных студий и внешних источников, а выходы подаются на пульты, рекордеры и эфирные кодеры. В нашем случае коммутироваться будут не сигналы в проводах, а потоки в сети. Представьте здания Вышки, в каждом по несколько оборудованных видеокамерами залов. В итоге по сети мы получаем множество потоков, но одновременно нужны далеко не все. И для режиссера эфира удобно иметь перед глазами только нужные камеры. Микшер подключен, например, к выходам 1-8 матрицы, а эти выходы коммутируются на нужные входы. Выходы матрицы также могут отдавать потоки на телевизионные панели в зданиях, сетевые рекордеры (такая тема тоже есть по соседству) и т.д.

Этот проект в минимальном виде за час собирается "на коленке" -- связка из двух VLC образует цепочку "переключатель/выход", где на переключателе указывается адрес входного потока, а выходной поток формируется вторым vlc (он является сервером RTSP. Количество таких пар определяет количество выходов, а входы -- это любые адреса потоков. Важно, что если к одной камере напрямую подключится много зрителей, то она не справится -- она является сервером, но не предназначена для массового доступа. Матрица выполняет роль прокси.

Технически это сервис на виртуальной машине. Он не должен перекодировать видео, только пересылать его. Зато матрице позволительно делать подрыв при переключении (это как при переключении каналов на телевизоре -- на время звук и картинка пропадают, потом появляется новый канал). Внешне это веб-интерфейс, представляющий собой минимально админ-панель, где вводятся адреса и имена источников и выходов, а в полной версии -- есть предпросмотр для всех входов и выходов. Сервис должен быть многопользовательским с возможностью делегировать доступ, группировать каналы и т.д.

=== Чему вы научитесь? ===
1. Работа с linux-серверами.

2. Поближе познакомитесь с сетями. Unicast/Multicast, TCP/UDP -- все это станет роднее и понятнее. VPN, куда же без него.

3. Манипуляции с медиапотоками в сети. Придется разобраться в RTSP серверах (в простейшем случае это многим знакомый VLC)

4. Разработка пользовательского интерфейса (личный кабинет с настройками, групповой доступ, отображение предпросмотра с минимизацией трафика) -- здесь достаточно ruby on rails (для совместимости поддержки с соседними проектами) и верстки bootstrap.

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

=== Какие начальные требования? ===
* Навыки программирования (рельсы можно изучить. После Python вы не будете очень страдать).

* Ожидается, что разработчики умеют пользоваться поисковыми системами и stackoverflow. Руководитель может консультировать вас по предметной области (видео/тв), но не по программной разработке.

* Разработка обычно имеет недельный цикл трекинга, встречи (как индивидуальные, так и групповые) по умолчанию -- по видеосвязи, но порой надо и очно (на факультете). Необходимые технические и серверные ресурсы предоставляются.

Специфику предметной области (видеопотоки, устройства и тд) у вас будет возможность изучить по ходу проекта.

=== Какие будут использоваться технологии? ===
* RTSP потоки и RTSP сервер -- протокол передачи видео в реальном времени, широко используется в системах IPTV и видеонаблюдения. В быту RTSP сервер легко сделать из VLC, но есть и другие варианты (FFSERVER, Live555 и т.д.).

* ONVIF -- стандарт управления для систем видеонаблюдения. Очень пригодится для обнаружения источников в сети и адресов потоков в этих источниках. Также, полезно сделать управление матрицей совместимым со стандартами управления прочим видеооборудованием.

* REST API -- не технология, но очевидно, что программное взаимодействие с матрицей будет необходимо, в частности, для автоматизации вещания (расписание -- это уже тема отдельного проекта)

* OAuth -- общее требование по аутентификации пользователей. Встречается повсеместно, освоить всегда полезно.

* Ruby on Rails -- веб-разработка крайне желательная на этой связке.

* FFMPEG/GStreamer -- на случай необходимости все-таки обработать поток. Например, чтобы сгенерировать превью или сделать транскодирование в RTSP или в нужный формат (если такое указано для данного канала).

=== Темы вводных занятий ===
Не в порядке изложения:

1. Архитектура проекта. API, внешние связи и зависимости.

2. Специфические технологии и используемые инструменты.

3. Доступные ресурсы, организация доступа.

4. Разделение ролей

=== Направления развития ===
Матрица -- вполне самодостаточный продукт для определенной инфраструктуры. Обычно медиа-производства в таком технологическом ключе не мыслят, но в совокупности с другими проектами (потоковый видеомикшер, съёмочный комплекс на IP-потоках, автотрекинг человека PTZ камерами и т.д.) образуется полноценная инфраструктура, позволяющая решать масштабные задачи, причём, изначально -- распределенно.

=== Критерии оценки ===
Про работу и оценки почитайте здесь: https://d.pr/143bq

Постарайтесь отнестись к этому с пониманием. Очень часто бодрое начало длится 3-4 недели и потом наступает тишина. Очень хочется, чтобы проекты доводились до запуска, а вы получали опыт успешной разработки и, возможно, работу в этих проектах уже в другом статусе. Но пока это для вас учебная работа, поэтому будем придерживаться описанных по ссылке правил и критериев. Спасибо!
===Как записаться?===

В общем доступе есть порядка двадцати проектов, относящихся к области видеотехнологий (стриминг, доставка потоков и т.д.). Чтобы всем было проще, эти проекты объединим в четыре группы и при записи на проект выбирайте группу, а конкретный проект и вашу роль в нем мы обсудим уже в рабочем порядке.

http://wiki.cs.hse.ru/images/thumb/f/f0/Projects.PNG/800px-Projects.PNG

=== Ориентировочное расписание занятий ===
Более точное расписание будет ясно после утверждения графика факультативов, пока ориентируемся на вторник, среду или пятницу во второй половине дня (после 15-16 часов).

На самом деле, для общения (как индивидуального, так и группового) удобно использовать средства видеосвязи -- это не заменяет очных встреч, но отлично дополняет их за счет возможности оперативно решать задачи "здесь и сейчас", сидя за удобным вам рабочим местом. Практически все темы проектов подразумевают работу в сети.

Денис Королев,

https://www.hse.ru/staff/dkorolev (там есть ссылки на соцсети)

+7 903 610 3290 (месенджеры по вкусу)

d.korolev@gmail.com

Разработка динамической сети доставки потокового видеоконтента (проект)

2017-10-19T19:19:51Z

Dkorolev:

{{Карточка_проекта
|name=Разработка динамической сети доставки потокового видеоконтента
|mentor=Королев Денис
|mentor_login={{URLENCODE:Dkorolev|WIKI}}
|semester=Осень 2017
|course=2
|summer=on
|number_of_students=5-10
|categorize=yes
}}

=== Что это за проект? ===
Видеотрансляции в интернет стали совсем обычным делом с тех пор, как ими вплотную занялись Youtube и, позже, соцсети. До них раздача видеопотоков зрителям решалась или своими силами, или через сети доставки контента (CDN). Суть задачи в том, что, в отличие от телевидения, которое посылает один сигнал всем, а смотрят его те, кто хотят, в интернет работает только метод передачи данных от точки к точке (unicast), что для сервера трансляций оборачивается необходимостью каждому зрителю индивидуально отправить поток. Тот же самый, что другому зрителю, в то же время, но отправить персонально. В итоге нагрузка на канал связи растет пропорционально аудитории трансляции. И задерживать такой поток нельзя.

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

Для эффективной работы CDN требуется диагностика и мониторинг каналов связи на серверах, ресурсов самих серверов -- это отдельная подтема в проекте.

Вторая часть проекта -- это frontend. Если при трансляции через Youtube зритель видит плеер Youtube, то при трансляции через собственный CDN зрителю надо показать какой-то свой плеер. А может быть и не только плеер. Есть множество "фич", которые становится возможным реализовать, если вести раздачу потоков через свои ресурсы: обратная связь, учет зрительской активности, взимание платы за трансляции, учет географии и других данных о пользователе, многопоточный звук для трансляции многоязычных конференций, субтитры (у нас есть распознавание голоса в текст). Можно организовать чат, голосования и даже принимать от зрителей видеопотоки, звук и файлы через WebRTC. Разумеется, здесь задачи будут выбираться исходя из состава и готовности проектной группы.

=== Чему вы научитесь? ===
Проект в первую очередь -- сетевой, в чистом виде -- облачный. Это разработка распределенной системы, динамически меняющейся в зависимости от нагрузки. Более того, практика показывает, что нельзя привязываться к одному провайдеру услуг: там тоже бывают перебои. В результате разработки CDN должна иметь REST API и хотя бы минимальную админ-панель, для зрителей должен предлагаться плеер (как минимум -- HLS) и страница для просмотра.

=== Какие начальные требования? ===
CDN -- это серверная разработка под Linux. Язык жестко не регламентирован, попытки что-то сделать уже предпринимались на Java. Веб-разработка -- основной проект написан на Ruby on Rails, желательно не вносить разнообразие языков, но это не блокирующее требование. Плеер -- если беретесь за плеер, то хорошо бы иметь хоть какой-то опыт общения с ними. Задача может оказаться сложнее, чем кажется на первый взгляд.

=== Какие будут использоваться технологии? ===
Облачные серверы запускаются с использованием API соответствующего провайдера. Некоторые провайдеры используют OpenStack, но это (на практике) не решает проблем унификации работы. Сетевой мониторинг -- само по себе важное направление в инфраструктуре ИТ. Конкретные инструменты предстоит выбрать. Плеер и фронтенд -- есть смелая идея раздавать поток через WebRTC (а это пиринговая технология, то есть, на стороне серверов будет о чем подумать), через него же собирать обратную связь. Но это отдельная часть проекта, для смелых веб-разработчиков, причем, ее можно реализовывать независимо от успехов в CDN (можем запустить в действующем проекте). Однозначно можно сказать, что Flash использовать нельзя, но при этом доставить на все платформы поток в едином виде можно лишь http-based протоколами (HLS, например), а у них есть свои недостатки -- большая задержка, от которой теряется смысл в обратной связи реального времени. Поэтому нужно предусматривать запасные протоколы: WebRTC - RTMP - HLS. Это в порядке увеличения задержки.

=== Темы вводных занятий ===
Не в порядке изложения:

1. Архитектура проекта. API, внешние связи и зависимости.

2. Специфические технологии и используемые инструменты.

3. Доступные ресурсы, организация доступа.

4. Разделение ролей

=== Направления развития ===
CDN для трансляций можно рассматривать как модуль для сервиса видеовещания, а можно и как самостоятельную платформу, работающую поверх облачных хостингов виртуальных машин. Но вывести такой продукт в самостоятельный статус, обеспечить необходимые функционал и стабильность -- это задача для настойчивых.

=== Критерии оценки ===
Про работу и оценки почитайте здесь: https://d.pr/143bq Обратите внимание, что проект составной и то, какие части пойдут в работу, мы поймём, когда сформируется состав рабочей группы. То есть, отсутствие в итоге какой-то из частей, не блокирующей работу (например, WebRTC не запустили, но HLS плеер есть -- его поставить недолго) никак не снижает оценки проделанной работы по тем частям проекта, которые выполнены. Участники проекта имеют свою область ответственности и оценки получают в соответствии с успехами в этих областях.

Постарайтесь отнестись к этому с пониманием. Очень часто бодрое начало длится 3-4 недели и потом наступает тишина. Очень хочется, чтобы проекты доводились до запуска, а вы получали опыт успешной разработки и, возможно, работу в этих проектах уже в другом статусе. Но пока это для вас учебная работа, поэтому будем придерживаться описанных по ссылке правил и критериев. Спасибо!
===Как записаться?===

В общем доступе есть порядка двадцати проектов, относящихся к области видеотехнологий (стриминг, доставка потоков и т.д.). Чтобы всем было проще, эти проекты объединим в четыре группы и при записи на проект выбирайте группу, а конкретный проект и вашу роль в нем мы обсудим уже в рабочем порядке.

http://wiki.cs.hse.ru/images/thumb/f/f0/Projects.PNG/800px-Projects.PNG

=== Ориентировочное расписание занятий ===
Более точное расписание будет ясно после утверждения графика факультативов, пока ориентируемся на вторник, среду или пятницу во второй половине дня (после 15-16 часов).

На самом деле, для общения (как индивидуального, так и группового) удобно использовать средства видеосвязи -- это не заменяет очных встреч, но отлично дополняет их за счет возможности оперативно решать задачи "здесь и сейчас", сидя за удобным вам рабочим местом. Практически все темы проектов подразумевают работу в сети.

Денис Королев,

https://www.hse.ru/staff/dkorolev (там есть ссылки на соцсети)

+7 903 610 3290 (месенджеры по вкусу)

d.korolev@gmail.com

Разработка веб-сервиса файлового менеджера для GoogleDrive (проект)

2017-10-19T19:19:34Z

Dkorolev:

{{Карточка_проекта
|name=Разработка веб-сервиса файлового менеджера для GoogleDrive
|mentor=Королев Денис
|mentor_login={{URLENCODE:Dkorolev|WIKI}}
|semester=Осень 2017
|course=2
|summer=on
|number_of_students=5-10
|categorize=yes
}}

=== Что это за проект? ===
Не все знают, но у корпоративных и академических аккаунтов Google безлимитные хранилища в GoogleDrive. При этом, скорость обмена с сервером достаточная, чтобы хранить там медиаархивы. Это радикально меняет подход к хранению данных видеопроизводств, к видеорегистрации и многим другим "тяжеловесным" задачам. Проект нацелен на создание медиаархива на базе хранилища GoogleDrive. От стандартной веб-оболочки медиаархив отличают две важные особенности:

1. Представление данных в том виде, в каком это удобно для выборки, шаринга, выгрузки и т.д

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

В данном проекте решается первая задача (вторая решается в соседнем проекте). Для этого уже написан веб-интерфейс файлового менеджера (MeteorJS, используется MongoDB). По сути, требуется доработка проекта.

При этом, важные требования: через серверы проекта медиа-трафик не проходит. То есть, загружается только метаинформация. Про метаданные файлов есть важное замечание: данных может быть довольно много, они даже могут быть относительно объёмными. Поэтому хранить их в полях метаданных, предоставляемых GoogleDrive не получится (кроме базовых сведений о файле -- это можно). Также, следует экономно относиться к запросам к серверу, т.к. на них есть ограничение для публичного сервиса оно вполне достижимое.

=== Чему вы научитесь? ===
* Разработка веб-приложения с отзывчивым интерфейсом

* Глубокое взаимодействие с API GoogleDrive

На выходе открытый продукт -- альтернативный файловый менеджер для GoogleDrive, размещённый в ChromeMarket.

=== Какие начальные требования? ===
* Навыки веб-разработки или желание её изучить.

=== Какие будут использоваться технологии? ===
* Meteor / MongoDB
* GoogleDrive API

=== Темы вводных занятий ===
Не в порядке изложения:

1. Архитектура проекта. API, внешние связи и зависимости.

2. Специфические технологии и используемые инструменты.

3. Доступные ресурсы, организация доступа.

4. Разделение ролей

=== Направления развития ===
Файлменеджер для GoogleDrive -- это "витрина" большого проекта, включающего анализатор файлов на облачном диске пользователя, сервис по продаже безлимитных аккаунтов, сервис персонализации контента (вотермаркинг) и даже CDN (сеть доставки контента, в данном случае -- статического, например, для часто запрашиваемых медиаматериалов).

=== Критерии оценки ===
Про работу и оценки почитайте здесь: https://d.pr/143bq

Постарайтесь отнестись к этому с пониманием. Очень часто бодрое начало длится 3-4 недели и потом наступает тишина. Очень хочется, чтобы проекты доводились до запуска, а вы получали опыт успешной разработки и, возможно, работу в этих проектах уже в другом статусе. Но пока это для вас учебная работа, поэтому будем придерживаться описанных по ссылке правил и критериев. Спасибо!
===Как записаться?===

В общем доступе есть порядка двадцати проектов, относящихся к области видеотехнологий (стриминг, доставка потоков и т.д.). Чтобы всем было проще, эти проекты объединим в четыре группы и при записи на проект выбирайте группу, а конкретный проект и вашу роль в нем мы обсудим уже в рабочем порядке.

http://wiki.cs.hse.ru/images/thumb/f/f0/Projects.PNG/800px-Projects.PNG

=== Ориентировочное расписание занятий ===
Более точное расписание будет ясно после утверждения графика факультативов, пока ориентируемся на вторник, среду или пятницу во второй половине дня (после 15-16 часов).

На самом деле, для общения (как индивидуального, так и группового) удобно использовать средства видеосвязи -- это не заменяет очных встреч, но отлично дополняет их за счет возможности оперативно решать задачи "здесь и сейчас", сидя за удобным вам рабочим местом. Практически все темы проектов подразумевают работу в сети.

Денис Королев,

https://www.hse.ru/staff/dkorolev (там есть ссылки на соцсети)

+7 903 610 3290 (месенджеры по вкусу)

d.korolev@gmail.com

Разработка веб-сервиса нелинейного видеоредактора (проект)

2017-10-19T19:19:14Z

Dkorolev:

{{Карточка_проекта
|name=Разработка веб-сервиса нелинейного видеоредактора
|mentor=Королев Денис
|mentor_login={{URLENCODE:Dkorolev|WIKI}}
|semester=Осень 2017
|course=2
|summer=
|number_of_students=
|categorize=yes
}}

=== Что это за проект? ===
Существует уже много веб-сервисов и мобильных приложений для редактирования фото и видео. Как обычно, чтобы ими воспользоваться, нужно в них загрузить свои файлы. А если файлы уже лежат в облаке, при этом, важно быстро внести требуемые изменения, то это неудобно. Чаще всего требуется подрезка, наложение титров или графики, склейка фрагментов. Эти операции могут выполняться из командной строки, если знать требуемые параметры (например, при помощи ffmpeg).

Задача в этом проекте разделена на два уровня сложности:

1. Сделать простой видеоредактор для выполнения основных операций: отрезать, приклеить, наложить, преобразовать в нужный размер/формат. При этом, в качестве источника должны приниматься файлы на GoogleDrive, WebDAV и FTP. Работа с файлами должна строиться путём отбора нужных материалов из архива с дальнейшей выгрузкой их на сервер (или открытием непосредственно с GoogleDrive) с последующей записью результата по любому указанному пути или выгрузкой пользователю.

2. Построить полноценный нелинейный редактор на основе существующего движка (например [https://www.mltframework.org/features/

=== Чему вы научитесь? ===
Либо писать свой интерфейс для несложного видеоредактора (даже для несложного придется потрудиться), либо работать с фреймворком видеоредактора и тоже строить отзывчивый пользовательский интерфейс.

Взаимодействовать с облачными хранилищами, API GoogleDrive, использовать OAuth и т.д.

Строить сервисы с распределением нагрузки по виртуальным машинам.

=== Какие начальные требования? ===
* Не бояться разбираться в фреймворках и api. Хотеть довести продукт до рабочего состояния.

=== Какие будут использоваться технологии? ===
* Фреймворк NLE-редактора

* GoogleDrive API

* Собственный REST API

* Отзывчивый UI (JS-based)

=== Темы вводных занятий ===
Не в порядке изложения:

1. Архитектура проекта. API, внешние связи и зависимости.

2. Специфические технологии и используемые инструменты.

3. Доступные ресурсы, организация доступа.

4. Разделение ролей

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

=== Критерии оценки ===
Про работу и оценки почитайте здесь: https://d.pr/143bq

Постарайтесь отнестись к этому с пониманием. Очень часто бодрое начало длится 3-4 недели и потом наступает тишина. Очень хочется, чтобы проекты доводились до запуска, а вы получали опыт успешной разработки и, возможно, работу в этих проектах уже в другом статусе. Но пока это для вас учебная работа, поэтому будем придерживаться описанных по ссылке правил и критериев. Спасибо!
===Как записаться?===

В общем доступе есть порядка двадцати проектов, относящихся к области видеотехнологий (стриминг, доставка потоков и т.д.). Чтобы всем было проще, эти проекты объединим в четыре группы и при записи на проект выбирайте группу, а конкретный проект и вашу роль в нем мы обсудим уже в рабочем порядке.

http://wiki.cs.hse.ru/images/thumb/f/f0/Projects.PNG/800px-Projects.PNG

=== Ориентировочное расписание занятий ===
Более точное расписание будет ясно после утверждения графика факультативов, пока ориентируемся на вторник, среду или пятницу во второй половине дня (после 15-16 часов).

На самом деле, для общения (как индивидуального, так и группового) удобно использовать средства видеосвязи -- это не заменяет очных встреч, но отлично дополняет их за счет возможности оперативно решать задачи "здесь и сейчас", сидя за удобным вам рабочим местом. Практически все темы проектов подразумевают работу в сети.

Денис Королев,

https://www.hse.ru/staff/dkorolev (там есть ссылки на соцсети)

+7 903 610 3290 (месенджеры по вкусу)

d.korolev@gmail.com

Разработка анализатора файлов, хранимых в GoogleDrive (проект)

2017-10-19T19:18:58Z

Dkorolev:

{{Карточка_проекта
|name=Разработка анализатора файлов, хранимых в GoogleDrive
|mentor=Королев Денис
|mentor_login={{URLENCODE:Dkorolev|WIKI}}
|semester=Осень 2017
|course=2
|summer=on
|number_of_students=5-10
|categorize=yes
}}

=== Что это за проект? ===
В соседнем проекте предлагается разработка файлового менеджера для медиаархивов, расположенных в GoogleDrive (корпоративные и академические аккаунты имеют безлимитные хранилища, что при хорошей скорости доступа позволяет включать их в работу там, где раньше использовались серверы хранения).

Рабочий процесс при работе с медиаархивом на диске Google выглядит следующим образом:

1. Для обмена данными с GoogleDrive используются альтернативные приложения, например, WebDrive, позволяющий подключать облачный аккаунт как логический диск в Windows/Mac.

2. Файлы отображаются в виртуальной файловой системе WebDrive и в веб-интерфейсе GoogleDrive в иерархическом виде, доступны все стандартные действия.

3. Веб-файлменеджер медиаархива показывает ту же структуру файлов, но может формировать другие представления, основываясь на критериях отбора, делать смарт-папки, витрины и давать задания на обработку (например, персонализированную маркировку файлов для отправки клиенту, чтобы было не повадно класть их на видном месте). И здесь возникает первая проблема недостатка метаинформации: про файлы мы в лучшем случае знаем дату их изменения, и то -- не всегда. Если файл загружался через браузер или стандартным приложением Google, то на GoogleDrive запишется дата загрузки. Более детальной информации о многих файлах получить не удастся: если для фотографий доступны данные EXIF (метаданные, которые записывают фотокамеры и фоторедакторы), то про видео известна самая малость: длина, размер кадра, формат. Даже размер файла точно неизвестен. Правда, про все файлы мы можем узнать MD5 -- это пригодится для поиска дубликатов. Недостающие данные можно было бы легко получить на стороне пользователя (про видеофайлы нам всё расскажет FFPROBE, про даты, пути, пользователя и т.д. -- файловая и операционная система через стандартные вызовы. Но у пользователя мы ничего не запускаем (хотя и можем ему предложить утилиту для отправки этой информации, которую потом будем считывать в базу уже с GoogleDrive) и выгружать на свой сервер терабайты ради этого было бы жаль, если не проводить более глубоких исследований файлов. Какие это могут быть исследования?

Если на жестком диске лежат два вроде бы одинаковых файла, то мы можем:

1. Сравнить их контрольные суммы, размеры и названия. Названия мало что значат, размеры тоже могут совпадать, MD5 совпадает редко. Но всё это бесполезно, если речь идет о об исходном файле и его сжатой копии.

2. Здесь придется сравнивать содержимое. Например, вычесть изображения и посмотреть, что осталось в разнице. Если видео -- аналогично вычитать кадры (можно не все, хотя есть риск пропустить разницу). Надо ещё не забыть про звук и звуковые дорожки -- разница может быть в них. Всё это -- ресурсоёмкие операции, требующие наличия доступа к обоим сравниваемым файлам.

3. А если файлы большие, их очень много и расположены на удаленном сервере? В таком случае придётся строить индекс и сравнивать не сами файлы, а описания файлов. Назовём их сигнатурами. Простой вариант -- построить гистаграммы (это 3 набора из 256 значений) для каждого кадра видео. Оригинал это или сжатая копия -- распределение яркостей по цветовым каналам должно быть примерно одинаковым. Можно попробовать более изощрённые методы, и даже в этом результирующие значения можно записать более экономно, чем 256 уровней *3 канала *2 байта * количество кадров. В любом случае, операции с данными раскладываются на два этапа: а) сбор метаданных, включая сигнатуры, какими бы они ни были, б) сравнение сигнатур.

Поскольку разрабатываемый сервис является сторонним и для Google и для пользовательского рабочего места приложением, запущен на виртуальных машинах в облаке, то для выполнения этих задач ему понадобится

* выгрузить последовательно все файлы с указанного пользовательского аккаунта к себе и провести все необходимые операции для анализа.
* отправить собранные метаданные в базу данных файлового менеджера.

Предстоит определить список операций и характеристик файлов, для которых составляются сигнатуры. Например, поиск дубликатов (включае нечеткие), определение частей целого (сопоставление файлов, содержащих исходную запись и нарезки из неё), поиск материалов по их характеристикам (динамичное видео, темные фотографии, ..... Кстати, здесь могут быть актуальны и запросы "размытые фотографии", "портреты" и тд).

=== Чему вы научитесь? ===
В зависимости от роли:

* Анализировать фото, видео, аудио контент с целью составления метаописаний, по которым можно сравнивать эти материалы между собой и с новыми файлами, а также определять определенные их характеристики.

* Работать с GoogleDrive API

* Создавать веб-сервисы с REST API

* Организовывать очередь запросов и распределение задач по воркерам на виртуальных машинах с (это опционально) запуском этих машин по мере надобности (через API провайдера).

=== Какие начальные требования? ===
В зависимости от роли в проекте:

1. Программирование веб-сервисров: опыт или желание освоить.

2. Анализ изображений. Хотя бы представление о том, как и чем это делается.

3. Linux и bash, чтобы не удивляться при работе с виртуалками.

=== Какие будут использоваться технологии? ===
* GoogleDrive API, OAuth.

* Анализ изображений, видео, звука. От FFPROBE/ImageMagick до OpenCV и далее -- на сколько хватит фантазии.

* Работа с виртуальными серверами на хостинг-провайдерах (API)

Веб-интерфейс в таком сервисе не является необходимой частью, но может использоваться для демонстрации возможностей. Основное взаимодействие с внешним миром -- REST API.

=== Темы вводных занятий ===
Не в порядке изложения:

1. Архитектура проекта. API, внешние связи и зависимости.

2. Специфические технологии и используемые инструменты.

3. Доступные ресурсы, организация доступа.

4. Разделение ролей

=== Направления развития ===
Этот проект довольно узкоспецифический, но по сути анализ медиаматериалов -- это то, чем занимаются поисковые системы, которые в выдаче картинок предлагают в настройках разные опции (в определенной цветовой гамме и тд). Они идут дальше и всерьез применяют распознавание и ML. Нам это тоже не повредит, но это следующий этап после запуска базовых возможностей. Ничто не мешает его начать делать уже сейчас.

Близкий проект на Ярмарке проектов ВШЭ: https://pf.hse.ru/208039048.html

=== Критерии оценки ===
Про работу и оценки почитайте здесь: https://d.pr/143bq

Постарайтесь отнестись к этому с пониманием. Очень часто бодрое начало длится 3-4 недели и потом наступает тишина. Очень хочется, чтобы проекты доводились до запуска, а вы получали опыт успешной разработки и, возможно, работу в этих проектах уже в другом статусе. Но пока это для вас учебная работа, поэтому будем придерживаться описанных по ссылке правил и критериев. Спасибо!

===Как записаться?===

В общем доступе есть порядка двадцати проектов, относящихся к области видеотехнологий (стриминг, доставка потоков и т.д.). Чтобы всем было проще, эти проекты объединим в четыре группы и при записи на проект выбирайте группу, а конкретный проект и вашу роль в нем мы обсудим уже в рабочем порядке.

http://wiki.cs.hse.ru/images/thumb/f/f0/Projects.PNG/800px-Projects.PNG

=== Ориентировочное расписание занятий ===
Более точное расписание будет ясно после утверждения графика факультативов, пока ориентируемся на вторник, среду или пятницу во второй половине дня (после 15-16 часов).

На самом деле, для общения (как индивидуального, так и группового) удобно использовать средства видеосвязи -- это не заменяет очных встреч, но отлично дополняет их за счет возможности оперативно решать задачи "здесь и сейчас", сидя за удобным вам рабочим местом. Практически все темы проектов подразумевают работу в сети.

Денис Королев,

https://www.hse.ru/staff/dkorolev (там есть ссылки на соцсети)

+7 903 610 3290 (месенджеры по вкусу)

d.korolev@gmail.com

Интеграция WebRTC в сервис потокового вещания для отображения потоков в реальном времени (проект)

2017-10-19T19:18:14Z

Dkorolev:

{{Карточка_проекта
|name=Интеграция WebRTC в сервис потокового вещания для отображения потоков в реальном времени
|mentor=Королев Денис
|mentor_login={{URLENCODE:Dkorolev|WIKI}}
|semester=Осень 2017
|course=2
|summer=on
|number_of_students=5
|categorize=yes
}}

=== Что это за проект? ===
Небольшая и совершенно конкретная тема, входящая в несколько соседних проектов в качестве подпроекта: есть задачи, в которых требуется получать видео из потока RAW/RTSP в реальном времени (или близком к реальному). Когда речь идёт о видеосистемах, там есть протоколы, которые с этим справляются (RTP, RTSP), но браузеры не умеют показывать RTP/RTSP. Зато некоторые браузеры (этого достаточно) умеют показывать WebRTC. В этой задаче нет новизны, она ориентирована на внедрение конкретного технического решения и отладку шероховатостей, возникающих в реальной жизни с реальными потоками.

=== Чему вы научитесь? ===
* Работа с видеопотоками в сети, доставка видео в реальном времени

=== Какие начальные требования? ===
* Навыки веб-программирования, желательно Ruby on Rails (для прототипа можно использовать любой язык).

=== Какие будут использоваться технологии? ===
* WebRTC (сервер Kurento или другой -- на выбор исполнителя)
* Ruby on Rails
* JavaScript

=== Темы вводных занятий ===
Не в порядке изложения:

1. Архитектура проекта. внешние связи и зависимости.

2. Специфические технологии и используемые инструменты.

3. Доступные ресурсы, организация доступа.

4. Разделение ролей

=== Направления развития ===
Предлагаемые темы не являются чисто учебными, все они -- из рабочей практики и имеют выход в коммерческие сервисы, дополняя уже имеющийся функционал. Общая практика работы "на развитие" -- преуспевший в разработке некоего проекта студент (если хочет) становится "хостом" проекта и ведет его развитие дальше уже находясь в договорных отношениях с компанией.

Это проект одной технологии, причём, применяться она может в обе стороны: как для доставки видеопотоков зрителю, так и для получения от него потока с камеры и с рабочего стола. Может применяться и для передачи файлов. Всё это имеет применение в видеотрансляциях, даже массовых. В настоящее время включение в эфир "звонка зрителя" выполняется или отдельным сервисом (Skype, например), или средствами программного видеомикшера ("звонящий" переходит по ссылке, рабочий стол показать при этом нельзя). Реализация полноценной обратной связи -- это полноценный проект, построенный на той же технологии WebRTC со связкой с потоковым микшером. Это важный элемент для создания видеокомплекса в облаке, действующего в реальном времени (то есть, с полноценной поддержкой режиссируемого общения участников)

=== Критерии оценки ===
Про работу и оценки почитайте здесь: https://d.pr/143bq

Постарайтесь отнестись к этому с пониманием. Очень часто бодрое начало длится 3-4 недели и потом наступает тишина. Очень хочется, чтобы проекты доводились до запуска, а вы получали опыт успешной разработки и, возможно, работу в этих проектах уже в другом статусе. Но пока это для вас учебная работа, поэтому будем придерживаться описанных по ссылке правил и критериев. Спасибо!

===Как записаться?===

В общем доступе есть порядка двадцати проектов, относящихся к области видеотехнологий (стриминг, доставка потоков и т.д.). Чтобы всем было проще, эти проекты объединим в четыре группы и при записи на проект выбирайте группу, а конкретный проект и вашу роль в нем мы обсудим уже в рабочем порядке.

http://wiki.cs.hse.ru/images/thumb/f/f0/Projects.PNG/800px-Projects.PNG

=== Ориентировочное расписание занятий ===
Более точное расписание будет ясно после утверждения графика факультативов, пока ориентируемся на вторник, среду или пятницу во второй половине дня (после 15-16 часов).

На самом деле, для общения (как индивидуального, так и группового) удобно использовать средства видеосвязи -- это не заменяет очных встреч, но отлично дополняет их за счет возможности оперативно решать задачи "здесь и сейчас", сидя за удобным вам рабочим местом. Практически все темы проектов подразумевают работу в сети.

Денис Королев,

https://www.hse.ru/staff/dkorolev (там есть ссылки на соцсети)

+7 903 610 3290 (месенджеры по вкусу)

d.korolev@gmail.com

Автоматизация видеосъёмки в прямом эфире (проект)

2017-10-19T19:17:34Z

Dkorolev:

{{Карточка_проекта
|name=Автоматизация видеосъёмки в прямом эфире
|mentor=Королев Денис
|mentor_login={{URLENCODE:Dkorolev|WIKI}}
|semester=Осень 2017
|course=2
|summer=on
|number_of_students=5-10
|categorize=yes
}}

=== Что это за проект? ===
По потоку RTSP, получаемому от управляемой (PTZ) IP видеокамеры, нужно определять человека в кадре и посредством команд ONVIF управлять камерой, чтобы человек оставался в кадре. При этом, движения должны быть плавными (но настойчивыми, чтобы не терять цель), а композиция кадра должна быть выдержана по заданным правилам. Требуется обеспечить устойчивость к ситуациям, когда снимаемый человек отвернулся или сел за стол, наклонился, и т.д. При появлении новых людей в кадре следует удерживать фокус на первом. Результатом является а) сервис на виртуальной linux-машине, имеющий REST API для передачи адресов-паролей камер и потоков, а также возвращения контрольного потока со служебными метками, и б) автономно устанавливаемая его версия в виде службы в Windows.

=== Чему вы научитесь? ===
Трекинг человека в кадре. Актуальная задача для многих применений. В данном случае "фишка" проекта -- в художественной съёмке. Здесь нет ничего гениального, просто следовать правилам, а правила опираются на знание, как расположена фигура человека в кадре и куда он смотрит или хотя бы повернул голову. Но, чтобы это смотрелось хорошо, нужно правильно управлять перемещением камеры, поэтому:
Управление камерой через ONVIF с плавным и одновременным изменением координат.
Следует учитывать, что работать придется без опорного изображения, полагаясь только на поток с камеры. То есть, выходящего за кадр актера придётся догонять, "отъезжать" и предпринимать все возможные действия, чтобы не потерять совсем. Желательно, чтобы при этом зрителей не укачало.

Основной challenge проекта -- учесть возможные помехи (человек отвернулся или наклонился, сел за стол -- тогда полагаться на иные, чем только распознанное лицо, характеристики изобржаения, следить за контурами и т.д.), при этом, обеспечить движение, которое можно показывать в прямом эфире, не боясь, что камера будет дергаться или снимать "мимо".

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

Сервис должен запускаться как на удаленном Linux-сервере, так и иметь локальную версию для Windows (в виде службы), при этом, взаимодействие с сервисом должно обеспечиваться через REST API и через веб-интерфейс. Помимо базовых команд (запуск, остановка автотрекинга, ручной выбор композиции и крупности плана), пользователь должен иметь возможность видеть обнаруженных программой людей (если их в кадре больше одного) и переключать фокус трекера на одного из них.

=== Какие начальные требования? ===
В зависимости от роли в проекте:

* Навыки работы с распознаванием лица и фигуры человека или, хотя бы, желание этому научиться и навыки программирования (С++ или Python - для работы с OpenCV)
* Программирование UI

=== Какие будут использоваться технологии? ===
* OpenCV
* Потоковая передача RTSP
* ONVIF-управление PTZ-камерой
* REST API для интеграции с клиентами сервиса.

=== Темы вводных занятий ===
1. Архитектура проекта. API, внешние связи и зависимости.

2. Специфические технологии и используемые инструменты.

3. Доступные ресурсы, организация доступа.

4. Разделение ролей

=== Направления развития ===
Все предлагаемые темы не являются чисто учебными, все они -- из рабочей практики и имеют выход в коммерческие сервисы, дополняя уже имеющийся функционал. Общая практика работы "на развитие" -- преуспевший в разработке некоего проекта студент (если хочет) становится "хостом" проекта и ведет его развитие дальше уже находясь в договорных отношениях с компанией.
При этом, тема автосъёмки применима как к автономным съёмочным комплексам, так и в формате сервиса совместно с VPN-подключением.

Оператор телевизионной съёмки в большинстве случаев -- это привод к камере, который должен не терять объект из кадра и держать композицию согласно правилам. Это не относится к киносъёмке и различным творческим задачам, но подавляющее большинство материала на ТВ -- это говорящие головы. А в интернет-трансляциях -- и подавно (конференции, выступления и тд -- это просто видеорегистрация). Как говорили в IBM, "машина должна работать, а человек -- думать". Вам предлагается перевести на автоматику ещё одну профессию, оставив человеку заниматься более творческими задачами.

=== Критерии оценки ===
Про работу и оценки почитайте здесь: https://d.pr/143bq

Постарайтесь отнестись к этому с пониманием. Очень часто бодрое начало длится 3-4 недели и потом наступает тишина. Очень хочется, чтобы проекты доводились до запуска, а вы получали опыт успешной разработки и, возможно, работу в этих проектах уже в другом статусе. Но пока это для вас учебная работа, поэтому будем придерживаться описанных по ссылке правил и критериев. Спасибо!

=== Ориентировочное расписание занятий ===
Более точное расписание будет ясно после утверждения графика факультативов, пока ориентируемся на вторник, среду или пятницу во второй половине дня (после 15-16 часов).

На самом деле, для общения (как индивидуального, так и группового) удобно использовать средства видеосвязи -- это не заменяет очных встреч, но отлично дополняет их за счет возможности оперативно решать задачи "здесь и сейчас", сидя за удобным вам рабочим местом. Практически все темы проектов подразумевают работу в сети.

===Как записаться?===

В общем доступе есть порядка двадцати проектов, относящихся к области видеотехнологий (стриминг, доставка потоков и т.д.). Чтобы всем было проще, эти проекты объединим в четыре группы и при записи на проект выбирайте группу, а конкретный проект и вашу роль в нем мы обсудим уже в рабочем порядке.

http://wiki.cs.hse.ru/images/thumb/f/f0/Projects.PNG/800px-Projects.PNG

Автоматическая экспо- и цветокоррекция при съёмке IP камерами (проект)

2017-10-19T18:26:37Z

Dkorolev:

{{Карточка_проекта
|name=Автоматическая экспо- и цветокоррекция при съёмке IP камерами
|mentor=Королев Денис
|mentor_login={{URLENCODE:Dkorolev|WIKI}}
|semester=Осень 2017
|course=2
|summer=on
|number_of_students=5-10
|categorize=yes
}}

=== Что это за проект? ===
Когда вы снимаете фото или видео, ваша камера автоматически подстраивается под условия освещения. Когда у нее это не получается, цвета в изображении искажаются (желтые фотографии в домашнем свете, синие в сумерках и т.д.). Это несложно настроить вручную, но теперь представим, что одновременно работает несколько камер. Здесь задача усложнаяется: нужно, чтобы цветопередача и экспозиция на всех камерах была одинаковой.

Здесь нам пригодится опыт телевизионных съёмочных комплексов. На телевидении оператор не занимается настройкой параметров изображения и прочими техническими подробностями, его задача -- направить камеру. Даже фокус за него могут поправить его коллеги. Все параметры экспозиции и цветопередачи настраивают на специальном пульте.

Если взять обычные камеры видеонаблюдения, то они тоже настраиваются дистанционно и у нас есть возможность менять все нужные параметры, посылая на камеры соответствующие команды.

Задача этого проекта -- сделать программу для корректировки параметров камер как вручную, так и в полностью автоматическом режиме. Регулируемые параметры:

1. Цветопередача (Cb/Cr) 2. Экспозиция (яркость, контрастность)

Дополнительные возможности: 1. Мониторинг фокуса

Программа должна иметь пользовательский интерфейс для ручной настройки и переключения режимов (отключения автоматики). Программа предназначена для работы как на пользовательском компьютере (Windows), так и на сервере Linux на виртуальной машине с доступом к камерам через VPN. Адрес получения потока и адрес управления камерой могут отличаться (при работе через матрицу потоков или иной прокси-сервер).

Аналогичный проект на Ярмарке проектов ВШЭ: https://pf.hse.ru/208027466.html

=== Чему вы научитесь? ===
* Управление камерами через ONVIF, включая автодетекцию камер в сети.
* Анализ визуальных характеристик изображений

=== Какие начальные требования? ===
Владеть программированием, желательно иметь опыт общения с OpenCV.

=== Какие будут использоваться технологии? ===
* ONVIF

* OpenCV

* RTSP/MJPEG

=== Темы вводных занятий ===
Не в порядке изложения:

1. Архитектура проекта. API, внешние связи и зависимости.

2. Специфические технологии и используемые инструменты.

3. Доступные ресурсы, организация доступа.

4. Разделение ролей

=== Направления развития ===
Предлагаемые темы не являются чисто учебными, все они -- из рабочей практики и имеют выход в коммерческие сервисы, дополняя уже имеющийся функционал. Общая практика работы "на развитие" -- преуспевший в разработке некоего проекта студент (если хочет) становится "хостом" проекта и ведет его развитие дальше уже находясь в договорных отношениях с компанией.

Тема является частью более общего проекта по созданию съёмочного комплекса -- как с ручным управлением, так и с разной степенью автоматизации; как локального, так и полностью распределенного. Одно из внедрений такого комплекса начинается на ФКН для записи и трансляции значимых событий.

=== Критерии оценки ===
Про работу и оценки почитайте здесь: https://d.pr/143bq

Постарайтесь отнестись к этому с пониманием. Очень часто бодрое начало длится 3-4 недели и потом наступает тишина. Очень хочется, чтобы проекты доводились до запуска, а вы получали опыт успешной разработки и, возможно, работу в этих проектах уже в другом статусе. Но пока это для вас учебная работа, поэтому будем придерживаться описанных по ссылке правил и критериев. Спасибо!

===Как записаться?===

В общем доступе есть порядка двадцати проектов, относящихся к области видеотехнологий (стриминг, доставка потоков и т.д.). Чтобы всем было проще, эти проекты объединим в четыре группы и при записи на проект выбирайте группу, а конкретный проект и вашу роль в нем мы обсудим уже в рабочем порядке.

http://wiki.cs.hse.ru/images/thumb/f/f0/Projects.PNG/800px-Projects.PNG

=== Ориентировочное расписание занятий ===
Более точное расписание будет ясно после утверждения графика факультативов, пока ориентируемся на вторник, среду или пятницу во второй половине дня (после 15-16 часов).

На самом деле, для общения (как индивидуального, так и группового) удобно использовать средства видеосвязи -- это не заменяет очных встреч, но отлично дополняет их за счет возможности оперативно решать задачи "здесь и сейчас", сидя за удобным вам рабочим местом. Практически все темы проектов подразумевают работу в сети.

Денис Королев,

https://www.hse.ru/staff/dkorolev (там есть ссылки на соцсети)

+7 903 610 3290 (месенджеры по вкусу)

d.korolev@gmail.com

Автоматическая экспо- и цветокоррекция при съёмке IP камерами (проект)

2017-10-19T18:23:51Z

Dkorolev:

{{Карточка_проекта
|name=Автоматическая экспо- и цветокоррекция при съёмке IP камерами
|mentor=Королев Денис
|mentor_login={{URLENCODE:Dkorolev|WIKI}}
|semester=Осень 2017
|course=2
|summer=on
|number_of_students=5-10
|categorize=yes
}}

=== Что это за проект? ===
Когда вы снимаете фото или видео, ваша камера автоматически подстраивается под условия освещения. Когда у нее это не получается, цвета в изображении искажаются (желтые фотографии в домашнем свете, синие в сумерках и т.д.). Это несложно настроить вручную, но теперь представим, что одновременно работает несколько камер. Здесь задача усложнаяется: нужно, чтобы цветопередача и экспозиция на всех камерах была одинаковой.

Здесь нам пригодится опыт телевизионных съёмочных комплексов. На телевидении оператор не занимается настройкой параметров изображения и прочими техническими подробностями, его задача -- направить камеру. Даже фокус за него могут поправить его коллеги. Все параметры экспозиции и цветопередачи настраивают на специальном пульте.

Если взять обычные камеры видеонаблюдения, то они тоже настраиваются дистанционно и у нас есть возможность менять все нужные параметры, посылая на камеры соответствующие команды.

Задача этого проекта -- сделать программу для корректировки параметров камер как вручную, так и в полностью автоматическом режиме. Регулируемые параметры:

1. Цветопередача (Cb/Cr) 2. Экспозиция (яркость, контрастность)

Дополнительные возможности: 1. Мониторинг фокуса

Программа должна иметь пользовательский интерфейс для ручной настройки и переключения режимов (отключения автоматики). Программа предназначена для работы как на пользовательском компьютере (Windows), так и на сервере Linux на виртуальной машине с доступом к камерам через VPN. Адрес получения потока и адрес управления камерой могут отличаться (при работе через матрицу потоков или иной прокси-сервер).

Аналогичный проект на Ярмарке проектов ВШЭ: https://pf.hse.ru/208027466.html

=== Чему вы научитесь? ===
* Управление камерами через ONVIF, включая автодетекцию камер в сети.
* Анализ визуальных характеристик изображений

=== Какие начальные требования? ===
Владеть программированием, желательно иметь опыт общения с OpenCV.

=== Какие будут использоваться технологии? ===
* ONVIF

* OpenCV

* RTSP/MJPEG

=== Темы вводных занятий ===
Не в порядке изложения:

1. Архитектура проекта. API, внешние связи и зависимости.

2. Специфические технологии и используемые инструменты.

3. Доступные ресурсы, организация доступа.

4. Разделение ролей

=== Направления развития ===
Предлагаемые темы не являются чисто учебными, все они -- из рабочей практики и имеют выход в коммерческие сервисы, дополняя уже имеющийся функционал. Общая практика работы "на развитие" -- преуспевший в разработке некоего проекта студент (если хочет) становится "хостом" проекта и ведет его развитие дальше уже находясь в договорных отношениях с компанией.

Тема является частью более общего проекта по созданию съёмочного комплекса -- как с ручным управлением, так и с разной степенью автоматизации; как локального, так и полностью распределенного. Одно из внедрений такого комплекса начинается на ФКН для записи и трансляции значимых событий.

=== Критерии оценки ===
Про работу и оценки почитайте здесь: https://d.pr/143bq

Постарайтесь отнестись к этому с пониманием. Очень часто бодрое начало длится 3-4 недели и потом наступает тишина. Очень хочется, чтобы проекты доводились до запуска, а вы получали опыт успешной разработки и, возможно, работу в этих проектах уже в другом статусе. Но пока это для вас учебная работа, поэтому будем придерживаться описанных по ссылке правил и критериев. Спасибо!

===Как записаться?===

В общем доступе есть порядка двадцати проектов, относящихся к области видеотехнологий (стриминг, доставка потоков и т.д.). Чтобы всем было проще, эти проекты объединим в группы и при записи на проект выбирайте группу, а конкретный проект и вашу роль в нем мы обсудим уже в рабочем порядке.

http://wiki.cs.hse.ru/images/thumb/f/f0/Projects.PNG/800px-Projects.PNG

=== Ориентировочное расписание занятий ===
Более точное расписание будет ясно после утверждения графика факультативов, пока ориентируемся на вторник, среду или пятницу во второй половине дня (после 15-16 часов).

На самом деле, для общения (как индивидуального, так и группового) удобно использовать средства видеосвязи -- это не заменяет очных встреч, но отлично дополняет их за счет возможности оперативно решать задачи "здесь и сейчас", сидя за удобным вам рабочим местом. Практически все темы проектов подразумевают работу в сети.

Денис Королев,

https://www.hse.ru/staff/dkorolev (там есть ссылки на соцсети)

+7 903 610 3290 (месенджеры по вкусу)

d.korolev@gmail.com

Файл:Projects.PNG

2017-10-19T18:16:34Z

Dkorolev: Проекты по группам

Проекты по группам

Разработка сети доставки статического контента (проект)

2017-09-20T19:39:13Z

Dkorolev: Новая страница, с помощью формы Новый_проект

{{Карточка_проекта
|name=Разработка сети доставки статического контента
|mentor=Королев Денис
|mentor_login={{URLENCODE:Dkorolev|WIKI}}
|semester=Осень 2017
|course=2
|summer=on
|number_of_students=5-10
|categorize=yes
}}

=== Что это за проект? ===
Статический CDN -- это распределение нагрузки для обеспечения доступа множества пользователей к файлам. Используется для нагруженных веб-ресурсов, чтобы все зрители, пришедшие смотреть новую серию популярного сериала, получили ее на достойной скорости и без падения сервера от перегрузки. Для этого используется распределенное хранение, балансировка между серверами и каналами связи.

В данном проекте предлагается в качестве уже существующей распределенной среды хранения и передачи файлов использовать хранилище GoogleDrive, которое так удачно предлагает безлимитные аккаунты для корпоративных и академических доменов. Суть разработки состоит в решении задачи подстановки контента напрямую с серверов GoogleDrive, чтобы не пропускать трафик через серверы проекта.

Второй вопрос для решения -- лимит на количество обращений к файлу на GoogleDrive. Решается он путём создания копии файла и подмены ссылки на новый файл.

=== Чему вы научитесь? ===
* Погружение в работу с GoogleDrive

* Разработка UI/REST API

=== Какие начальные требования? ===
* Навыки веб-разработки.

=== Какие будут использоваться технологии? ===
* GoogleDrive API

=== Темы вводных занятий ===
1. Архитектура проекта. API, внешние связи и зависимости.

2. Специфические технологии и используемые инструменты.

3. Доступные ресурсы, организация доступа.

4. Разделение ролей

=== Направления развития ===
Это же немного хак. Есть "магический камень" (GoogleDrive), к нему нужен особый подход, чтобы использовать его не только как хотят авторы, но и немного иначе. Сколько ещё можно придумать интересных применений для этого ресурса -- жизнь покажет. Пока же туда успешно сохраняются записи трансляций с сервера (есть такой сервис on-air.pro), аккаунты используются для хранения многотерабайтных архивов медиаданных (очень удобно для ТВ и продакшенов) и т.д. Получится то, что в этом проекте описано, -- там же и хостинг для фото/видеогалерей и т.д.

=== Критерии оценки ===
Про работу и оценки почитайте здесь: https://d.pr/143bq

Постарайтесь отнестись к этому с пониманием. Очень часто бодрое начало длится 3-4 недели и потом наступает тишина. Очень хочется, чтобы проекты доводились до запуска, а вы получали опыт успешной разработки и, возможно, работу в этих проектах уже в другом статусе. Но пока это для вас учебная работа, поэтому будем придерживаться описанных по ссылке правил и критериев. Спасибо!

=== Ориентировочное расписание занятий ===
Более точное расписание будет ясно после утверждения графика факультативов, пока ориентируемся на вторник, среду или пятницу во второй половине дня (после 15-16 часов).

На самом деле, для общения (как индивидуального, так и группового) удобно использовать средства видеосвязи -- это не заменяет очных встреч, но отлично дополняет их за счет возможности оперативно решать задачи "здесь и сейчас", сидя за удобным вам рабочим местом. Практически все темы проектов подразумевают работу в сети.

Денис Королев,

https://www.hse.ru/staff/dkorolev (там есть ссылки на соцсети)

+7 903 610 3290 (месенджеры по вкусу)

d.korolev@gmail.com

Разработка сервиса воспроизведения Video on Demand (проект)

2017-09-20T19:24:40Z

Dkorolev: Новая страница, с помощью формы Новый_проект

{{Карточка_проекта
|name=Разработка сервиса воспроизведения Video on Demand
|mentor=Королев Денис
|mentor_login={{URLENCODE:Dkorolev|WIKI}}
|semester=Осень 2017
|course=2
|summer=on
|number_of_students=5-10
|categorize=yes
}}

=== Что это за проект? ===
Задача -- разработать сервис, который будет воспроизводить видеозаписи, хранящиеся на Google Drive или указанном WebDAV/FTP сервере по команде или по расписанию, и формировать из них поток RTSP/RTMP. К этому сервису нужен веб-интерфейс и REST API для автоматического взаимодействия. Помимо этого, он должен поддерживать управление через ONVIF, определяясь для остальных устройств как NVR.

Сервис нужен для следующих типовых задач:

1. Воспроизведение в поток по расписанию заготовленных записей. Это нужно для публикации стримов в соцсети (если залить файл, то соцсеть это событие никак не продвигает, а если отправить стрим, то такой контент имеет приоритет для соцсети и его проще продвигать в массы.

2. При воспроизведении по расписанию (по времени, по триггеру) совместно с потоковым микшером можно формировать канал постоянного вещания, переключая микшер на записи по плейлисту и запуская их. При этом хранение контента -- в облаке.

3. При работе с облачным видеомикшером любые записи из архива могут быть включены в эфир.

4. Дополнение к сервису видеозаписи потоков (вместе они образуют полноценный "магнитофон").

Сервис предназначен для формирования видеопотока из видеозаписей. Хранение записей: GoogleDrive, работа по расписанию, по нажатию кнопки. Интерфейс загрузки, каталог пользовательских записей, представление на таймлайне и в календаре (API Google Calendar). Пригодятся: Ruby on Rails, OAuth, соответствующие API. Дополнительно: headless браузер с передачей данных для ввода на странице для формирования потоков с веб-страниц (вебинары и тд). Проект групповой. Правила работы: https://d.pr/143bq

=== Чему вы научитесь? ===
Сам по себе процесс запуска воспроизведения из файла в поток -- дело нехитрое: ffmpeg одной простой командой отправит на нужный адрес поток RTMP, а FFSERVER, VLC или аналогичный сервер сформирует RTSP поток, который в реальном времени может забрать любой потребитель (микшер, матрица, монитор и тд). Прочитать файл с аккаунта на GoogleDrive тоже задача не выдающаяся, хотя и полезная в жизненных ситуациях, учитывая, что этот сервис предлагает безлимитные аккаунты.
Здесь важно обеспечить управляемость и низкую задержку выполнения команды, а также совместимость с ONVIF. К пользовательскому интерфейсу, если его делать "со всеми удобствами", тоже довольно серьезные требования по отзывчивости (хотя, в минимальной версии этот сервис может иметь весьма аскетичный интерфейс).

=== Какие начальные требования? ===
* Навыки или страстное желание освоить веб-разработку, крайне желательно придерживаться Ruby on Rails.

* Владение Linux (придется работать с сервером на виртуальной машине),

* API соцсетей (опционально)

=== Какие будут использоваться технологии? ===
* Стриминг RTSP/RTMP

* GoogleDrive API, WebDAV, FTP

* ONVIF

* OAuth

=== Темы вводных занятий ===
Не в порядке изложения:

1. Архитектура проекта. API, внешние связи и зависимости.

2. Специфические технологии и используемые инструменты.

3. Доступные ресурсы, организация доступа.

4. Разделение ролей

=== Направления развития ===
Это специфический инструмент. Есть системы управления контентом, типа XIBO, есть playout-серверы для телевизионного вещания или для indoor-TV (панели в супермаркетах и других общественных местах), но здесь решается узкая задача: как контент из облака или своего сервера отправить в поток для дальнейшего использования.
Как аналог одного из применений, можно назвать BufferApp - сервис отложенного постинга сообщений в соцсети. Здесь тоже по расписанию, но отправка видеопотоков (интеграция с API сетей может быть вынесена в отдельный проект).

Если рассматривать развитие проекта как самостоятельного сервиса, то он может объединиться с рекордером и работать с облачным хранилищем. Полезно не только для телевизионного применения, но и в более обширной области видеонаблюдения (обычно для этого используют локально установленные сетевые видеорекордеры) и в связанных с ней задачах -- наблюдение с выводом в публичный доступ и т.д. Бывали заказы на timelapse строящихся объектов.

=== Критерии оценки ===
Про работу и оценки почитайте здесь: https://d.pr/143bq

Постарайтесь отнестись к этому с пониманием. Очень часто бодрое начало длится 3-4 недели и потом наступает тишина. Очень хочется, чтобы проекты доводились до запуска, а вы получали опыт успешной разработки и, возможно, работу в этих проектах уже в другом статусе. Но пока это для вас учебная работа, поэтому будем придерживаться описанных по ссылке правил и критериев. Спасибо!

=== Ориентировочное расписание занятий ===
Более точное расписание будет ясно после утверждения графика факультативов, пока ориентируемся на вторник, среду или пятницу во второй половине дня (после 15-16 часов).

На самом деле, для общения (как индивидуального, так и группового) удобно использовать средства видеосвязи -- это не заменяет очных встреч, но отлично дополняет их за счет возможности оперативно решать задачи "здесь и сейчас", сидя за удобным вам рабочим местом. Практически все темы проектов подразумевают работу в сети.

Денис Королев,

https://www.hse.ru/staff/dkorolev (там есть ссылки на соцсети)

+7 903 610 3290 (месенджеры по вкусу)

d.korolev@gmail.com

Разработка сервиса Speech-to-text на базе существующего API (командный проект)

2017-09-20T19:08:19Z

Dkorolev:

{{Карточка_командного_проекта
|name=Разработка сервиса Speech-to-text на базе существующего API
|company=On-Air.Pro
|semester=Осень 2017
|course=3
|number_of_students=2-8
|categorize=yes
}}

=== Что это за проект? ===
Разработка в уже действиующем проекте, направления работы -- от UI/UX до предобработки потоков и анализа и обработки результатов распознавания и перевода.

Суть проекта: пользователь загружает видео- или аудио-файл, файл преобразуется для отправки в один или несколько сервисов распознавания, далее результат высылается на электронную почту пользователя.

Сервисов распознавания и перевода существует много, но всилу специфики их назначения и произвольного характера поступающих от пользователей исходных файлов, требуется предобработка и последующая сборка результатов. Взаимодействие со сторонними сервисами -- через API. При этом, различные сервисы по-разному воспринимают особенности исходных записей. Например, одни не любят телефонные разговоры, а другие -- многоголосые записи. Стоимость обработки также различается.

Отдельное направление -- разработка личного кабинета со статистикой, сохранением результатов ранее проведенных распознаваний и исходных файлов (файлы сохраняются на аккаунте GoogleDrive). В том числе, требуется поддержка обработки папок (GoogleDrive, FTP, WebDAV) в качестве источников файлов и места сохранения результатов.

Также отдельный подпроект -- подключение не только распознавания, но и перевода (также через API).

Результаты распознавания и перевода могут быть представлены как простым текстом, так и размеченным таймкодами, облаком тегов и т.д.

Заметим, что операции распознавания и перевода доступны в реальном времени и одной из задач (на практике уже проверено -- работает) будет реализовать для пользователей возможность давать на вход сервиса не только файлы, но и потоки, а на выходе -- поток субтитров, в т.ч. автоматически стримить в Yotube.

Разработка на Ruby on Rails.

=== Чему научатся студенты? Что самое интересное в проекте? ===
В зависимости от выбранного направления работы:

* работа с API сторонних сервисов

* предобработка потоков (gstreamer, ffmpeg)

* UI/UX разработка

* OAuth, работа с платежной системой

* Работа с хранилищами файлов (GoogleDrive, WebDAV, FTP)

Задачи разносторонние, поэтому каждый найдет себе что-то по вкусу.

=== Организация работы (Как студенты будут работать в команде?) ===
Роли и точный состав работ формируется по итогам регистрации желающих участвовать (команда может быть смешанной, в т.ч. со студентами МИЭМ и других факультетов, аналогичная тема заявлена на ярмарке проектов.

Далее организуется slack и трекер (обычно trello), где ведется рабочее общение и трекинг задач.
Встречи -- по договоренности (на первых порах это понадобится точно) на Кочновском, альтернативный и более частый вариант -- аудио/видеосвязь. Удобно, т.к. можно собираться по актуальному вопросу безотлагательно и в любое время в любом составе.

=== Компоненеты (Из каких частей состоит проект?) ===
* Связка с API сервисов распознавания и перевода (отдельные подпроекты)

* UI (личный кабинет)

* UX всего сервиса, прототип.

* Взаимодействие с хранилищами

* Платежный модуль

* Пред- и пост-обработка данных пользователя.

=== Какие будут использоваться технологии? ===
* API сервисов распознавания и перевода, Google Drive и Youtube, ЯндексКассы.

* Ruby on Rails, Java Script

* Анализ видео- и аудиофайлов, их предобработка

* Анализ текстов и их обработка

=== Какие начальные требования? ===
В зависимости от выбранного направления -- владение соответствующими технологиями и языками. Очевидно, потребуется знать или изучить большинство используемых инструментов и языков.

=== Темы вводных занятий ===
Не в порядке изложения:

1. Архитектура проекта. API, внешние связи и зависимости.

2. Специфические технологии и используемые инструменты.

3. Доступные ресурсы, организация доступа.

4. Разделение ролей

=== Критерии оценки ===
Про работу и оценки почитайте здесь: https://d.pr/143bq

Постарайтесь отнестись к этому с пониманием. Очень часто бодрое начало длится 3-4 недели и потом наступает тишина. Очень хочется, чтобы проекты доводились до запуска, а вы получали опыт успешной разработки и, возможно, работу в этих проектах уже в другом статусе. Но пока это для вас учебная работа, поэтому будем придерживаться описанных по ссылке правил и критериев. Спасибо!

=== Похожие проекты ===
Данный проект в текущем виде доступен по адресу transcript.on-air.pro
Распознавание голоса также возможно с использованием приложений, но полного аналога в сети не встречали (чтобы файл и поток отдавал в тексте, причем, с таймкодами, и в srt потоке для субтитров в реальном времени).

Данный проект на ярмарке проектов ВШЭ: https://pf.hse.ru/208036688.html

=== Контактная информация ===
Денис Королев,

https://www.hse.ru/staff/dkorolev (там есть ссылки на соцсети)

+7 903 610 3290 (месенджеры по вкусу)

d.korolev@gmail.com

Разработка сервиса Speech-to-text на базе существующего API (проект)

2017-09-20T19:08:13Z

Dkorolev: Новая страница, с помощью формы Новый_проект

{{Карточка_проекта
|name=Разработка сервиса Speech-to-text на базе существующего API
|mentor=Королев Денис
|mentor_login={{URLENCODE:Dkorolev|WIKI}}
|semester=Осень 2017
|course=2
|summer=on
|number_of_students=5-10
|categorize=yes
}}

=== Что это за проект? ===
Разработка в уже действиующем проекте, направления работы -- от UI/UX до предобработки потоков и анализа и обработки результатов распознавания и перевода.

Суть проекта: пользователь загружает видео- или аудио-файл, файл преобразуется для отправки в один или несколько сервисов распознавания, далее результат высылается на электронную почту пользователя.

Сервисов распознавания и перевода существует много, но всилу специфики их назначения и произвольного характера поступающих от пользователей исходных файлов, требуется предобработка и последующая сборка результатов. Взаимодействие со сторонними сервисами -- через API. При этом, различные сервисы по-разному воспринимают особенности исходных записей. Например, одни не любят телефонные разговоры, а другие -- многоголосые записи. Стоимость обработки также различается.

Отдельное направление -- разработка личного кабинета со статистикой, сохранением результатов ранее проведенных распознаваний и исходных файлов (файлы сохраняются на аккаунте GoogleDrive). В том числе, требуется поддержка обработки папок (GoogleDrive, FTP, WebDAV) в качестве источников файлов и места сохранения результатов.

Также отдельный подпроект -- подключение не только распознавания, но и перевода (также через API).

Результаты распознавания и перевода могут быть представлены как простым текстом, так и размеченным таймкодами, облаком тегов и т.д.

Заметим, что операции распознавания и перевода доступны в реальном времени и одной из задач (на практике уже проверено -- работает) будет реализовать для пользователей возможность давать на вход сервиса не только файлы, но и потоки, а на выходе -- поток субтитров, в т.ч. автоматически стримить в Yotube.

Разработка на Ruby on Rails.

=== Чему вы научитесь? ===
В зависимости от выбранного направления работы:

* работа с API сторонних сервисов

* предобработка потоков (gstreamer, ffmpeg)

* UI/UX разработка

* OAuth, работа с платежной системой

* Работа с хранилищами файлов (GoogleDrive, WebDAV, FTP)

Задачи разносторонние, поэтому каждый найдет себе что-то по вкусу.

=== Какие начальные требования? ===
В зависимости от выбранного направления -- владение соответствующими технологиями и языками. Очевидно, потребуется знать или изучить большинство используемых инструментов и языков.

=== Какие будут использоваться технологии? ===
* API сервисов распознавания и перевода, Google Drive и Youtube, ЯндексКассы.

* Ruby on Rails, Java Script

* Анализ видео- и аудиофайлов, их предобработка

* Анализ текстов и их обработка

=== Темы вводных занятий ===
Не в порядке изложения:

1. Архитектура проекта. API, внешние связи и зависимости.

2. Специфические технологии и используемые инструменты.

3. Доступные ресурсы, организация доступа.

4. Разделение ролей

=== Направления развития ===
Сейчас этот сервис работает лишь для распознавания голосовых записей, может работать с потоками (но для пользователей эта возможность закрыта, а так титры в Youtube делаются на лету), при этом выдача распознанных файлов приходит пользователю с таймкодами. Но это пока очень сырой проект, выросший из прошлогодней курсовой работы в МИЭМ. В развитие видятся следующие направления:

* Повышение качества распознавания -- не только подбором провайдера сервиса распознавания (сейчас Google, тестируются два других), но и предобработкой (особенно шумных и искаженных сжатием) записей и анализом результирующего текста, возможно, по дублирующему результату от альтернативного провайдера;

* Введение распознавания графических образов из видео (про это есть отдельный проект). Актуально для мониторинговых компаний, которые распознают телевизионный эфир (а там много интересного пишут в lower third и не только);

* Пользовательский интерфейс для всего этого. Сейчас его можно сказать что нет.

Помимо этого предстоит много сделать для интеграции в рабочие процессы заказчиков. Например, обработку папок в облачных дисках и по адресам ftp/webdav вместо загрузки файлов непосредственно на сайте.

=== Критерии оценки ===
Про работу и оценки почитайте здесь: https://d.pr/143bq

Постарайтесь отнестись к этому с пониманием. Очень часто бодрое начало длится 3-4 недели и потом наступает тишина. Очень хочется, чтобы проекты доводились до запуска, а вы получали опыт успешной разработки и, возможно, работу в этих проектах уже в другом статусе. Но пока это для вас учебная работа, поэтому будем придерживаться описанных по ссылке правил и критериев. Спасибо!

=== Ориентировочное расписание занятий ===
Более точное расписание будет ясно после утверждения графика факультативов, пока ориентируемся на вторник, среду или пятницу во второй половине дня (после 15-16 часов).

На самом деле, для общения (как индивидуального, так и группового) удобно использовать средства видеосвязи -- это не заменяет очных встреч, но отлично дополняет их за счет возможности оперативно решать задачи "здесь и сейчас", сидя за удобным вам рабочим местом. Практически все темы проектов подразумевают работу в сети.

Денис Королев,

https://www.hse.ru/staff/dkorolev (там есть ссылки на соцсети)

+7 903 610 3290 (месенджеры по вкусу)

d.korolev@gmail.com

Разработка редактора компоновок для сервиса потокового видеовещания (командный проект)

2017-09-20T18:57:11Z

Dkorolev:

{{Карточка_командного_проекта
|name=Разработка редактора компоновок для сервиса потокового видеовещания
|company=On-Air.Pro
|semester=Осень 2017
|course=3
|number_of_students=
|categorize=yes
}}

=== Что это за проект? ===
Редактор компоновок позволяет из нескольких видеопотоков собрать на одном экране композицию, загрузить/выбрать фон, добавить текстовые и графические элементы. Используется в прямых трансляциях, записи, подключается к микшеру потоков или непосредственно к источнику трансляции. Это не видеомикшер в обычном понимании (про видеомикшер есть отдельная тема), а отдельный модуль, использующий тот же движок, но для формирования составной картинки, использоваться выходной поток может как сам по себе (сразу в трансляцию/запись), так и в микшере среди прочих входов.
Основная область применения -- трансляция лекций и других мероприятий, где одновременно нужно показывать выступающего и экран, при этом, нет ресурсов на режиссуру в эфире. Здесь важно иметь возможность сделать 2-3 компоновки, заставку и переключать их время от времени в зависимости от происходящего. Высоких требований к скорости выполнения, как в микшере, нет (2-3 секунды задержки не критичны). С другой стороны, здесь требуется создать конструктор компоновок и интерфейс управления ими во время эфира, и всё это на том же движке, что микшер.
В развитие проекта для интересующихся соответствующими направлениями можно предложить автопереключение компоновок (анализ потоков на изменения и принятие режиссерских решений).

=== Чему научатся студенты? Что самое интересное в проекте? ===
Как и в Микшере, работа связана с движком на базе gstreamer -- само по себе познавательное дело, т.к. применимость gstreamer'а не ограничивается сведением пото созданием отзывчивого пользовательского интерфейса.

В зависимости от комплектации группы, будет разрабатываться больше или меньше возможностей. Например, полезный в этой области навык -- анализ потоков для дальнейшего принятия режиссерских решений. Интересующимся этой темой может быть полезно заглянуть в проекты про автоматическую съёмку и автоматическую режиссуру.

Коротко о связи с реальностью: изначально именно компоновки были соновной идеей On-air.pro, который строился как публичный сервис для трансляции лекций с нескольких источников. Но всилу ограничений используемого движка компоновки не стали киллер-фичей, зато сервис увлеченно транслирует в соцсети. Тем не менее, как только созреет микшер, редактор компоновок и другие модули, выставленные на проработку, они займут своё место в проекте.

=== Организация работы (Как студенты будут работать в команде?) ===
Роли и точный состав работ формируется по итогам регистрации желающих участвовать (команда может быть смешанной, в т.ч. со студентами МИЭМ и других факультетов, аналогичная тема заявлена на ярмарке проектов.

Далее организуется slack и трекер (обычно trello), где ведется рабочее общение и трекинг задач.
Встречи -- по договоренности (на первых порах это понадобится точно) на Кочновском, альтернативный и более частый вариант -- аудио/видеосвязь. Удобно, т.к. можно собираться по актуальному вопросу безотлагательно и в любое время в любом составе.

=== Компоненеты (Из каких частей состоит проект?) ===
Backend -- движок на основе gstreamer (SnowMix / Voctomix)
Frontend --
1. редактор компоновок с загрузкой элементов оформления, библиотекой этих элементов и сохранением пресетов,
2. также эфирный контроллер (переключатель компоновок во время эфира). Фактически, это выбор из подготовленных к эфиру компоновок. Превью задействованных источников нужно, но может быть урезанным.
3. титровальня (в простом случае -- список заранее написанных титров и выбор нужных в момент показа). Для увлеченных распознаванием можно предложить отдельный подпроект с автодетекцией человека в кадре (обучение по фото или, если совсем уходить в фантастику -- по открытым данным, соцсетям и тд).

=== Какие будут использоваться технологии? ===
* Gstreamer и с ним Snowmix/Voctomix, возможно -- ffmpeg

* Виртуальные машины linux, nginx и сопутствующие инструменты

* Ruby on Rails (для унификации) и необходимые средства для UI (например, meteor, это ещё нужно обоснованно решить).

* Опционально: ONVIF для управления камерами (переход по предустановленным позициям)

=== Какие начальные требования? ===
В любом случае понадобятся навыки программирования (будь то веб-разработка или работа с движком GStreamer/Snowmix), работы с Linux (потому что виртуалка в сети). Остальное -- специфика, с которой можно познакомиться по ходу проекта. Веб-часть на Ruby on Rails -- для унификации с базовым проектом.

Ожидается, что разработчики умеют пользоваться поисковыми системами и stackoverflow. Руководитель может консультировать вас по предметной области (видео/тв), но не по программной разработке.

Разработка обычно имеет недельный цикл трекинга, встречи (как индивидуальные, так и групповые) по умолчанию -- по видеосвязи, но порой надо и очно (на факультете). Необходимые технические и серверные ресурсы предоставляются.

=== Темы вводных занятий ===
Не в порядке изложения:

1. Архитектура проекта. API, внешние связи и зависимости.

2. Специфические технологии и используемые инструменты.

3. Доступные ресурсы, организация доступа.

4. Разделение ролей

=== Критерии оценки ===
Про работу и оценки почитайте здесь: https://d.pr/143bq

Постарайтесь отнестись к этому с пониманием. Очень часто бодрое начало длится 3-4 недели и потом наступает тишина. Очень хочется, чтобы проекты доводились до запуска, а вы получали опыт успешной разработки и, возможно, работу в этих проектах уже в другом статусе. Но пока это для вас учебная работа, поэтому будем придерживаться описанных по ссылке правил и критериев. Спасибо!

=== Похожие проекты ===
Любые вебинары, сервисы многосторонней видеосвязи -- все они показывают несколько потоков на одном экране. Но, кто пробовал делать трансляцию какой-нибудь конференции или защит через GoogleHangouts, поймёт, почему для этих целей видеоболтушки не используют.
Есть нынешняя версия On-Air.Pro, где поддерживаются многоэкранные компоновки, но там есть проблемы синхронизации потоков и, главное, компоновки во время трансляции менять нельзя. Всё потому, что там работает ffmpeg, а надо бы движок видеомикшера.

Проект разработки потокового видеомикшера на ярмарке проектов: https://pf.hse.ru/208034867.html

=== Контактная информация ===
Денис Королев,

https://www.hse.ru/staff/dkorolev (там есть ссылки на соцсети)

+7 903 610 3290 (месенджеры по вкусу)

d.korolev@gmail.com

Разработка редактора компоновок для сервиса потокового видеовещания (проект)

2017-09-20T18:57:00Z

Dkorolev: Новая страница, с помощью формы Новый_проект

{{Карточка_проекта
|name=Разработка редактора компоновок для сервиса потокового видеовещания
|mentor=Королев Денис
|mentor_login={{URLENCODE:Dkorolev|WIKI}}
|semester=Осень 2017
|course=2
|summer=on
|number_of_students=5-10
|categorize=yes
}}

=== Что это за проект? ===
Редактор компоновок позволяет из нескольких видеопотоков собрать на одном экране композицию, загрузить/выбрать фон, добавить текстовые и графические элементы. Используется в прямых трансляциях, записи, подключается к микшеру потоков или непосредственно к источнику трансляции. Это не видеомикшер в обычном понимании (про видеомикшер есть отдельная тема), а отдельный модуль, использующий тот же движок, но для формирования составной картинки, использоваться выходной поток может как сам по себе (сразу в трансляцию/запись), так и в микшере среди прочих входов.
Основная область применения -- трансляция лекций и других мероприятий, где одновременно нужно показывать выступающего и экран, при этом, нет ресурсов на режиссуру в эфире. Здесь важно иметь возможность сделать 2-3 компоновки, заставку и переключать их время от времени в зависимости от происходящего. Высоких требований к скорости выполнения, как в микшере, нет (2-3 секунды задержки не критичны). С другой стороны, здесь требуется создать конструктор компоновок и интерфейс управления ими во время эфира, и всё это на том же движке, что микшер.
В развитие проекта для интересующихся соответствующими направлениями можно предложить автопереключение компоновок (анализ потоков на изменения и принятие режиссерских решений).

=== Чему вы научитесь? ===
Как и в Микшере, работа связана с движком на базе gstreamer -- само по себе познавательное дело, т.к. применимость gstreamer'а не ограничивается сведением пото созданием отзывчивого пользовательского интерфейса.

В зависимости от комплектации группы, будет разрабатываться больше или меньше возможностей. Например, полезный в этой области навык -- анализ потоков для дальнейшего принятия режиссерских решений. Интересующимся этой темой может быть полезно заглянуть в проекты про автоматическую съёмку и автоматическую режиссуру.

Коротко о связи с реальностью: изначально именно компоновки были соновной идеей On-air.pro, который строился как публичный сервис для трансляции лекций с нескольких источников. Но всилу ограничений используемого движка компоновки не стали киллер-фичей, зато сервис увлеченно транслирует в соцсети. Тем не менее, как только созреет микшер, редактор компоновок и другие модули, выставленные на проработку, они займут своё место в проекте.

=== Организация работы (Как студенты будут работать в команде?) ===
Роли и точный состав работ формируется по итогам регистрации желающих участвовать (команда может быть смешанной, в т.ч. со студентами МИЭМ и других факультетов, аналогичная тема заявлена на ярмарке проектов.

Далее организуется slack и трекер (обычно trello), где ведется рабочее общение и трекинг задач.
Встречи -- по договоренности (на первых порах это понадобится точно) на Кочновском, альтернативный и более частый вариант -- аудио/видеосвязь. Удобно, т.к. можно собираться по актуальному вопросу безотлагательно и в любое время в любом составе.

=== Какие начальные требования? ===
В любом случае понадобятся навыки программирования (будь то веб-разработка или работа с движком GStreamer/Snowmix), работы с Linux (потому что виртуалка в сети). Остальное -- специфика, с которой можно познакомиться по ходу проекта. Веб-часть на Ruby on Rails -- для унификации с базовым проектом.

Ожидается, что разработчики умеют пользоваться поисковыми системами и stackoverflow. Руководитель может консультировать вас по предметной области (видео/тв), но не по программной разработке.

Разработка обычно имеет недельный цикл трекинга, встречи (как индивидуальные, так и групповые) по умолчанию -- по видеосвязи, но порой надо и очно (на факультете). Необходимые технические и серверные ресурсы предоставляются.

=== Какие будут использоваться технологии? ===
* Gstreamer и с ним Snowmix/Voctomix, возможно -- ffmpeg

* Виртуальные машины linux, nginx и сопутствующие инструменты

* Ruby on Rails (для унификации) и необходимые средства для UI (например, meteor, это ещё нужно обоснованно решить).

* Опционально: ONVIF для управления камерами (переход по предустановленным позициям)

=== Темы вводных занятий ===
Не в порядке изложения:

1. Архитектура проекта. API, внешние связи и зависимости.

2. Специфические технологии и используемые инструменты.

3. Доступные ресурсы, организация доступа.

4. Разделение ролей

=== Направления развития ===
Редактор компоновок -- это компонент потокового видеомикшера, причём, этот проект актуален безотносительно того, в каком виде будет реализован видеомикшер -- в "скромном", для скрытого выполнения операций с видеопотоками (поставить логотип/титры, переключиться на заставку при пропадении входного потока, переключиться на другой источник), или в "полноценном", то есть, с пользовательским интерфейсом видеомикшера, со всеми подобающими кнопками, экранами и т.д. В любом случае, мультиэкранное изображение нужно,а для этого, помимо движка микшера, нужно иметь интерфейс для его создания: как с нуля, так и из готовых пресетов. В свою очередь, конструктор компоновок и титровальня -- это лишь с виду простые программы, на деле же там может быть заложено много интересных возможностей, вплоть до автоматического распознавания лиц на крупном плане, чтобы рекомендовать правильные титры.

=== Критерии оценки ===
Про работу и оценки почитайте здесь: https://d.pr/143bq

Постарайтесь отнестись к этому с пониманием. Очень часто бодрое начало длится 3-4 недели и потом наступает тишина. Очень хочется, чтобы проекты доводились до запуска, а вы получали опыт успешной разработки и, возможно, работу в этих проектах уже в другом статусе. Но пока это для вас учебная работа, поэтому будем придерживаться описанных по ссылке правил и критериев. Спасибо!

=== Ориентировочное расписание занятий ===
Более точное расписание будет ясно после утверждения графика факультативов, пока ориентируемся на вторник, среду или пятницу во второй половине дня (после 15-16 часов).

На самом деле, для общения (как индивидуального, так и группового) удобно использовать средства видеосвязи -- это не заменяет очных встреч, но отлично дополняет их за счет возможности оперативно решать задачи "здесь и сейчас", сидя за удобным вам рабочим местом. Практически все темы проектов подразумевают работу в сети.

Денис Королев,

https://www.hse.ru/staff/dkorolev (там есть ссылки на соцсети)

+7 903 610 3290 (месенджеры по вкусу)

d.korolev@gmail.com

Разработка программного модуля управления ONVIF-совместимыми IP PTZ камерами (проект)

2017-09-20T18:47:09Z

Dkorolev: Новая страница, с помощью формы Новый_проект

{{Карточка_проекта
|name=Разработка программного модуля управления ONVIF-совместимыми IP PTZ камерами
|mentor=Королев Денис
|mentor_login={{URLENCODE:Dkorolev|WIKI}}
|semester=Осень 2017
|course=2
|summer=on
|number_of_students=5-10
|categorize=yes
}}

=== Что это за проект? ===
Для управления цифровыми камерами видеонаблюдения существует ряд программ и устройств, использующих единый стандарт ONVIF. Но ни одна из этих программ и ни одно устройство не предназначены для управления камерами в "операторской манере", когда движения совершаются плавно и сразу по трем измерениям (поворот/наклон/увеличение -- PTZ). Также, камеры могут настраиваться по многим параметрам изображения, в некоторых камерах есть поддержка звука, но эти параметры не регулируются устройствами, предназначенными для видеонаблюдения.

Нужно разработать сервис управления ONVIF PTZ камерами. Взаимодействие с пользователем через веб-интерфейс с поддержкой наборов камер в личном кабинете, с сохранением пресетов.

Специфические особенности, отличающие от существующих программ и веб-интерфейса самих камер:

1. "Операторское" движение камеры (одновременное и плавное перемещение по всем трём осям)

2. Настройка "на лету" параметров изображения, звука и потока.

3. Предусмотреть возможность подключения автоматического трекера и автоцветокоррекции (см. соседние проекты и проекты на Ярмарке проектов: https://pf.hse.ru/208027417.html https://pf.hse.ru/208027466.html)

Для локального использования предусмотреть установку под Windows, по умолчанию установка на linux-сервере с VPN, экспериментально -- на роутерах с прошивкой OpenWRT.

=== Чему вы научитесь? ===
* Тонкое управление устройствами (IP PTZ камерами) по протоколу ONVIF

* Имитация работы оператора-человека

* Создание сервиса управления, работающего на различных платформах

* Создание отзывчивого веб-интерфейса для управления камерой.

=== Какие начальные требования? ===
Иметь представление о веб-разработке. при этом, больше внимания уделить JS и отзывчивому пользовательскому интерфейсу.

Работа с ONVIF возможна на разных языках, язык выбирается так, чтобы результат запускался на указанных платформах.

=== Какие будут использоваться технологии? ===
* ONVIF

* Разработать REST API

* AJAX и другие элементы разработки отзывчивого UI

=== Темы вводных занятий ===
1. Архитектура проекта. API, внешние связи и зависимости.

2. Специфические технологии и используемые инструменты.

3. Доступные ресурсы, организация доступа.

4. Разделение ролей

=== Направления развития ===
Это один из проектов, имеющих в будущем общее будущее: объединение возможностей управления PTZ IP камерами, включая автоматическую съёмку (в т.ч. с трекингом человека), автоцвето/экспокоррекцию и т.д. сделает дешевые и вполне качественные IP камеры серьезным конкурентом современным дорогостоящим телевизионным камерам, требующим не менее дорогостоящих компонентов для сборки съёмочных комплексов. Здесь же мы обходимся обычными компьютерами и локальной сетью, при этом можем строить полностью распределенные съёмочные комплексы, где режиссер, камеры и операторы могут находиться в разных местах.

=== Критерии оценки ===
Про работу и оценки почитайте здесь: https://d.pr/143bq

Постарайтесь отнестись к этому с пониманием. Очень часто бодрое начало длится 3-4 недели и потом наступает тишина. Очень хочется, чтобы проекты доводились до запуска, а вы получали опыт успешной разработки и, возможно, работу в этих проектах уже в другом статусе. Но пока это для вас учебная работа, поэтому будем придерживаться описанных по ссылке правил и критериев. Спасибо!

=== Ориентировочное расписание занятий ===
Более точное расписание будет ясно после утверждения графика факультативов, пока ориентируемся на вторник, среду или пятницу во второй половине дня (после 15-16 часов).

На самом деле, для общения (как индивидуального, так и группового) удобно использовать средства видеосвязи -- это не заменяет очных встреч, но отлично дополняет их за счет возможности оперативно решать задачи "здесь и сейчас", сидя за удобным вам рабочим местом. Практически все темы проектов подразумевают работу в сети.

Денис Королев,

https://www.hse.ru/staff/dkorolev (там есть ссылки на соцсети)

+7 903 610 3290 (месенджеры по вкусу)

d.korolev@gmail.com

Разработка программного адаптера ONVIF устройств для видеомикшера VMix (командный проект)

2017-09-20T18:39:57Z

Dkorolev:

{{Карточка_командного_проекта
|name=Разработка программного адаптера ONVIF устройств для видеомикшера VMix
|company=On-Air.Pro
|semester=Осень 2017
|course=3
|number_of_students=2-3
|categorize=yes
}}

=== Что это за проект? ===
Небольшой проект для решения узкой, но актуальной задачи.
Для монтажа многокамерной видеосъёмки и трансляции используют как аппаратные, так и программные видеомикшеры. Один из наиболее удобных и функциональных программных микшеров -- VMix, он не только поддерживает работу с различным оборудованием захвата сигнала с камер, но и прекрасно работает с RTSP-потоками от IP-камер, а значит, с ним совместимы все камеры видеонаблюдения при их низкой стоимости и гибкости настройки. В частности, из VMix можно задать несколько позиций поворота одной камеры и переходить между ними в прямом эфире, как между разными камерами (virtual input), что облегчает работу режиссера (и исключает необходимость в операторе) в прямом эфире.
Но разработчики VMix ориентировались на рынок профессионального телевизионного оборудования и для управления камерами включили только проприетарные стандарты дорогих камер, в то время как системы видеонаблюдения давно используют единый открытый стандарт для всех видов используемого оборудования -- ONVIF.
Задача: сделать прокси-адаптер, который будет транслировать команды VMix в команды ONVIF.
Прототип такой программы уже сделан, но довести его до продукта, сделать локальную версию для Windows (как службу + интерфейс управления) и сетевую для Linux-сервера -- это ещё предстоит.

Минимальный проект:
Помимо 11 команд и 2 настроек для управления PTZ, понадобится управлять Alarm-статусами камеры (так можно зажигать индикатор "камера в эфире", его называют Tally).

Расширенный проект:
Настройка камер включает экспо- и цветокоррекцию, причём, не коррекцию потоков, а настройку самих камер через ONVIF. Эта задача вынесена в отдельный проект (здесь и в ярмарке проектов), но может быть реализована в рамках данного проекта.

=== Чему научатся студенты? Что самое интересное в проекте? ===
* Управление видеокамерами IP PTZ через ONVIF

* Автоматизация рутинных процедур в видеопроизводстве

* Интеграция ПО с видеомикшером VMix, оптимизация рабочего процесса

В расширенном проекте:

* Анализ видеопотоков

=== Организация работы (Как студенты будут работать в команде?) ===
Роли и точный состав работ формируется по итогам регистрации желающих участвовать (команда может быть смешанной, в т.ч. со студентами МИЭМ и других факультетов, аналогичная тема заявлена на ярмарке проектов.

Далее организуется slack и трекер (обычно trello), где ведется рабочее общение и трекинг задач.
Встречи -- по договоренности (на первых порах это понадобится точно) на Кочновском, альтернативный и более частый вариант -- аудио/видеосвязь. Удобно, т.к. можно собираться по актуальному вопросу безотлагательно и в любое время в любом составе.

=== Компоненеты (Из каких частей состоит проект?) ===
* Служба для Windows (настраивается на определеный порт для каждой подключенной камеры)

* Сетевой сервис для Linux-сервера (аналогично)

* Веб-интерфейс управления (запускается и для локальной службы, и для удаленного сервера)

* Расширенные возможности: управление реализуется в том же веб-интерфейсе.

=== Какие будут использоваться технологии? ===
* ONVIF -- управление оборудованием видеонаблюдения

* Служба для Windows и аналогичной версии для сервера под Linux.

=== Какие начальные требования? ===
Существующая версия написана на C# в VisualStudio, но это несколько странно для работы на Linux-сервере. Особых требований по языку разработки нет, исходить нужно из оценки пригодности выбранных инструментов для работы с ONVIF и названными ОС.

Для управления можно использовать веб-интерфейс, иначе придется делать приложение "в трее" для Windows.

=== Темы вводных занятий ===
Не в порядке изложения:

1. Специфические технологии и используемые инструменты.

2. Доступные ресурсы, организация доступа.

3. Разделение ролей

=== Критерии оценки ===
Про работу и оценки почитайте здесь: https://d.pr/143bq

Постарайтесь отнестись к этому с пониманием. Очень часто бодрое начало длится 3-4 недели и потом наступает тишина. Очень хочется, чтобы проекты доводились до запуска, а вы получали опыт успешной разработки и, возможно, работу в этих проектах уже в другом статусе. Но пока это для вас учебная работа, поэтому будем придерживаться описанных по ссылке правил и критериев. Спасибо!

=== Похожие проекты ===
Это небольшая сервисная программа, аналогичные встроены в VMix.
Прототип успешно работает, проект направлен на развитие.

=== Контактная информация ===
Денис Королев,

https://www.hse.ru/staff/dkorolev (там есть ссылки на соцсети)

+7 903 610 3290 (месенджеры по вкусу)

d.korolev@gmail.com

Разработка программного адаптера ONVIF устройств для видеомикшера VMix (проект)

2017-09-20T18:39:49Z

Dkorolev: Новая страница, с помощью формы Новый_проект

{{Карточка_проекта
|name=Разработка программного адаптера ONVIF устройств для видеомикшера VMix
|mentor=Королев Денис
|mentor_login={{URLENCODE:Dkorolev|WIKI}}
|semester=Осень 2017
|course=2
|summer=on
|number_of_students=5-10
|categorize=yes
}}

=== Что это за проект? ===
Небольшой проект для решения узкой, но актуальной задачи. Для монтажа многокамерной видеосъёмки и трансляции используют как аппаратные, так и программные видеомикшеры. Один из наиболее удобных и функциональных программных микшеров -- VMix, он не только поддерживает работу с различным оборудованием захвата сигнала с камер, но и прекрасно работает с RTSP-потоками от IP-камер, а значит, с ним совместимы все камеры видеонаблюдения при их низкой стоимости и гибкости настройки. В частности, из VMix можно задать несколько позиций поворота одной камеры и переходить между ними в прямом эфире, как между разными камерами (virtual input), что облегчает работу режиссера (и исключает необходимость в операторе) в прямом эфире. Но разработчики VMix ориентировались на рынок профессионального телевизионного оборудования и для управления камерами включили только проприетарные стандарты дорогих камер, в то время как системы видеонаблюдения давно используют единый открытый стандарт для всех видов используемого оборудования -- ONVIF. Задача: сделать прокси-адаптер, который будет транслировать команды VMix в команды ONVIF. Прототип такой программы уже сделан, но довести его до продукта, сделать локальную версию для Windows (как службу + интерфейс управления) и сетевую для Linux-сервера -- это ещё предстоит.

Минимальный проект: Помимо 11 команд и 2 настроек для управления PTZ, понадобится управлять Alarm-статусами камеры (так можно зажигать индикатор "камера в эфире", его называют Tally).

Расширенный проект: Настройка камер включает экспо- и цветокоррекцию, причём, не коррекцию потоков, а настройку самих камер через ONVIF. Эта задача вынесена в отдельный проект (здесь и в ярмарке проектов), но может быть реализована в рамках данного проекта.

=== Чему вы научитесь? ===
* Управление видеокамерами IP PTZ через ONVIF

* Автоматизация рутинных процедур в видеопроизводстве

* Интеграция ПО с видеомикшером VMix, оптимизация рабочего процесса

В расширенном проекте:

* Анализ видеопотоков

=== Какие начальные требования? ===
Существующая версия написана на C# в VisualStudio, но это несколько странно для работы на Linux-сервере. Особых требований по языку разработки нет, исходить нужно из оценки пригодности выбранных инструментов для работы с ONVIF и названными ОС.

Для управления можно использовать веб-интерфейс, иначе придется делать приложение "в трее" для Windows.

=== Какие будут использоваться технологии? ===
* ONVIF -- управление оборудованием видеонаблюдения

* Служба для Windows и аналогичной версии для сервера под Linux.

=== Темы вводных занятий ===
Не в порядке изложения:

1. Специфические технологии и используемые инструменты.

2. Доступные ресурсы, организация доступа.

3. Разделение ролей

=== Направления развития ===
От небольшой утилиты-адаптера (или небольшого служебного сервиса) эта программа может вырасти в полноценный продукт для IP-video продакшена. IP-камеры в последние годы стали снимать вполне качественно и могут конкурировать с классическими, при этом имея массу преимуществ по управляемости. Проект в будущем должен объединить в себя возможности управления, монитоирнга, конфигурирования этих камер (включая трекинг людей и автосъёмку вообще, автокоррекцию параметров изображения при многокамерной съёмке и т.д.).

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

=== Критерии оценки ===
Про работу и оценки почитайте здесь: https://d.pr/143bq

Постарайтесь отнестись к этому с пониманием. Очень часто бодрое начало длится 3-4 недели и потом наступает тишина. Очень хочется, чтобы проекты доводились до запуска, а вы получали опыт успешной разработки и, возможно, работу в этих проектах уже в другом статусе. Но пока это для вас учебная работа, поэтому будем придерживаться описанных по ссылке правил и критериев. Спасибо!

=== Ориентировочное расписание занятий ===
Более точное расписание будет ясно после утверждения графика факультативов, пока ориентируемся на вторник, среду или пятницу во второй половине дня (после 15-16 часов).

На самом деле, для общения (как индивидуального, так и группового) удобно использовать средства видеосвязи -- это не заменяет очных встреч, но отлично дополняет их за счет возможности оперативно решать задачи "здесь и сейчас", сидя за удобным вам рабочим местом. Практически все темы проектов подразумевают работу в сети.

Денис Королев,

https://www.hse.ru/staff/dkorolev (там есть ссылки на соцсети)

+7 903 610 3290 (месенджеры по вкусу)

d.korolev@gmail.com

Разработка модуля распознавания текста из видеоизображения (проект)

2017-09-20T18:32:11Z

Dkorolev: Новая страница, с помощью формы Новый_проект

{{Карточка_проекта
|name=Разработка модуля распознавания текста из видеоизображения
|mentor=Королев Денис
|mentor_login={{URLENCODE:Dkorolev|WIKI}}
|semester=Осень 2017
|course=2
|summer=on
|number_of_students=5-10
|categorize=yes
}}

=== Что это за проект? ===
Распознавание текста из видео/фото изображений дополняет сервис распознавания голоса из аудио и видео (как файлов, так и потоков).

Основная область применения -- мониторинг телевизионных программ различными мониторинговыми службами. Основной объект для распознавания -- бегущие строки и субтитры (lower thirds), но на деле объекты могут быть не только текстовыми (вылавливать логотипы и другие эталонные изображения и надписи, регистрировать их размер).

=== Чему вы научитесь? ===
Обработка видеопотоков, файлов и фотоизображений с целью распознавания текстов и изображений по заданным шаблонам.

=== Какие начальные требования? ===
В зависимости от роли в проекте:

* OpenCV и навыки работы с распознаванием изображений.

* Веб-разработка на Ruby on Rails

=== Какие будут использоваться технологии? ===
* Разработка на Ruby on Rails, JavaScript

* Распознавание -- OpenCV + C++/Python

* API GoogleDrive, работа с хранилищами FTP/WebDAV

=== Темы вводных занятий ===
Не в порядке изложения:

1. Архитектура проекта. API, внешние связи и зависимости.

2. Специфические технологии и используемые инструменты.

3. Доступные ресурсы, организация доступа.

4. Разделение ролей

=== Направления развития ===
Графическая часть сервиса распознавания дополняет голосовую (изначально это сервис распознавания голоса в текст), также там предусмотрено подключение перевода. Комплексная услуга позволяет покрывать значительную часть запросов, но требует и более тщательной разработки интерфейса пользователя, и сами "распознаватели" зачастую требуется дублировать и перепроверять возможными автоматическими способами, чтобы снизить уровень ошибок. Проект развивается в настоящее время в сторону комплексного сервиса, обслуживающего как запросы частных клиентов, так и интегрируемого в корпоративный рабочий процесс, в т. ч. для профильных компаний (медиаизмерители, HR, колцентры, журналисты, продакшены и тд).

=== Критерии оценки ===
Про работу и оценки почитайте здесь: https://d.pr/143bq

Постарайтесь отнестись к этому с пониманием. Очень часто бодрое начало длится 3-4 недели и потом наступает тишина. Очень хочется, чтобы проекты доводились до запуска, а вы получали опыт успешной разработки и, возможно, работу в этих проектах уже в другом статусе. Но пока это для вас учебная работа, поэтому будем придерживаться описанных по ссылке правил и критериев. Спасибо!

=== Ориентировочное расписание занятий ===
Более точное расписание будет ясно после утверждения графика факультативов, пока ориентируемся на вторник, среду или пятницу во второй половине дня (после 15-16 часов).

На самом деле, для общения (как индивидуального, так и группового) удобно использовать средства видеосвязи -- это не заменяет очных встреч, но отлично дополняет их за счет возможности оперативно решать задачи "здесь и сейчас", сидя за удобным вам рабочим местом. Практически все темы проектов подразумевают работу в сети.

Денис Королев,

https://www.hse.ru/staff/dkorolev (там есть ссылки на соцсети)

+7 903 610 3290 (месенджеры по вкусу)

d.korolev@gmail.com

Разработка модуля автоматизации видеомонтажа в прямом эфире (проект)

2017-09-20T18:25:28Z

Dkorolev: Новая страница, с помощью формы Новый_проект

{{Карточка_проекта
|name=Разработка модуля автоматизации видеомонтажа в прямом эфире
|mentor=Королев Денис
|mentor_login={{URLENCODE:Dkorolev|WIKI}}
|semester=Осень 2017
|course=2
|summer=on
|number_of_students=5-10
|categorize=yes
}}

=== Что это за проект? ===
Если вы снимаете какое-нибудь событие (конференцию, защиты выпускных работ или другое разговорное событие) на одну камеру, то запись, монтаж и трансляция особой проблемы не представляют -- просто нечего монтировать, разве что подрезать. Транслировать такое событие тоже просто. Стоит добавить к этой одной камере хотя бы захват экрана презентации, начинаются сложности. А если камер несколько, выступающий общается с залом, из президиума что-то комментируют -- здесь обычно нужен режиссер. На входе у режиссера несколько потоков, он выбирает, какой из потоков пойдет в запись/трансляцию в каждый момент времени.
Критерии выбора потока зависят от а) его содержательности и актуальности для зрителя в данный момент и б) от технической и эстетической готовности. Содержательность -- это значит, что показывают обычно либо говорящего, либо то, о чём он говорит (презентацию), либо и то и другое сразу (картинка в картинке). Техническая пригодность -- значит, камера в фокусе, не дрожит и готова передавать поток без помех. Эстетическая готовность -- камера наведена на объект съёмки с соблюдением требуемой композиции кадра и в допустимых пределах экспозиции и цветопередачи.

Переключение источников видеопотоков может быть автоматизировано и это реализовано в конференц-системах, где камеры поворачиваются на говорящего в микрофон на определенном месте. Но такие системы имеют простой алгоритм, основанный на предварительной настройке позиций камер на оснащённые места с индивидуальными микрофонами. В нашем случае нет возможности использовать дополнительные датчики и заранее настраивать камеры на определенные точки, задачу автоматизации режиссуры нужно решать для абстрактного случая "разговорного события".
Если общие правила монтажа и съёмки довольно легко описываются (например, длительность кадров в пределах 5-20 секунд, переходы по крупности плана -- через один, съёмка по правилу третей, при этом поворот головы к центру кадра, и т.д.), то выбор источников для включения и конкретных моментов для переходов -- это задача творческая и для ее решения могут привлекаться как обычные формальные методы (изменение содержания слайда, детекция говорящего человека на крупном плане и т.д.), так и нейросеть.

=== Чему вы научитесь? ===
* Распознавание движений и мимики человека

* Практика в OpenCV

* Составление формальных критериев для съёмки и монтажа

* Амбициозная задача -- лишить режиссеров работы, где это возможно! Пусть кино снимают, а здесь и машина управится.

=== Какие начальные требования? ===
* Программирование C++ или Python, желательно OpenCV

=== Какие будут использоваться технологии? ===
* Распознавание образов (OpenCV)

* Возможно: нейросети

=== Темы вводных занятий ===
1. Архитектура проекта. API, внешние связи и зависимости.

2. Специфические технологии и используемые инструменты.

3. Доступные ресурсы, организация доступа.

4. Разделение ролей

=== Направления развития ===
Автомонтаж -- это даже не технология, а мечта одних и ужас других (кому потом придется искать себе работу). По сути, большинство "режиссеров" днями напролет выполняют работу, с которой компьютер справится не хуже, а зачастую -- лучше. Никакого творчества в съёмке разговорных мероприятий обычно нет (речь не о топовых проектах крупных телеканалов, а о всевозможных конференциях, семинарах и тд -- их по количеству часов снимается подавляющее большинство). Развитие проекта востребовано в двух очевидных направлениях, в которых ныне существует классический монтаж:

* Линейный автомонтаж -- вместо линейного монтажа, это прямые эфиры и записи "телевизионным" способом (такой же прямой эфир, только в запись, потом можно подкорректировать).

* Нелинейный автомонтаж -- вместо обычного нелинейного мотнажа. Элементы такой автоматики уже кое-где встречаются, достаточно вспомнить, какие ролики время от времени подкидывает вам Facebook и Google+. Здесь полагаться приходится имеющийся материал, не всегда есть сведения о его синхронизации (многокамерную съёмку можно синхронизировать по звуку и по движениям в кадре), но для нелинейного монтажа обычно важнее сделать ролик с самым важным из имеющегося материала, а не собрать хронологически выстроенные записи и переключать планы, как в многокамерной телевизионной съёмке. Здесь есть время подумать, но и задачи более творческие.

Одной технологией пользоваться невозможно, поэтому важно "завернуть" алгоритмы в продукт. И здесь есть хороший шанс выйти на благодатную почву, т.к. этот (как и многие соседние в этом списке предлагаемых проектов) проект разрабатывается для уже действующего и постоянно развивающегося сервиса интернет-трансляций.

=== Критерии оценки ===
Про работу и оценки почитайте здесь: https://d.pr/143bq

Постарайтесь отнестись к этому с пониманием. Очень часто бодрое начало длится 3-4 недели и потом наступает тишина. Очень хочется, чтобы проекты доводились до запуска, а вы получали опыт успешной разработки и, возможно, работу в этих проектах уже в другом статусе. Но пока это для вас учебная работа, поэтому будем придерживаться описанных по ссылке правил и критериев. Спасибо!

=== Ориентировочное расписание занятий ===
Более точное расписание будет ясно после утверждения графика факультативов, пока ориентируемся на вторник, среду или пятницу во второй половине дня (после 15-16 часов).

На самом деле, для общения (как индивидуального, так и группового) удобно использовать средства видеосвязи -- это не заменяет очных встреч, но отлично дополняет их за счет возможности оперативно решать задачи "здесь и сейчас", сидя за удобным вам рабочим местом. Практически все темы проектов подразумевают работу в сети.

Денис Королев,

https://www.hse.ru/staff/dkorolev (там есть ссылки на соцсети)

+7 903 610 3290 (месенджеры по вкусу)

d.korolev@gmail.com

Разработка модулей ретрансляции видеопотоков на стриминговые платформы (проект)

2017-09-20T18:10:58Z

Dkorolev: Новая страница, с помощью формы Новый_проект

{{Карточка_проекта
|name=Разработка модулей ретрансляции видеопотоков на стриминговые платформы
|mentor=Королев Денис
|mentor_login={{URLENCODE:Dkorolev|WIKI}}
|semester=Осень 2017
|course=2
|summer=on
|number_of_students=5-10
|categorize=yes
}}

=== Что это за проект? ===
Потоковое вещание с 2016 года поддерживается практически всеми соцсетями, это модная тема и эффективное средство продвижения контента. Есть различные сервисы и приложения (как от самих сетей, так и сторонние), обеспечивающие вещание как в отдельные сети, так и в несколько одновременно. Для одного из таких сервисов (On-Air.Pro) требуется разработка связки с API соцсетей и сетей доставки контента. Это отдельные фрагменты кода, они должны пройти соответствующие тесты, далее они включаются в основной проект. Список сетей и конкретные задачи определяются на момент согласования темы, т.к. проект живой и развивается безотносительно участия студентов. В качестве примера можно привести Youtube streaming API -- новая версия вышла весной 2017 года, потребуется реализовать новые возможности.

Разработка на Ruby on Rails.

=== Чему вы научитесь? ===
Потоковое вещание с 2016 года поддерживается практически всеми соцсетями, это модная тема и эффективное средство продвижения контента. Есть различные сервисы и приложения (как от самих сетей, так и сторонние), обеспечивающие вещание как в отдельные сети, так и в несколько одновременно. Для одного из таких сервисов (On-Air.Pro) требуется разработка связки с API соцсетей и сетей доставки контента. Это отдельные фрагменты кода, они должны пройти соответствующие тесты, далее они включаются в основной проект.
Список сетей и конкретные задачи определяются на момент согласования темы, т.к. проект живой и развивается безотносительно участия студентов.
В качестве примера можно привести Youtube streaming API -- новая версия вышла весной 2017 года, потребуется реализовать новые возможности.

Разработка на Ruby on Rails.

=== Какие начальные требования? ===
Навыки программирования под веб (если вы планируете изучить Ruby on Rails по ходу работы, то ещё и способность быстро обучаться).

=== Какие будут использоваться технологии? ===
* REST API сторонних сервисов,

* Ruby on Rails,

* Разработка по тестам

=== Темы вводных занятий ===
Не в порядке изложения:

1. Архитектура проекта. API, внешние связи и зависимости.

2. Специфические технологии и используемые инструменты.

3. Доступные ресурсы, организация доступа.

4. Разделение ролей

=== Направления развития ===
Модули для интеграции с внешними сетями -- часть большого проекта, одной из ключевых возможностей которого является стриминг соцсети и планируется более плотное взаимодействие с ними. Здесь важнейшую роль играет интеграция через API и решение задач, возникающих при этом, а возможно, и, порой, обход ограничений (парсингом страниц, например).

На ярмарке проектов данная тема явно не выделена, но входит в этот проект: https://pf.hse.ru/208012056.html.

=== Критерии оценки ===
Про работу и оценки почитайте здесь: https://d.pr/143bq

Постарайтесь отнестись к этому с пониманием. Очень часто бодрое начало длится 3-4 недели и потом наступает тишина. Очень хочется, чтобы проекты доводились до запуска, а вы получали опыт успешной разработки и, возможно, работу в этих проектах уже в другом статусе. Но пока это для вас учебная работа, поэтому будем придерживаться описанных по ссылке правил и критериев. Спасибо!

=== Ориентировочное расписание занятий ===
Более точное расписание будет ясно после утверждения графика факультативов, пока ориентируемся на вторник, среду или пятницу во второй половине дня (после 15-16 часов).

На самом деле, для общения (как индивидуального, так и группового) удобно использовать средства видеосвязи -- это не заменяет очных встреч, но отлично дополняет их за счет возможности оперативно решать задачи "здесь и сейчас", сидя за удобным вам рабочим местом. Практически все темы проектов подразумевают работу в сети.

Денис Королев,

https://www.hse.ru/staff/dkorolev (там есть ссылки на соцсети)

+7 903 610 3290 (месенджеры по вкусу)

d.korolev@gmail.com

Разработка мобильного приложения "ONVIF камера" (проект)

2017-09-20T14:54:35Z

Dkorolev: Новая страница, с помощью формы Новый_проект

{{Карточка_проекта
|name=Разработка мобильного приложения "ONVIF камера"
|mentor=Королев Денис
|mentor_login={{URLENCODE:Dkorolev|WIKI}}
|semester=Осень 2017
|course=2
|summer=on
|number_of_students=5-10
|categorize=yes
}}

=== Что это за проект? ===
Любопытная особенность камер видеонаблюдения, которую призвано имитировать разрабатываемое приложение, -- это то, что они полностью контролируются дистанционно по стандартному протоколу. Если вы когда-нибудь снимали на обычные бытовые камеры, то знаете, что к чему их ни подключи, а настроить параметры изображения можно только с самой камеры, запустить запись -- тоже. И только в телевизионных комплексах оператор камеру направляет, а остальное настраивается со специального пульта, и это позволяет при съёмке с нескольких камер получать одинаковые параметры изображения (по цвету, свету, параметрам сигнала). Мобильный телефон уже давно стал устройством для стриминга, но стриминга "сырого" видео и обычно сразу к зрителю. От этого любительские трансляции в ВК и Фейсбуке выглядят хуже, чем любительское VHS в 90х: ни монтажа, ни смены планов.

Существует множество мобильных приложений для видеостриминга, но требуется специфическая разработка, которая превратит для внешнего наблюдателя обычный смартфон или планшет в камеру видеонаблюдения с присущими ей возможностями: поддержкой стандарта ONVIF (управление потоками, параметрами изображения и тд), формированием как минимум двух потоков RTSP со звуком AAC, веб-интерфейсом управления.

Таким образом, любой совместимый смартфон или планшет станет полноценным источником видеопотока для потокового микшера (например, VMix. Или для того, что разрабатывается в одном из соседних проектов). При использовании VPN можно использовать потоки от устройств, находящихся в любой точке мира, подключенной к интернет.

=== Чему вы научитесь? ===
* Разработка мобильного приложения (если ещё нет такого опыта). По умолчанию -- Android, если есть желающие работать под IOS, это тоже хорошо, проекты могут идти параллельно.

* Работа с камерой мобильного устройства для формирования RTSP потоков.

* Разработка ONVIF-совместимого ПО (используется всей инфраструктурой систем видеонаблюдения).

=== Какие начальные требования? ===
Навыки или желание освоить разработку мобильных приложений.

=== Какие будут использоваться технологии? ===
* JAVA (для Android)

* ONVIF

* RTSP сервер

* OpenVPN (опционально)

* Web-сервер для создания простого веб-интерфейса (опционально)

=== Темы вводных занятий ===
Не в порядке изложения:

1. Архитектура проекта. ONVIF, внешние связи и зависимости.

2. Специфические технологии и используемые инструменты.

3. Доступные ресурсы, организация доступа.

4. Разделение ролей

=== Направления развития ===
Существует программный видеомикшер VMix и он поддерживает проприетарный и относительно молодой протокол NDI, через который по сети можно легко передавать потоки с компьютера и даже с мобильника. Но они используют потоки в десятки мегабит/с и совместимых устройств (камер, например) единицы и цены на них -- "телевизионные". В нашем случае строится связка из мобильного приложения, микшера, сервиса стриминга в соцсети и CDN, при этом, рассчитанная на работу с доступными каналами связи (1-8 вместо 40 мбит/с). Проект имеет смысл и развитие и безотносительно самодельных микшеров, т.к. RTSP-камера может использоваться в программных микшерах (в том же Vmix).

=== Критерии оценки ===
Про работу и оценки почитайте здесь: https://d.pr/143bq

Постарайтесь отнестись к этому с пониманием. Очень часто бодрое начало длится 3-4 недели и потом наступает тишина. Очень хочется, чтобы проекты доводились до запуска, а вы получали опыт успешной разработки и, возможно, работу в этих проектах уже в другом статусе. Но пока это для вас учебная работа, поэтому будем придерживаться описанных по ссылке правил и критериев. Спасибо!

=== Ориентировочное расписание занятий ===
Более точное расписание будет ясно после утверждения графика факультативов, пока ориентируемся на вторник, среду или пятницу во второй половине дня (после 15-16 часов).

На самом деле, для общения (как индивидуального, так и группового) удобно использовать средства видеосвязи -- это не заменяет очных встреч, но отлично дополняет их за счет возможности оперативно решать задачи "здесь и сейчас", сидя за удобным вам рабочим местом. Практически все темы проектов подразумевают работу в сети.

Денис Королев,

https://www.hse.ru/staff/dkorolev (там есть ссылки на соцсети)

+7 903 610 3290 (месенджеры по вкусу)

d.korolev@gmail.com

Разработка микшера видеопотоков RTSP/RTMP (проект)

2017-09-20T14:38:01Z

Dkorolev: Новая страница, с помощью формы Новый_проект

{{Карточка_проекта
|name=Разработка микшера видеопотоков RTSP/RTMP
|mentor=Королев Денис
|mentor_login={{URLENCODE:Dkorolev|WIKI}}
|semester=Осень 2017
|course=2
|summer=on
|number_of_students=5-10
|categorize=yes
}}

=== Что это за проект? ===
Все, наверное, видели, как в телевизионной аппаратной режиссер эфира сидит за пультом,смотрит в стену с мониторами и жмет кнопки. И рядом сидят его коллеги и тоже что-то напряженно делают. Прямой эфир -- это всегда напряжение и ответственность, для его проведения требуются опыт и квалификация. А ещё -- дорогостоящее оборудование и провода до камер (или спутниковые каналы связи). Так было и так есть сейчас. Наша задача -- перенести возможности профессионального телевидения в реальность, где нет таких бюджетов, зато есть доступная цифровая техника, интернет и уже существуют все необходимые компоненты, чтобы сделать телевизионную аппаратную в облаке, а управлять ею с обычного компьютера. Тогда вы уже не привязаны к месту съёмки, перед вами мощности всех датацентров мира за очень разумные деньги, вы решаете задачи, для которых классическому телевидению пришлось бы задействовать массу дорогостоящих ресурсов.

Ключом к успеху здесь является быстрая доставка видеопотоков через интернет (а не сигналов по проводам)от камер к "микшеру" и оттуда -- к режиссеру. Задержки всё портят. Другое отличие -- камеры мы будем использовать тоже необычные. Точнее, самые обычные,но не телевизионные и не бытовые, а камеры видеонаблюдения.

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

Проект групповой, движок видеомикшера есть, техника и специально под эти задачи построенная VPN тоже есть. Потребуется его интеграция в рабочий процесс на удаленном сервере, real-time отображение потоков режиссеру, создание отзывчивого фронтенда.

=== Чему вы научитесь? ===
Любопытно, но прямых аналогов нет. Движки, причем, функционально богатые, есть, а в явном виде облачный микшер видеопотоков не предлагают. Есть шанс сделать "скайп" для многокамерной съёмки/трансляции. Кто не помнит, скайп в своё время сделал видеосвязь обыденным делом, до него требовалось много приготовлений.
Работа связана с движком на базе gstreamer -- само по себе познавательное дело, т.к. применимость gstreamer'а не ограничивается сведением потоков.
Помимо этого, здесь предстоит столкнуться с двумя проявлениями отзывчивости: минимизацией задержки видеопотоков (сам по себе RTSP передается почти мгновенно, но как его показать без задержки?) и созданием отзывчивого пользовательского интерфейса. Разумеется, первые версии могут быть аскетичными по возможностям, но отзывчивость будет важна.
В зависимости от комплектации группы, будет разрабатываться больше или меньше возможностей. Например, полезный в этой области навык -- управление камерами (ONVIF). Есть смежные проекты, где эта тема получает развитие в трекинг человека или, коррекцию параметров изображения, в имитацию работы оператора (плавные движения, правильная композиция кадра).

=== Какие начальные требования? ===
В любом случае понадобятся навыки программирования (будь то веб-разработка или работа с движком GStreamer/Snowmix), работы с Linux (потому что виртуалка в сети). Остальное -- специфика, с которой можно познакомиться по ходу проекта. Веб-часть на Ruby on Rails -- для унификации с базовым проектом.

Ожидается, что разработчики умеют пользоваться поисковыми системами и stackoverflow. Руководитель может консультировать вас по предметной области (видео/тв), но не по программной разработке.

Разработка обычно имеет недельный цикл трекинга, встречи (как индивидуальные, так и групповые) по умолчанию -- по видеосвязи, но порой надо и очно (на факультете). Необходимые технические и серверные ресурсы предоставляются.

=== Какие будут использоваться технологии? ===
* Gstreamer и с ним Snowmix/Voctomix, возможно -- ffmpeg

* Виртуальные машины linux, nginx и сопутствующие инструменты

* Быстрая доставка потоков режиссеру -- возможно, WebRTC, но это не догма.

* Ruby on Rails (для унификации) и необходимые средства для UI (например, meteor, это ещё нужно обоснованно решить).

* Опционально: ONVIF для управления камерами (переход по предустановленным позициям)

=== Темы вводных занятий ===
Не в порядке изложения:

1. Архитектура проекта. API, внешние связи и зависимости.

2. Специфические технологии и используемые инструменты.

3. Доступные ресурсы, организация доступа.

4. Разделение ролей

=== Направления развития ===
Как микшер -- ядро телестудии, так и потоковый микшер связывает несколько разработок в мощный набор инструментов для организации полного цикла производства медиаконтента практически без капитальных вложений (не нужна закупка дорогостоящего оборудования, используется сервисная модель и облачные серверы).
Сам видеомикшер имеет два основных пути развития: как движок для непритязательных (выполняет монтажные функции, но не имеет выраженного "микшерного" интерфейсы, и как полноценный видеомикшер со всеми инструментами профессионального назначения. Этот проект может развиваться долго и стать стандартом де-факто для режиссеров потоковых эфиров. В такого рода проектах есть богатое поле для автоматизации и интеллектуализации рабочих процессов, есть множество рутинных процедур, которые могут быть сняты с человека, вплоть до разработки "автопилота" эфира (про это есть отдельный проект).

=== Критерии оценки ===
Про работу и оценки почитайте здесь: https://d.pr/143bq

Постарайтесь отнестись к этому с пониманием. Очень часто бодрое начало длится 3-4 недели и потом наступает тишина. Очень хочется, чтобы проекты доводились до запуска, а вы получали опыт успешной разработки и, возможно, работу в этих проектах уже в другом статусе. Но пока это для вас учебная работа, поэтому будем придерживаться описанных по ссылке правил и критериев. Спасибо!

=== Ориентировочное расписание занятий ===
Более точное расписание будет ясно после утверждения графика факультативов, пока ориентируемся на вторник, среду или пятницу во второй половине дня (после 15-16 часов).

На самом деле, для общения (как индивидуального, так и группового) удобно использовать средства видеосвязи -- это не заменяет очных встреч, но отлично дополняет их за счет возможности оперативно решать задачи "здесь и сейчас", сидя за удобным вам рабочим местом. Практически все темы проектов подразумевают работу в сети.

Денис Королев,

https://www.hse.ru/staff/dkorolev (там есть ссылки на соцсети)

+7 903 610 3290 (месенджеры по вкусу)

d.korolev@gmail.com

Разработка матрицы видеопотоков (проект)

2017-09-20T14:23:57Z

Dkorolev: Новая страница, с помощью формы Новый_проект

{{Карточка_проекта
|name=Разработка матрицы видеопотоков
|mentor=Королев Денис
|mentor_login={{URLENCODE:Dkorolev|WIKI}}
|semester=Осень 2017
|course=2
|summer=on
|number_of_students=5-10
|categorize=yes
}}

=== Что это за проект? ===
Матрица -- это узел, куда в телевизионном центре сходятся все сигналы и оттуда распределяются по потребителям. Технически это коробка с N входами и M выходами. И каждый выход m может быть сопоставлен входу n, при этом, на один вход может быть скоммутировано сколько угодно выходов. Ко входам подключаются камеры, выходы пультов, спутниковые приёмники с сигналами от выездных студий и внешних источников, а выходы подаются на пульты, рекордеры и эфирные кодеры. В нашем случае коммутироваться будут не сигналы в проводах, а потоки в сети. Представьте здания Вышки, в каждом по несколько оборудованных видеокамерами залов. В итоге по сети мы получаем множество потоков, но одновременно нужны далеко не все. И для режиссера эфира удобно иметь перед глазами только нужные камеры. Микшер подключен, например, к выходам 1-8 матрицы, а эти выходы коммутируются на нужные входы. Выходы матрицы также могут отдавать потоки на телевизионные панели в зданиях, сетевые рекордеры (такая тема тоже есть по соседству) и т.д.

Этот проект в минимальном виде за час собирается "на коленке" -- связка из двух VLC образует цепочку "переключатель/выход", где на переключателе указывается адрес входного потока, а выходной поток формируется вторым vlc (он является сервером RTSP. Количество таких пар определяет количество выходов, а входы -- это любые адреса потоков. Важно, что если к одной камере напрямую подключится много зрителей, то она не справится -- она является сервером, но не предназначена для массового доступа. Матрица выполняет роль прокси.

Технически это сервис на виртуальной машине. Он не должен перекодировать видео, только пересылать его. Зато матрице позволительно делать подрыв при переключении (это как при переключении каналов на телевизоре -- на время звук и картинка пропадают, потом появляется новый канал). Внешне это веб-интерфейс, представляющий собой минимально админ-панель, где вводятся адреса и имена источников и выходов, а в полной версии -- есть предпросмотр для всех входов и выходов. Сервис должен быть многопользовательским с возможностью делегировать доступ, группировать каналы и т.д.

=== Чему вы научитесь? ===
1. Работа с linux-серверами.

2. Поближе познакомитесь с сетями. Unicast/Multicast, TCP/UDP -- все это станет роднее и понятнее. VPN, куда же без него.

3. Манипуляции с медиапотоками в сети. Придется разобраться в RTSP серверах (в простейшем случае это многим знакомый VLC)

4. Разработка пользовательского интерфейса (личный кабинет с настройками, групповой доступ, отображение предпросмотра с минимизацией трафика) -- здесь достаточно ruby on rails (для совместимости поддержки с соседними проектами) и верстки bootstrap.

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

=== Какие начальные требования? ===
* Навыки программирования (рельсы можно изучить. После Python вы не будете очень страдать).

* Ожидается, что разработчики умеют пользоваться поисковыми системами и stackoverflow. Руководитель может консультировать вас по предметной области (видео/тв), но не по программной разработке.

* Разработка обычно имеет недельный цикл трекинга, встречи (как индивидуальные, так и групповые) по умолчанию -- по видеосвязи, но порой надо и очно (на факультете). Необходимые технические и серверные ресурсы предоставляются.

Специфику предметной области (видеопотоки, устройства и тд) у вас будет возможность изучить по ходу проекта.

=== Какие будут использоваться технологии? ===
* RTSP потоки и RTSP сервер -- протокол передачи видео в реальном времени, широко используется в системах IPTV и видеонаблюдения. В быту RTSP сервер легко сделать из VLC, но есть и другие варианты (FFSERVER, Live555 и т.д.).

* ONVIF -- стандарт управления для систем видеонаблюдения. Очень пригодится для обнаружения источников в сети и адресов потоков в этих источниках. Также, полезно сделать управление матрицей совместимым со стандартами управления прочим видеооборудованием.

* REST API -- не технология, но очевидно, что программное взаимодействие с матрицей будет необходимо, в частности, для автоматизации вещания (расписание -- это уже тема отдельного проекта)

* OAuth -- общее требование по аутентификации пользователей. Встречается повсеместно, освоить всегда полезно.

* Ruby on Rails -- веб-разработка крайне желательная на этой связке.

* FFMPEG/GStreamer -- на случай необходимости все-таки обработать поток. Например, чтобы сгенерировать превью или сделать транскодирование в RTSP или в нужный формат (если такое указано для данного канала).

=== Темы вводных занятий ===
Не в порядке изложения:

1. Архитектура проекта. API, внешние связи и зависимости.

2. Специфические технологии и используемые инструменты.

3. Доступные ресурсы, организация доступа.

4. Разделение ролей

=== Направления развития ===
Матрица -- вполне самодостаточный продукт для определенной инфраструктуры. Обычно медиа-производства в таком технологическом ключе не мыслят, но в совокупности с другими проектами (потоковый видеомикшер, съёмочный комплекс на IP-потоках, автотрекинг человека PTZ камерами и т.д.) образуется полноценная инфраструктура, позволяющая решать масштабные задачи, причём, изначально -- распределенно.

=== Критерии оценки ===
Про работу и оценки почитайте здесь: https://d.pr/143bq

Постарайтесь отнестись к этому с пониманием. Очень часто бодрое начало длится 3-4 недели и потом наступает тишина. Очень хочется, чтобы проекты доводились до запуска, а вы получали опыт успешной разработки и, возможно, работу в этих проектах уже в другом статусе. Но пока это для вас учебная работа, поэтому будем придерживаться описанных по ссылке правил и критериев. Спасибо!

=== Ориентировочное расписание занятий ===
Более точное расписание будет ясно после утверждения графика факультативов, пока ориентируемся на вторник, среду или пятницу во второй половине дня (после 15-16 часов).

На самом деле, для общения (как индивидуального, так и группового) удобно использовать средства видеосвязи -- это не заменяет очных встреч, но отлично дополняет их за счет возможности оперативно решать задачи "здесь и сейчас", сидя за удобным вам рабочим местом. Практически все темы проектов подразумевают работу в сети.

Денис Королев,

https://www.hse.ru/staff/dkorolev (там есть ссылки на соцсети)

+7 903 610 3290 (месенджеры по вкусу)

d.korolev@gmail.com

Разработка динамической сети доставки потокового видеоконтента (проект)

2017-09-20T14:10:00Z

Dkorolev: Новая страница, с помощью формы Новый_проект

{{Карточка_проекта
|name=Разработка динамической сети доставки потокового видеоконтента
|mentor=Королев Денис
|mentor_login={{URLENCODE:Dkorolev|WIKI}}
|semester=Осень 2017
|course=2
|summer=on
|number_of_students=5-10
|categorize=yes
}}

=== Что это за проект? ===
Видеотрансляции в интернет стали совсем обычным делом с тех пор, как ими вплотную занялись Youtube и, позже, соцсети. До них раздача видеопотоков зрителям решалась или своими силами, или через сети доставки контента (CDN). Суть задачи в том, что, в отличие от телевидения, которое посылает один сигнал всем, а смотрят его те, кто хотят, в интернет работает только метод передачи данных от точки к точке (unicast), что для сервера трансляций оборачивается необходимостью каждому зрителю индивидуально отправить поток. Тот же самый, что другому зрителю, в то же время, но отправить персонально. В итоге нагрузка на канал связи растет пропорционально аудитории трансляции. И задерживать такой поток нельзя.

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

Для эффективной работы CDN требуется диагностика и мониторинг каналов связи на серверах, ресурсов самих серверов -- это отдельная подтема в проекте.

Вторая часть проекта -- это frontend. Если при трансляции через Youtube зритель видит плеер Youtube, то при трансляции через собственный CDN зрителю надо показать какой-то свой плеер. А может быть и не только плеер. Есть множество "фич", которые становится возможным реализовать, если вести раздачу потоков через свои ресурсы: обратная связь, учет зрительской активности, взимание платы за трансляции, учет географии и других данных о пользователе, многопоточный звук для трансляции многоязычных конференций, субтитры (у нас есть распознавание голоса в текст). Можно организовать чат, голосования и даже принимать от зрителей видеопотоки, звук и файлы через WebRTC. Разумеется, здесь задачи будут выбираться исходя из состава и готовности проектной группы.

=== Чему вы научитесь? ===
Проект в первую очередь -- сетевой, в чистом виде -- облачный. Это разработка распределенной системы, динамически меняющейся в зависимости от нагрузки. Более того, практика показывает, что нельзя привязываться к одному провайдеру услуг: там тоже бывают перебои. В результате разработки CDN должна иметь REST API и хотя бы минимальную админ-панель, для зрителей должен предлагаться плеер (как минимум -- HLS) и страница для просмотра.

=== Какие начальные требования? ===
CDN -- это серверная разработка под Linux. Язык жестко не регламентирован, попытки что-то сделать уже предпринимались на Java. Веб-разработка -- основной проект написан на Ruby on Rails, желательно не вносить разнообразие языков, но это не блокирующее требование. Плеер -- если беретесь за плеер, то хорошо бы иметь хоть какой-то опыт общения с ними. Задача может оказаться сложнее, чем кажется на первый взгляд.

=== Какие будут использоваться технологии? ===
Облачные серверы запускаются с использованием API соответствующего провайдера. Некоторые провайдеры используют OpenStack, но это (на практике) не решает проблем унификации работы. Сетевой мониторинг -- само по себе важное направление в инфраструктуре ИТ. Конкретные инструменты предстоит выбрать. Плеер и фронтенд -- есть смелая идея раздавать поток через WebRTC (а это пиринговая технология, то есть, на стороне серверов будет о чем подумать), через него же собирать обратную связь. Но это отдельная часть проекта, для смелых веб-разработчиков, причем, ее можно реализовывать независимо от успехов в CDN (можем запустить в действующем проекте). Однозначно можно сказать, что Flash использовать нельзя, но при этом доставить на все платформы поток в едином виде можно лишь http-based протоколами (HLS, например), а у них есть свои недостатки -- большая задержка, от которой теряется смысл в обратной связи реального времени. Поэтому нужно предусматривать запасные протоколы: WebRTC - RTMP - HLS. Это в порядке увеличения задержки.

=== Темы вводных занятий ===
Не в порядке изложения:

1. Архитектура проекта. API, внешние связи и зависимости.

2. Специфические технологии и используемые инструменты.

3. Доступные ресурсы, организация доступа.

4. Разделение ролей

=== Направления развития ===
CDN для трансляций можно рассматривать как модуль для сервиса видеовещания, а можно и как самостоятельную платформу, работающую поверх облачных хостингов виртуальных машин. Но вывести такой продукт в самостоятельный статус, обеспечить необходимые функционал и стабильность -- это задача для настойчивых.

=== Критерии оценки ===
Про работу и оценки почитайте здесь: https://d.pr/143bq Обратите внимание, что проект составной и то, какие части пойдут в работу, мы поймём, когда сформируется состав рабочей группы. То есть, отсутствие в итоге какой-то из частей, не блокирующей работу (например, WebRTC не запустили, но HLS плеер есть -- его поставить недолго) никак не снижает оценки проделанной работы по тем частям проекта, которые выполнены. Участники проекта имеют свою область ответственности и оценки получают в соответствии с успехами в этих областях.

Постарайтесь отнестись к этому с пониманием. Очень часто бодрое начало длится 3-4 недели и потом наступает тишина. Очень хочется, чтобы проекты доводились до запуска, а вы получали опыт успешной разработки и, возможно, работу в этих проектах уже в другом статусе. Но пока это для вас учебная работа, поэтому будем придерживаться описанных по ссылке правил и критериев. Спасибо!

=== Ориентировочное расписание занятий ===
Более точное расписание будет ясно после утверждения графика факультативов, пока ориентируемся на вторник, среду или пятницу во второй половине дня (после 15-16 часов).

На самом деле, для общения (как индивидуального, так и группового) удобно использовать средства видеосвязи -- это не заменяет очных встреч, но отлично дополняет их за счет возможности оперативно решать задачи "здесь и сейчас", сидя за удобным вам рабочим местом. Практически все темы проектов подразумевают работу в сети.

Денис Королев,

https://www.hse.ru/staff/dkorolev (там есть ссылки на соцсети)

+7 903 610 3290 (месенджеры по вкусу)

d.korolev@gmail.com

Разработка динамической сети доставки потокового видеоконтента. (командный проект)

2017-09-20T14:01:07Z

Dkorolev:

{{Карточка_командного_проекта
|name=Разработка динамической сети доставки потокового видеоконтента
|company=On-Air.Pro
|semester=Осень 2017
|course=3
|number_of_students=4-6
|categorize=yes
}}

=== Что это за проект? ===
Видеотрансляции в интернет стали совсем обычным делом с тех пор, как ими вплотную занялись Youtube и, позже, соцсети. До них раздача видеопотоков зрителям решалась или своими силами, или через сети доставки контента (CDN). Суть задачи в том, что, в отличие от телевидения, которое посылает один сигнал всем, а смотрят его те, кто хотят, в интернет работает только метод передачи данных от точки к точке (unicast), что для сервера трансляций оборачивается необходимостью каждому зрителю индивидуально отправить поток. Тот же самый, что другому зрителю, в то же время, но отправить персонально. В итоге нагрузка на канал связи растет пропорционально аудитории трансляции. И задерживать такой поток нельзя.

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

Для эффективной работы CDN требуется диагностика и мониторинг каналов связи на серверах, ресурсов самих серверов -- это отдельная подтема в проекте.

Вторая часть проекта -- это frontend. Если при трансляции через Youtube зритель видит плеер Youtube, то при трансляции через собственный CDN зрителю надо показать какой-то свой плеер. А может быть и не только плеер. Есть множество "фич", которые становится возможным реализовать, если вести раздачу потоков через свои ресурсы: обратная связь, учет зрительской активности, взимание платы за трансляции, учет географии и других данных о пользователе, многопоточный звук для трансляции многоязычных конференций, субтитры (у нас есть распознавание голоса в текст). Можно организовать чат, голосования и даже принимать от зрителей видеопотоки, звук и файлы через WebRTC. Разумеется, здесь задачи будут выбираться исходя из состава и готовности проектной группы.

=== Чему научатся студенты? Что самое интересное в проекте? ===
Проект в первую очередь -- сетевой, в чистом виде -- облачный. Это разработка распределенной системы, динамически меняющейся в зависимости от нагрузки. Более того, практика показывает, что нельзя привязываться к одному провайдеру услуг: там тоже бывают перебои.
В результате разработки CDN должна иметь REST API и хотя бы минимальную админ-панель, для зрителей должен предлагаться плеер (как минимум -- HLS) и страница для просмотра.

=== Организация работы (Как студенты будут работать в команде?) ===
Роли и точный состав работ формируется по итогам регистрации желающих участвовать (команда может быть смешанной, в т.ч. со студентами МИЭМ и других факультетов, аналогичная тема заявлена на ярмарке проектов.

Далее организуется slack и трекер (обычно trello), где ведется рабочее общение и трекинг задач.
Встречи -- по договоренности (на первых порах это понадобится точно) на Кочновском, альтернативный и более частый вариант -- аудио/видеосвязь. Удобно, т.к. можно собираться по актуальному вопросу безотлагательно и в любое время в любом составе.

=== Компоненеты (Из каких частей состоит проект?) ===
1. Работа с API хостинг-провайдеров.

2. Балансировщик

3. REST API для сервиса трансляций.

4. Плеер и фронтенд (для зрителя, для админа)

5. WebRTC обвеска (в дополнение к предыдущему пункту)

=== Какие будут использоваться технологии? ===
Облачные серверы запускаются с использованием API соответствующего провайдера. Некоторые провайдеры используют OpenStack, но это (на практике) не решает проблем унификации работы.
Сетевой мониторинг -- само по себе важное направление в инфраструктуре ИТ. Конкретные инструменты предстоит выбрать.
Плеер и фронтенд -- есть смелая идея раздавать поток через WebRTC (а это пиринговая технология, то есть, на стороне серверов будет о чем подумать), через него же собирать обратную связь. Но это отдельная часть проекта, для смелых веб-разработчиков, причем, ее можно реализовывать независимо от успехов в CDN (можем запустить в действующем проекте).
Однозначно можно сказать, что Flash использовать нельзя, но при этом доставить на все платформы поток в едином виде можно лишь http-based протоколами (HLS, например), а у них есть свои недостатки -- большая задержка, от которой теряется смысл в обратной связи реального времени. Поэтому нужно предусматривать запасные протоколы: WebRTC - RTMP - HLS. Это в порядке увеличения задержки.

=== Какие начальные требования? ===
CDN -- это серверная разработка под Linux. Язык жестко не регламентирован, попытки что-то сделать уже предпринимались на Java.
Веб-разработка -- основной проект написан на Ruby on Rails, желательно не вносить разнообразие языков, но это не блокирующее требование.
Плеер -- если беретесь за плеер, то хорошо бы иметь хоть какой-то опыт общения с ними. Задача может оказаться сложнее, чем кажется на первый взгляд.

=== Темы вводных занятий ===
Не в порядке изложения:

1. Архитектура проекта. API, внешние связи и зависимости.

2. Специфические технологии и используемые инструменты.

3. Доступные ресурсы, организация доступа.

4. Разделение ролей

=== Критерии оценки ===
Про работу и оценки почитайте здесь: https://d.pr/143bq
Обратите внимание, что проект составной и то, какие части пойдут в работу, мы поймём, когда сформируется состав рабочей группы. То есть, отсутствие в итоге какой-то из частей, не блокирующей работу (например, WebRTC не запустили, но HLS плеер есть -- его поставить недолго) никак не снижает оценки проделанной работы по тем частям проекта, которые выполнены. Участники проекта имеют свою область ответственности и оценки получают в соответствии с успехами в этих областях.

Постарайтесь отнестись к этому с пониманием. Очень часто бодрое начало длится 3-4 недели и потом наступает тишина. Очень хочется, чтобы проекты доводились до запуска, а вы получали опыт успешной разработки и, возможно, работу в этих проектах уже в другом статусе. Но пока это для вас учебная работа, поэтому будем придерживаться описанных по ссылке правил и критериев. Спасибо!

=== Похожие проекты ===
CDNVideo, NGenix -- российские CDN, классические, на физических серверах. Akamai и т.д. -- зарубежные, их много. Но они решают больше задач: DVR -- запись с timeshift, раздача статического контента (про это есть отдельный проект среди предложенных здесь, и он базируется на бесконечных GoogleDrive)

FaceCast -- интересная организация, скоро запускают новую версию своей платформы с API. Но у них нет задачи работы в реальном времени, чат там тоже внешний и не сохраняется, и вообще они предлагают полный цикл от отправки сигнала с камер, а не только доставку потоков. CDN они тоже сделали на своих серверах, хотя и использовали подход Google -- много дешевых машин, распределенное хранение, резервирование.

По использованию WebRTC: appear.in -- видеочат. Но чат связывает участников одного уровня между собой, причем, всех со всеми, а тут задача другая -- на противоположной стороне от зрителя будет сервер.

=== Контактная информация ===
Денис Королев,

https://www.hse.ru/staff/dkorolev (там есть ссылки на соцсети)

+7 903 610 3290 (месенджеры по вкусу)

d.korolev@gmail.com

Разработка динамической сети доставки потокового видеоконтента. (командный проект)

2017-09-20T13:59:38Z

Dkorolev:

{{Карточка_командного_проекта
|name=Разработка динамической сети доставки потокового видеоконтента
|company=On-Air.Pro
|semester=Осень 2017
|course=3
|number_of_students=5-10
|categorize=yes
}}

=== Что это за проект? ===
Видеотрансляции в интернет стали совсем обычным делом с тех пор, как ими вплотную занялись Youtube и, позже, соцсети. До них раздача видеопотоков зрителям решалась или своими силами, или через сети доставки контента (CDN). Суть задачи в том, что, в отличие от телевидения, которое посылает один сигнал всем, а смотрят его те, кто хотят, в интернет работает только метод передачи данных от точки к точке (unicast), что для сервера трансляций оборачивается необходимостью каждому зрителю индивидуально отправить поток. Тот же самый, что другому зрителю, в то же время, но отправить персонально. В итоге нагрузка на канал связи растет пропорционально аудитории трансляции. И задерживать такой поток нельзя.

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

Для эффективной работы CDN требуется диагностика и мониторинг каналов связи на серверах, ресурсов самих серверов -- это отдельная подтема в проекте.

Вторая часть проекта -- это frontend. Если при трансляции через Youtube зритель видит плеер Youtube, то при трансляции через собственный CDN зрителю надо показать какой-то свой плеер. А может быть и не только плеер. Есть множество "фич", которые становится возможным реализовать, если вести раздачу потоков через свои ресурсы: обратная связь, учет зрительской активности, взимание платы за трансляции, учет географии и других данных о пользователе, многопоточный звук для трансляции многоязычных конференций, субтитры (у нас есть распознавание голоса в текст). Можно организовать чат, голосования и даже принимать от зрителей видеопотоки, звук и файлы через WebRTC. Разумеется, здесь задачи будут выбираться исходя из состава и готовности проектной группы.

=== Чему научатся студенты? Что самое интересное в проекте? ===
Проект в первую очередь -- сетевой, в чистом виде -- облачный. Это разработка распределенной системы, динамически меняющейся в зависимости от нагрузки. Более того, практика показывает, что нельзя привязываться к одному провайдеру услуг: там тоже бывают перебои.
В результате разработки CDN должна иметь REST API и хотя бы минимальную админ-панель, для зрителей должен предлагаться плеер (как минимум -- HLS) и страница для просмотра.

=== Организация работы (Как студенты будут работать в команде?) ===
Роли и точный состав работ формируется по итогам регистрации желающих участвовать (команда может быть смешанной, в т.ч. со студентами МИЭМ и других факультетов, аналогичная тема заявлена на ярмарке проектов.

Далее организуется slack и трекер (обычно trello), где ведется рабочее общение и трекинг задач.
Встречи -- по договоренности (на первых порах это понадобится точно) на Кочновском, альтернативный и более частый вариант -- аудио/видеосвязь. Удобно, т.к. можно собираться по актуальному вопросу безотлагательно и в любое время в любом составе.

=== Компоненеты (Из каких частей состоит проект?) ===
1. Работа с API хостинг-провайдеров.

2. Балансировщик

3. REST API для сервиса трансляций.

4. Плеер и фронтенд (для зрителя, для админа)

5. WebRTC обвеска (в дополнение к предыдущему пункту)

=== Какие будут использоваться технологии? ===
Облачные серверы запускаются с использованием API соответствующего провайдера. Некоторые провайдеры используют OpenStack, но это (на практике) не решает проблем унификации работы.
Сетевой мониторинг -- само по себе важное направление в инфраструктуре ИТ. Конкретные инструменты предстоит выбрать.
Плеер и фронтенд -- есть смелая идея раздавать поток через WebRTC (а это пиринговая технология, то есть, на стороне серверов будет о чем подумать), через него же собирать обратную связь. Но это отдельная часть проекта, для смелых веб-разработчиков, причем, ее можно реализовывать независимо от успехов в CDN (можем запустить в действующем проекте).
Однозначно можно сказать, что Flash использовать нельзя, но при этом доставить на все платформы поток в едином виде можно лишь http-based протоколами (HLS, например), а у них есть свои недостатки -- большая задержка, от которой теряется смысл в обратной связи реального времени. Поэтому нужно предусматривать запасные протоколы: WebRTC - RTMP - HLS. Это в порядке увеличения задержки.

=== Какие начальные требования? ===
CDN -- это серверная разработка под Linux. Язык жестко не регламентирован, попытки что-то сделать уже предпринимались на Java.
Веб-разработка -- основной проект написан на Ruby on Rails, желательно не вносить разнообразие языков, но это не блокирующее требование.
Плеер -- если беретесь за плеер, то хорошо бы иметь хоть какой-то опыт общения с ними. Задача может оказаться сложнее, чем кажется на первый взгляд.

=== Темы вводных занятий ===
Не в порядке изложения:

1. Архитектура проекта. API, внешние связи и зависимости.

2. Специфические технологии и используемые инструменты.

3. Доступные ресурсы, организация доступа.

4. Разделение ролей

=== Критерии оценки ===
Про работу и оценки почитайте здесь: https://d.pr/143bq
Обратите внимание, что проект составной и то, какие части пойдут в работу, мы поймём, когда сформируется состав рабочей группы. То есть, отсутствие в итоге какой-то из частей, не блокирующей работу (например, WebRTC не запустили, но HLS плеер есть -- его поставить недолго) никак не снижает оценки проделанной работы по тем частям проекта, которые выполнены. Участники проекта имеют свою область ответственности и оценки получают в соответствии с успехами в этих областях.

Постарайтесь отнестись к этому с пониманием. Очень часто бодрое начало длится 3-4 недели и потом наступает тишина. Очень хочется, чтобы проекты доводились до запуска, а вы получали опыт успешной разработки и, возможно, работу в этих проектах уже в другом статусе. Но пока это для вас учебная работа, поэтому будем придерживаться описанных по ссылке правил и критериев. Спасибо!

=== Похожие проекты ===
CDNVideo, NGenix -- российские CDN, классические, на физических серверах. Akamai и т.д. -- зарубежные, их много. Но они решают больше задач: DVR -- запись с timeshift, раздача статического контента (про это есть отдельный проект среди предложенных здесь, и он базируется на бесконечных GoogleDrive)

FaceCast -- интересная организация, скоро запускают новую версию своей платформы с API. Но у них нет задачи работы в реальном времени, чат там тоже внешний и не сохраняется, и вообще они предлагают полный цикл от отправки сигнала с камер, а не только доставку потоков. CDN они тоже сделали на своих серверах, хотя и использовали подход Google -- много дешевых машин, распределенное хранение, резервирование.

По использованию WebRTC: appear.in -- видеочат. Но чат связывает участников одного уровня между собой, причем, всех со всеми, а тут задача другая -- на противоположной стороне от зрителя будет сервер.

=== Контактная информация ===
Денис Королев,

https://www.hse.ru/staff/dkorolev (там есть ссылки на соцсети)

+7 903 610 3290 (месенджеры по вкусу)

d.korolev@gmail.com

Разработка веб-сервиса файлового менеджера для GoogleDrive (проект)

2017-09-20T13:57:21Z

Dkorolev: Новая страница, с помощью формы Новый_проект

{{Карточка_проекта
|name=Разработка веб-сервиса файлового менеджера для GoogleDrive
|mentor=Королев Денис
|mentor_login={{URLENCODE:Dkorolev|WIKI}}
|semester=Осень 2017
|course=2
|summer=on
|number_of_students=5-10
|categorize=yes
}}

=== Что это за проект? ===
Не все знают, но у корпоративных и академических аккаунтов Google безлимитные хранилища в GoogleDrive. При этом, скорость обмена с сервером достаточная, чтобы хранить там медиаархивы. Это радикально меняет подход к хранению данных видеопроизводств, к видеорегистрации и многим другим "тяжеловесным" задачам. Проект нацелен на создание медиаархива на базе хранилища GoogleDrive. От стандартной веб-оболочки медиаархив отличают две важные особенности:

1. Представление данных в том виде, в каком это удобно для выборки, шаринга, выгрузки и т.д

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

В данном проекте решается первая задача (вторая решается в соседнем проекте). Для этого уже написан веб-интерфейс файлового менеджера (MeteorJS, используется MongoDB). По сути, требуется доработка проекта.

При этом, важные требования: через серверы проекта медиа-трафик не проходит. То есть, загружается только метаинформация. Про метаданные файлов есть важное замечание: данных может быть довольно много, они даже могут быть относительно объёмными. Поэтому хранить их в полях метаданных, предоставляемых GoogleDrive не получится (кроме базовых сведений о файле -- это можно). Также, следует экономно относиться к запросам к серверу, т.к. на них есть ограничение для публичного сервиса оно вполне достижимое.

=== Чему вы научитесь? ===
* Разработка веб-приложения с отзывчивым интерфейсом

* Глубокое взаимодействие с API GoogleDrive

На выходе открытый продукт -- альтернативный файловый менеджер для GoogleDrive, размещённый в ChromeMarket.

=== Какие начальные требования? ===
* Навыки веб-разработки или желание её изучить.

=== Какие будут использоваться технологии? ===
* Meteor / MongoDB
* GoogleDrive API

=== Темы вводных занятий ===
Не в порядке изложения:

1. Архитектура проекта. API, внешние связи и зависимости.

2. Специфические технологии и используемые инструменты.

3. Доступные ресурсы, организация доступа.

4. Разделение ролей

=== Направления развития ===
Файлменеджер для GoogleDrive -- это "витрина" большого проекта, включающего анализатор файлов на облачном диске пользователя, сервис по продаже безлимитных аккаунтов, сервис персонализации контента (вотермаркинг) и даже CDN (сеть доставки контента, в данном случае -- статического, например, для часто запрашиваемых медиаматериалов).

=== Критерии оценки ===
Про работу и оценки почитайте здесь: https://d.pr/143bq

Постарайтесь отнестись к этому с пониманием. Очень часто бодрое начало длится 3-4 недели и потом наступает тишина. Очень хочется, чтобы проекты доводились до запуска, а вы получали опыт успешной разработки и, возможно, работу в этих проектах уже в другом статусе. Но пока это для вас учебная работа, поэтому будем придерживаться описанных по ссылке правил и критериев. Спасибо!

=== Ориентировочное расписание занятий ===
Более точное расписание будет ясно после утверждения графика факультативов, пока ориентируемся на вторник, среду или пятницу во второй половине дня (после 15-16 часов).

На самом деле, для общения (как индивидуального, так и группового) удобно использовать средства видеосвязи -- это не заменяет очных встреч, но отлично дополняет их за счет возможности оперативно решать задачи "здесь и сейчас", сидя за удобным вам рабочим местом. Практически все темы проектов подразумевают работу в сети.

Денис Королев,

https://www.hse.ru/staff/dkorolev (там есть ссылки на соцсети)

+7 903 610 3290 (месенджеры по вкусу)

d.korolev@gmail.com

Автоматическая экспо- и цветокоррекция при съёмке IP камерами (проект)

2017-09-20T08:40:15Z

Dkorolev:

{{Карточка_проекта
|name=Автоматическая экспо- и цветокоррекция при съёмке IP камерами
|mentor=Королев Денис
|mentor_login={{URLENCODE:Dkorolev|WIKI}}
|semester=Осень 2017
|course=2
|summer=on
|number_of_students=5-10
|categorize=yes
}}

=== Что это за проект? ===
Когда вы снимаете фото или видео, ваша камера автоматически подстраивается под условия освещения. Когда у нее это не получается, цвета в изображении искажаются (желтые фотографии в домашнем свете, синие в сумерках и т.д.). Это несложно настроить вручную, но теперь представим, что одновременно работает несколько камер. Здесь задача усложнаяется: нужно, чтобы цветопередача и экспозиция на всех камерах была одинаковой.

Здесь нам пригодится опыт телевизионных съёмочных комплексов. На телевидении оператор не занимается настройкой параметров изображения и прочими техническими подробностями, его задача -- направить камеру. Даже фокус за него могут поправить его коллеги. Все параметры экспозиции и цветопередачи настраивают на специальном пульте.

Если взять обычные камеры видеонаблюдения, то они тоже настраиваются дистанционно и у нас есть возможность менять все нужные параметры, посылая на камеры соответствующие команды.

Задача этого проекта -- сделать программу для корректировки параметров камер как вручную, так и в полностью автоматическом режиме. Регулируемые параметры:

1. Цветопередача (Cb/Cr) 2. Экспозиция (яркость, контрастность)

Дополнительные возможности: 1. Мониторинг фокуса

Программа должна иметь пользовательский интерфейс для ручной настройки и переключения режимов (отключения автоматики). Программа предназначена для работы как на пользовательском компьютере (Windows), так и на сервере Linux на виртуальной машине с доступом к камерам через VPN. Адрес получения потока и адрес управления камерой могут отличаться (при работе через матрицу потоков или иной прокси-сервер).

Аналогичный проект на Ярмарке проектов ВШЭ: https://pf.hse.ru/208027466.html

=== Чему вы научитесь? ===
* Управление камерами через ONVIF, включая автодетекцию камер в сети.
* Анализ визуальных характеристик изображений

=== Какие начальные требования? ===
Владеть программированием, желательно иметь опыт общения с OpenCV.

=== Какие будут использоваться технологии? ===
* ONVIF

* OpenCV

* RTSP/MJPEG

=== Темы вводных занятий ===
Не в порядке изложения:

1. Архитектура проекта. API, внешние связи и зависимости.

2. Специфические технологии и используемые инструменты.

3. Доступные ресурсы, организация доступа.

4. Разделение ролей

=== Направления развития ===
Предлагаемые темы не являются чисто учебными, все они -- из рабочей практики и имеют выход в коммерческие сервисы, дополняя уже имеющийся функционал. Общая практика работы "на развитие" -- преуспевший в разработке некоего проекта студент (если хочет) становится "хостом" проекта и ведет его развитие дальше уже находясь в договорных отношениях с компанией.

Тема является частью более общего проекта по созданию съёмочного комплекса -- как с ручным управлением, так и с разной степенью автоматизации; как локального, так и полностью распределенного. Одно из внедрений такого комплекса начинается на ФКН для записи и трансляции значимых событий.

=== Критерии оценки ===
Про работу и оценки почитайте здесь: https://d.pr/143bq

Постарайтесь отнестись к этому с пониманием. Очень часто бодрое начало длится 3-4 недели и потом наступает тишина. Очень хочется, чтобы проекты доводились до запуска, а вы получали опыт успешной разработки и, возможно, работу в этих проектах уже в другом статусе. Но пока это для вас учебная работа, поэтому будем придерживаться описанных по ссылке правил и критериев. Спасибо!

=== Ориентировочное расписание занятий ===
Более точное расписание будет ясно после утверждения графика факультативов, пока ориентируемся на вторник, среду или пятницу во второй половине дня (после 15-16 часов).

На самом деле, для общения (как индивидуального, так и группового) удобно использовать средства видеосвязи -- это не заменяет очных встреч, но отлично дополняет их за счет возможности оперативно решать задачи "здесь и сейчас", сидя за удобным вам рабочим местом. Практически все темы проектов подразумевают работу в сети.

Денис Королев,

https://www.hse.ru/staff/dkorolev (там есть ссылки на соцсети)

+7 903 610 3290 (месенджеры по вкусу)

d.korolev@gmail.com

Интеграция WebRTC в сервис потокового вещания для отображения потоков в реальном времени (проект)

2017-09-20T08:39:59Z

Dkorolev:

{{Карточка_проекта
|name=Интеграция WebRTC в сервис потокового вещания для отображения потоков в реальном времени
|mentor=Королев Денис
|mentor_login={{URLENCODE:Dkorolev|WIKI}}
|semester=Осень 2017
|course=2
|summer=on
|number_of_students=5
|categorize=yes
}}

=== Что это за проект? ===
Небольшая и совершенно конкретная тема, входящая в несколько соседних проектов в качестве подпроекта: есть задачи, в которых требуется получать видео из потока RAW/RTSP в реальном времени (или близком к реальному). Когда речь идёт о видеосистемах, там есть протоколы, которые с этим справляются (RTP, RTSP), но браузеры не умеют показывать RTP/RTSP. Зато некоторые браузеры (этого достаточно) умеют показывать WebRTC. В этой задаче нет новизны, она ориентирована на внедрение конкретного технического решения и отладку шероховатостей, возникающих в реальной жизни с реальными потоками.

=== Чему вы научитесь? ===
* Работа с видеопотоками в сети, доставка видео в реальном времени

=== Какие начальные требования? ===
* Навыки веб-программирования, желательно Ruby on Rails (для прототипа можно использовать любой язык).

=== Какие будут использоваться технологии? ===
* WebRTC (сервер Kurento или другой -- на выбор исполнителя)
* Ruby on Rails
* JavaScript

=== Темы вводных занятий ===
Не в порядке изложения:

1. Архитектура проекта. внешние связи и зависимости.

2. Специфические технологии и используемые инструменты.

3. Доступные ресурсы, организация доступа.

4. Разделение ролей

=== Направления развития ===
Предлагаемые темы не являются чисто учебными, все они -- из рабочей практики и имеют выход в коммерческие сервисы, дополняя уже имеющийся функционал. Общая практика работы "на развитие" -- преуспевший в разработке некоего проекта студент (если хочет) становится "хостом" проекта и ведет его развитие дальше уже находясь в договорных отношениях с компанией.

Это проект одной технологии, причём, применяться она может в обе стороны: как для доставки видеопотоков зрителю, так и для получения от него потока с камеры и с рабочего стола. Может применяться и для передачи файлов. Всё это имеет применение в видеотрансляциях, даже массовых. В настоящее время включение в эфир "звонка зрителя" выполняется или отдельным сервисом (Skype, например), или средствами программного видеомикшера ("звонящий" переходит по ссылке, рабочий стол показать при этом нельзя). Реализация полноценной обратной связи -- это полноценный проект, построенный на той же технологии WebRTC со связкой с потоковым микшером. Это важный элемент для создания видеокомплекса в облаке, действующего в реальном времени (то есть, с полноценной поддержкой режиссируемого общения участников)

=== Критерии оценки ===
Про работу и оценки почитайте здесь: https://d.pr/143bq

Постарайтесь отнестись к этому с пониманием. Очень часто бодрое начало длится 3-4 недели и потом наступает тишина. Очень хочется, чтобы проекты доводились до запуска, а вы получали опыт успешной разработки и, возможно, работу в этих проектах уже в другом статусе. Но пока это для вас учебная работа, поэтому будем придерживаться описанных по ссылке правил и критериев. Спасибо!

=== Ориентировочное расписание занятий ===
Более точное расписание будет ясно после утверждения графика факультативов, пока ориентируемся на вторник, среду или пятницу во второй половине дня (после 15-16 часов).

На самом деле, для общения (как индивидуального, так и группового) удобно использовать средства видеосвязи -- это не заменяет очных встреч, но отлично дополняет их за счет возможности оперативно решать задачи "здесь и сейчас", сидя за удобным вам рабочим местом. Практически все темы проектов подразумевают работу в сети.

Денис Королев,

https://www.hse.ru/staff/dkorolev (там есть ссылки на соцсети)

+7 903 610 3290 (месенджеры по вкусу)

d.korolev@gmail.com

Разработка анализатора файлов, хранимых в GoogleDrive (проект)

2017-09-20T08:39:38Z

Dkorolev:

{{Карточка_проекта
|name=Разработка анализатора файлов, хранимых в GoogleDrive
|mentor=Королев Денис
|mentor_login={{URLENCODE:Dkorolev|WIKI}}
|semester=Осень 2017
|course=2
|summer=on
|number_of_students=5-10
|categorize=yes
}}

=== Что это за проект? ===
В соседнем проекте предлагается разработка файлового менеджера для медиаархивов, расположенных в GoogleDrive (корпоративные и академические аккаунты имеют безлимитные хранилища, что при хорошей скорости доступа позволяет включать их в работу там, где раньше использовались серверы хранения).

Рабочий процесс при работе с медиаархивом на диске Google выглядит следующим образом:

1. Для обмена данными с GoogleDrive используются альтернативные приложения, например, WebDrive, позволяющий подключать облачный аккаунт как логический диск в Windows/Mac.

2. Файлы отображаются в виртуальной файловой системе WebDrive и в веб-интерфейсе GoogleDrive в иерархическом виде, доступны все стандартные действия.

3. Веб-файлменеджер медиаархива показывает ту же структуру файлов, но может формировать другие представления, основываясь на критериях отбора, делать смарт-папки, витрины и давать задания на обработку (например, персонализированную маркировку файлов для отправки клиенту, чтобы было не повадно класть их на видном месте). И здесь возникает первая проблема недостатка метаинформации: про файлы мы в лучшем случае знаем дату их изменения, и то -- не всегда. Если файл загружался через браузер или стандартным приложением Google, то на GoogleDrive запишется дата загрузки. Более детальной информации о многих файлах получить не удастся: если для фотографий доступны данные EXIF (метаданные, которые записывают фотокамеры и фоторедакторы), то про видео известна самая малость: длина, размер кадра, формат. Даже размер файла точно неизвестен. Правда, про все файлы мы можем узнать MD5 -- это пригодится для поиска дубликатов. Недостающие данные можно было бы легко получить на стороне пользователя (про видеофайлы нам всё расскажет FFPROBE, про даты, пути, пользователя и т.д. -- файловая и операционная система через стандартные вызовы. Но у пользователя мы ничего не запускаем (хотя и можем ему предложить утилиту для отправки этой информации, которую потом будем считывать в базу уже с GoogleDrive) и выгружать на свой сервер терабайты ради этого было бы жаль, если не проводить более глубоких исследований файлов. Какие это могут быть исследования?

Если на жестком диске лежат два вроде бы одинаковых файла, то мы можем:

1. Сравнить их контрольные суммы, размеры и названия. Названия мало что значат, размеры тоже могут совпадать, MD5 совпадает редко. Но всё это бесполезно, если речь идет о об исходном файле и его сжатой копии.

2. Здесь придется сравнивать содержимое. Например, вычесть изображения и посмотреть, что осталось в разнице. Если видео -- аналогично вычитать кадры (можно не все, хотя есть риск пропустить разницу). Надо ещё не забыть про звук и звуковые дорожки -- разница может быть в них. Всё это -- ресурсоёмкие операции, требующие наличия доступа к обоим сравниваемым файлам.

3. А если файлы большие, их очень много и расположены на удаленном сервере? В таком случае придётся строить индекс и сравнивать не сами файлы, а описания файлов. Назовём их сигнатурами. Простой вариант -- построить гистаграммы (это 3 набора из 256 значений) для каждого кадра видео. Оригинал это или сжатая копия -- распределение яркостей по цветовым каналам должно быть примерно одинаковым. Можно попробовать более изощрённые методы, и даже в этом результирующие значения можно записать более экономно, чем 256 уровней *3 канала *2 байта * количество кадров. В любом случае, операции с данными раскладываются на два этапа: а) сбор метаданных, включая сигнатуры, какими бы они ни были, б) сравнение сигнатур.

Поскольку разрабатываемый сервис является сторонним и для Google и для пользовательского рабочего места приложением, запущен на виртуальных машинах в облаке, то для выполнения этих задач ему понадобится

* выгрузить последовательно все файлы с указанного пользовательского аккаунта к себе и провести все необходимые операции для анализа.
* отправить собранные метаданные в базу данных файлового менеджера.

Предстоит определить список операций и характеристик файлов, для которых составляются сигнатуры. Например, поиск дубликатов (включае нечеткие), определение частей целого (сопоставление файлов, содержащих исходную запись и нарезки из неё), поиск материалов по их характеристикам (динамичное видео, темные фотографии, ..... Кстати, здесь могут быть актуальны и запросы "размытые фотографии", "портреты" и тд).

=== Чему вы научитесь? ===
В зависимости от роли:

* Анализировать фото, видео, аудио контент с целью составления метаописаний, по которым можно сравнивать эти материалы между собой и с новыми файлами, а также определять определенные их характеристики.

* Работать с GoogleDrive API

* Создавать веб-сервисы с REST API

* Организовывать очередь запросов и распределение задач по воркерам на виртуальных машинах с (это опционально) запуском этих машин по мере надобности (через API провайдера).

=== Какие начальные требования? ===
В зависимости от роли в проекте:

1. Программирование веб-сервисров: опыт или желание освоить.

2. Анализ изображений. Хотя бы представление о том, как и чем это делается.

3. Linux и bash, чтобы не удивляться при работе с виртуалками.

=== Какие будут использоваться технологии? ===
* GoogleDrive API, OAuth.

* Анализ изображений, видео, звука. От FFPROBE/ImageMagick до OpenCV и далее -- на сколько хватит фантазии.

* Работа с виртуальными серверами на хостинг-провайдерах (API)

Веб-интерфейс в таком сервисе не является необходимой частью, но может использоваться для демонстрации возможностей. Основное взаимодействие с внешним миром -- REST API.

=== Темы вводных занятий ===
Не в порядке изложения:

1. Архитектура проекта. API, внешние связи и зависимости.

2. Специфические технологии и используемые инструменты.

3. Доступные ресурсы, организация доступа.

4. Разделение ролей

=== Направления развития ===
Этот проект довольно узкоспецифический, но по сути анализ медиаматериалов -- это то, чем занимаются поисковые системы, которые в выдаче картинок предлагают в настройках разные опции (в определенной цветовой гамме и тд). Они идут дальше и всерьез применяют распознавание и ML. Нам это тоже не повредит, но это следующий этап после запуска базовых возможностей. Ничто не мешает его начать делать уже сейчас.

Близкий проект на Ярмарке проектов ВШЭ: https://pf.hse.ru/208039048.html

=== Критерии оценки ===
Про работу и оценки почитайте здесь: https://d.pr/143bq

Постарайтесь отнестись к этому с пониманием. Очень часто бодрое начало длится 3-4 недели и потом наступает тишина. Очень хочется, чтобы проекты доводились до запуска, а вы получали опыт успешной разработки и, возможно, работу в этих проектах уже в другом статусе. Но пока это для вас учебная работа, поэтому будем придерживаться описанных по ссылке правил и критериев. Спасибо!

=== Ориентировочное расписание занятий ===
Более точное расписание будет ясно после утверждения графика факультативов, пока ориентируемся на вторник, среду или пятницу во второй половине дня (после 15-16 часов).

На самом деле, для общения (как индивидуального, так и группового) удобно использовать средства видеосвязи -- это не заменяет очных встреч, но отлично дополняет их за счет возможности оперативно решать задачи "здесь и сейчас", сидя за удобным вам рабочим местом. Практически все темы проектов подразумевают работу в сети.

Денис Королев,

https://www.hse.ru/staff/dkorolev (там есть ссылки на соцсети)

+7 903 610 3290 (месенджеры по вкусу)

d.korolev@gmail.com

Разработка веб-сервиса нелинейного видеоредактора (проект)

2017-09-20T08:39:14Z

Dkorolev: Новая страница, с помощью формы Новый_проект

{{Карточка_проекта
|name=Разработка веб-сервиса нелинейного видеоредактора
|mentor=
|mentor_login={{URLENCODE:Dkorolev|WIKI}}
|semester=Осень 2017
|course=2
|summer=
|number_of_students=
|categorize=yes
}}

=== Что это за проект? ===
Существует уже много веб-сервисов и мобильных приложений для редактирования фото и видео. Как обычно, чтобы ими воспользоваться, нужно в них загрузить свои файлы. А если файлы уже лежат в облаке, при этом, важно быстро внести требуемые изменения, то это неудобно. Чаще всего требуется подрезка, наложение титров или графики, склейка фрагментов. Эти операции могут выполняться из командной строки, если знать требуемые параметры (например, при помощи ffmpeg).

Задача в этом проекте разделена на два уровня сложности:

1. Сделать простой видеоредактор для выполнения основных операций: отрезать, приклеить, наложить, преобразовать в нужный размер/формат. При этом, в качестве источника должны приниматься файлы на GoogleDrive, WebDAV и FTP. Работа с файлами должна строиться путём отбора нужных материалов из архива с дальнейшей выгрузкой их на сервер (или открытием непосредственно с GoogleDrive) с последующей записью результата по любому указанному пути или выгрузкой пользователю.

2. Построить полноценный нелинейный редактор на основе существующего движка (например [https://www.mltframework.org/features/

=== Чему вы научитесь? ===
Либо писать свой интерфейс для несложного видеоредактора (даже для несложного придется потрудиться), либо работать с фреймворком видеоредактора и тоже строить отзывчивый пользовательский интерфейс.

Взаимодействовать с облачными хранилищами, API GoogleDrive, использовать OAuth и т.д.

Строить сервисы с распределением нагрузки по виртуальным машинам.

=== Какие начальные требования? ===
* Не бояться разбираться в фреймворках и api. Хотеть довести продукт до рабочего состояния.

=== Какие будут использоваться технологии? ===
* Фреймворк NLE-редактора

* GoogleDrive API

* Собственный REST API

* Отзывчивый UI (JS-based)

=== Темы вводных занятий ===
Не в порядке изложения:

1. Архитектура проекта. API, внешние связи и зависимости.

2. Специфические технологии и используемые инструменты.

3. Доступные ресурсы, организация доступа.

4. Разделение ролей

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

=== Критерии оценки ===
Про работу и оценки почитайте здесь: https://d.pr/143bq

Постарайтесь отнестись к этому с пониманием. Очень часто бодрое начало длится 3-4 недели и потом наступает тишина. Очень хочется, чтобы проекты доводились до запуска, а вы получали опыт успешной разработки и, возможно, работу в этих проектах уже в другом статусе. Но пока это для вас учебная работа, поэтому будем придерживаться описанных по ссылке правил и критериев. Спасибо!

=== Ориентировочное расписание занятий ===
Более точное расписание будет ясно после утверждения графика факультативов, пока ориентируемся на вторник, среду или пятницу во второй половине дня (после 15-16 часов).

На самом деле, для общения (как индивидуального, так и группового) удобно использовать средства видеосвязи -- это не заменяет очных встреч, но отлично дополняет их за счет возможности оперативно решать задачи "здесь и сейчас", сидя за удобным вам рабочим местом. Практически все темы проектов подразумевают работу в сети.

Денис Королев,

https://www.hse.ru/staff/dkorolev (там есть ссылки на соцсети)

+7 903 610 3290 (месенджеры по вкусу)

d.korolev@gmail.com

Разработка анализатора файлов, хранимых в GoogleDrive (проект)

2017-09-20T08:29:43Z

Dkorolev: Новая страница, с помощью формы Новый_проект

{{Карточка_проекта
|name=Разработка анализатора файлов, хранимых в GoogleDrive
|mentor=Королев Денис
|mentor_login={{URLENCODE:Dkorolev|WIKI}}
|semester=Осень 2017
|course=2
|summer=on
|number_of_students=5-10
|categorize=yes
}}

=== Что это за проект? ===
В соседнем проекте предлагается разработка файлового менеджера для медиаархивов, расположенных в GoogleDrive (корпоративные и академические аккаунты имеют безлимитные хранилища, что при хорошей скорости доступа позволяет включать их в работу там, где раньше использовались серверы хранения).

Рабочий процесс при работе с медиаархивом на диске Google выглядит следующим образом:

1. Для обмена данными с GoogleDrive используются альтернативные приложения, например, WebDrive, позволяющий подключать облачный аккаунт как логический диск в Windows/Mac.

2. Файлы отображаются в виртуальной файловой системе WebDrive и в веб-интерфейсе GoogleDrive в иерархическом виде, доступны все стандартные действия.

3. Веб-файлменеджер медиаархива показывает ту же структуру файлов, но может формировать другие представления, основываясь на критериях отбора, делать смарт-папки, витрины и давать задания на обработку (например, персонализированную маркировку файлов для отправки клиенту, чтобы было не повадно класть их на видном месте). И здесь возникает первая проблема недостатка метаинформации: про файлы мы в лучшем случае знаем дату их изменения, и то -- не всегда. Если файл загружался через браузер или стандартным приложением Google, то на GoogleDrive запишется дата загрузки. Более детальной информации о многих файлах получить не удастся: если для фотографий доступны данные EXIF (метаданные, которые записывают фотокамеры и фоторедакторы), то про видео известна самая малость: длина, размер кадра, формат. Даже размер файла точно неизвестен. Правда, про все файлы мы можем узнать MD5 -- это пригодится для поиска дубликатов. Недостающие данные можно было бы легко получить на стороне пользователя (про видеофайлы нам всё расскажет FFPROBE, про даты, пути, пользователя и т.д. -- файловая и операционная система через стандартные вызовы. Но у пользователя мы ничего не запускаем (хотя и можем ему предложить утилиту для отправки этой информации, которую потом будем считывать в базу уже с GoogleDrive) и выгружать на свой сервер терабайты ради этого было бы жаль, если не проводить более глубоких исследований файлов. Какие это могут быть исследования?

Если на жестком диске лежат два вроде бы одинаковых файла, то мы можем:

1. Сравнить их контрольные суммы, размеры и названия. Названия мало что значат, размеры тоже могут совпадать, MD5 совпадает редко. Но всё это бесполезно, если речь идет о об исходном файле и его сжатой копии.

2. Здесь придется сравнивать содержимое. Например, вычесть изображения и посмотреть, что осталось в разнице. Если видео -- аналогично вычитать кадры (можно не все, хотя есть риск пропустить разницу). Надо ещё не забыть про звук и звуковые дорожки -- разница может быть в них. Всё это -- ресурсоёмкие операции, требующие наличия доступа к обоим сравниваемым файлам.

3. А если файлы большие, их очень много и расположены на удаленном сервере? В таком случае придётся строить индекс и сравнивать не сами файлы, а описания файлов. Назовём их сигнатурами. Простой вариант -- построить гистаграммы (это 3 набора из 256 значений) для каждого кадра видео. Оригинал это или сжатая копия -- распределение яркостей по цветовым каналам должно быть примерно одинаковым. Можно попробовать более изощрённые методы, и даже в этом результирующие значения можно записать более экономно, чем 256 уровней *3 канала *2 байта * количество кадров. В любом случае, операции с данными раскладываются на два этапа: а) сбор метаданных, включая сигнатуры, какими бы они ни были, б) сравнение сигнатур.

Поскольку разрабатываемый сервис является сторонним и для Google и для пользовательского рабочего места приложением, запущен на виртуальных машинах в облаке, то для выполнения этих задач ему понадобится

* выгрузить последовательно все файлы с указанного пользовательского аккаунта к себе и провести все необходимые операции для анализа.
* отправить собранные метаданные в базу данных файлового менеджера.

Предстоит определить список операций и характеристик файлов, для которых составляются сигнатуры. Например, поиск дубликатов (включае нечеткие), определение частей целого (сопоставление файлов, содержащих исходную запись и нарезки из неё), поиск материалов по их характеристикам (динамичное видео, темные фотографии, ..... Кстати, здесь могут быть актуальны и запросы "размытые фотографии", "портреты" и тд).

=== Чему вы научитесь? ===
В зависимости от роли:

* Анализировать фото, видео, аудио контент с целью составления метаописаний, по которым можно сравнивать эти материалы между собой и с новыми файлами, а также определять определенные их характеристики.

* Работать с GoogleDrive API

* Создавать веб-сервисы с REST API

* Организовывать очередь запросов и распределение задач по воркерам на виртуальных машинах с (это опционально) запуском этих машин по мере надобности (через API провайдера).

=== Какие начальные требования? ===
В зависимости от роли в проекте:

1. Программирование веб-сервисров: опыт или желание освоить.

2. Анализ изображений. Хотя бы представление о том, как и чем это делается.

3. Linux и bash, чтобы не удивляться при работе с виртуалками.

=== Какие будут использоваться технологии? ===
* GoogleDrive API, OAuth.

* Анализ изображений, видео, звука. От FFPROBE/ImageMagick до OpenCV и далее -- на сколько хватит фантазии.

* Работа с виртуальными серверами на хостинг-провайдерах (API)

Веб-интерфейс в таком сервисе не является необходимой частью, но может использоваться для демонстрации возможностей. Основное взаимодействие с внешним миром -- REST API.

=== Темы вводных занятий ===
Не в порядке изложения:

1. Архитектура проекта. API, внешние связи и зависимости.

2. Специфические технологии и используемые инструменты.

3. Доступные ресурсы, организация доступа.

4. Разделение ролей

=== Направления развития ===
Этот проект довольно узкоспецифический, но по сути анализ медиаматериалов -- это то, чем занимаются поисковые системы, которые в выдаче картинок предлагают в настройках разные опции (в определенной цветовой гамме и тд). Они идут дальше и всерьез применяют распознавание и ML. Нам это тоже не повредит, но это следующий этап после запуска базовых возможностей. Ничто не мешает его начать делать уже сейчас.

Близкий проект на Ярмарке проектов ВШЭ: https://pf.hse.ru/208039048.html

=== Критерии оценки ===
Про работу и оценки почитайте здесь: https://d.pr/143bq

Постарайтесь отнестись к этому с пониманием. Очень часто бодрое начало длится 3-4 недели и потом наступает тишина. Очень хочется, чтобы проекты доводились до запуска, а вы получали опыт успешной разработки и, возможно, работу в этих проектах уже в другом статусе. Но пока это для вас учебная работа, поэтому будем придерживаться описанных по ссылке правил и критериев. Спасибо!

=== Ориентировочное расписание занятий ===
Более точное расписание будет ясно после утверждения графика факультативов, пока ориентируемся на вторник, среду или пятницу во второй половине дня (после 15-16 часов).

На самом деле, для общения (как индивидуального, так и группового) удобно использовать средства видеосвязи -- это не заменяет очных встреч, но отлично дополняет их за счет возможности оперативно решать задачи "здесь и сейчас", сидя за удобным вам рабочим местом. Практически все темы проектов подразумевают работу в сети.

Интеграция WebRTC в сервис потокового вещания для отображения потоков в реальном времени (проект)

2017-09-20T08:22:58Z

Dkorolev: Новая страница, с помощью формы Новый_проект

{{Карточка_проекта
|name=Интеграция WebRTC в сервис потокового вещания для отображения потоков в реальном времени
|mentor=Королев Денис
|mentor_login={{URLENCODE:Dkorolev|WIKI}}
|semester=Осень 2017
|course=2
|summer=on
|number_of_students=5
|categorize=yes
}}

=== Что это за проект? ===
Небольшая и совершенно конкретная тема, входящая в несколько соседних проектов в качестве подпроекта: есть задачи, в которых требуется получать видео из потока RAW/RTSP в реальном времени (или близком к реальному). Когда речь идёт о видеосистемах, там есть протоколы, которые с этим справляются (RTP, RTSP), но браузеры не умеют показывать RTP/RTSP. Зато некоторые браузеры (этого достаточно) умеют показывать WebRTC. В этой задаче нет новизны, она ориентирована на внедрение конкретного технического решения и отладку шероховатостей, возникающих в реальной жизни с реальными потоками.

=== Чему вы научитесь? ===
* Работа с видеопотоками в сети, доставка видео в реальном времени

=== Какие начальные требования? ===
* Навыки веб-программирования, желательно Ruby on Rails (для прототипа можно использовать любой язык).

=== Какие будут использоваться технологии? ===
* WebRTC (сервер Kurento или другой -- на выбор исполнителя)
* Ruby on Rails
* JavaScript

=== Темы вводных занятий ===
Не в порядке изложения:

1. Архитектура проекта. внешние связи и зависимости.

2. Специфические технологии и используемые инструменты.

3. Доступные ресурсы, организация доступа.

4. Разделение ролей

=== Направления развития ===
Предлагаемые темы не являются чисто учебными, все они -- из рабочей практики и имеют выход в коммерческие сервисы, дополняя уже имеющийся функционал. Общая практика работы "на развитие" -- преуспевший в разработке некоего проекта студент (если хочет) становится "хостом" проекта и ведет его развитие дальше уже находясь в договорных отношениях с компанией.

Это проект одной технологии, причём, применяться она может в обе стороны: как для доставки видеопотоков зрителю, так и для получения от него потока с камеры и с рабочего стола. Может применяться и для передачи файлов. Всё это имеет применение в видеотрансляциях, даже массовых. В настоящее время включение в эфир "звонка зрителя" выполняется или отдельным сервисом (Skype, например), или средствами программного видеомикшера ("звонящий" переходит по ссылке, рабочий стол показать при этом нельзя). Реализация полноценной обратной связи -- это полноценный проект, построенный на той же технологии WebRTC со связкой с потоковым микшером. Это важный элемент для создания видеокомплекса в облаке, действующего в реальном времени (то есть, с полноценной поддержкой режиссируемого общения участников)

=== Критерии оценки ===
Про работу и оценки почитайте здесь: https://d.pr/143bq

Постарайтесь отнестись к этому с пониманием. Очень часто бодрое начало длится 3-4 недели и потом наступает тишина. Очень хочется, чтобы проекты доводились до запуска, а вы получали опыт успешной разработки и, возможно, работу в этих проектах уже в другом статусе. Но пока это для вас учебная работа, поэтому будем придерживаться описанных по ссылке правил и критериев. Спасибо!

=== Ориентировочное расписание занятий ===
Более точное расписание будет ясно после утверждения графика факультативов, пока ориентируемся на вторник, среду или пятницу во второй половине дня (после 15-16 часов).

На самом деле, для общения (как индивидуального, так и группового) удобно использовать средства видеосвязи -- это не заменяет очных встреч, но отлично дополняет их за счет возможности оперативно решать задачи "здесь и сейчас", сидя за удобным вам рабочим местом. Практически все темы проектов подразумевают работу в сети.

Автоматическая экспо- и цветокоррекция при съёмке IP камерами (проект)

2017-09-20T08:14:10Z

Dkorolev: Новая страница, с помощью формы Новый_проект

{{Карточка_проекта
|name=Автоматическая экспо- и цветокоррекция при съёмке IP камерами
|mentor=Королев Денис
|mentor_login={{URLENCODE:Dkorolev|WIKI}}
|semester=Осень 2017
|course=2
|summer=on
|number_of_students=5-10
|categorize=yes
}}

=== Что это за проект? ===
Когда вы снимаете фото или видео, ваша камера автоматически подстраивается под условия освещения. Когда у нее это не получается, цвета в изображении искажаются (желтые фотографии в домашнем свете, синие в сумерках и т.д.). Это несложно настроить вручную, но теперь представим, что одновременно работает несколько камер. Здесь задача усложнаяется: нужно, чтобы цветопередача и экспозиция на всех камерах была одинаковой.

Здесь нам пригодится опыт телевизионных съёмочных комплексов. На телевидении оператор не занимается настройкой параметров изображения и прочими техническими подробностями, его задача -- направить камеру. Даже фокус за него могут поправить его коллеги. Все параметры экспозиции и цветопередачи настраивают на специальном пульте.

Если взять обычные камеры видеонаблюдения, то они тоже настраиваются дистанционно и у нас есть возможность менять все нужные параметры, посылая на камеры соответствующие команды.

Задача этого проекта -- сделать программу для корректировки параметров камер как вручную, так и в полностью автоматическом режиме. Регулируемые параметры:

1. Цветопередача (Cb/Cr) 2. Экспозиция (яркость, контрастность)

Дополнительные возможности: 1. Мониторинг фокуса

Программа должна иметь пользовательский интерфейс для ручной настройки и переключения режимов (отключения автоматики). Программа предназначена для работы как на пользовательском компьютере (Windows), так и на сервере Linux на виртуальной машине с доступом к камерам через VPN. Адрес получения потока и адрес управления камерой могут отличаться (при работе через матрицу потоков или иной прокси-сервер).

Аналогичный проект на Ярмарке проектов ВШЭ: https://pf.hse.ru/208027466.html

=== Чему вы научитесь? ===
* Управление камерами через ONVIF, включая автодетекцию камер в сети.
* Анализ визуальных характеристик изображений

=== Какие начальные требования? ===
Владеть программированием, желательно иметь опыт общения с OpenCV.

=== Какие будут использоваться технологии? ===
* ONVIF

* OpenCV

* RTSP/MJPEG

=== Темы вводных занятий ===
Не в порядке изложения:

1. Архитектура проекта. API, внешние связи и зависимости.

2. Специфические технологии и используемые инструменты.

3. Доступные ресурсы, организация доступа.

4. Разделение ролей

=== Направления развития ===
Предлагаемые темы не являются чисто учебными, все они -- из рабочей практики и имеют выход в коммерческие сервисы, дополняя уже имеющийся функционал. Общая практика работы "на развитие" -- преуспевший в разработке некоего проекта студент (если хочет) становится "хостом" проекта и ведет его развитие дальше уже находясь в договорных отношениях с компанией.

Тема является частью более общего проекта по созданию съёмочного комплекса -- как с ручным управлением, так и с разной степенью автоматизации; как локального, так и полностью распределенного. Одно из внедрений такого комплекса начинается на ФКН для записи и трансляции значимых событий.

=== Критерии оценки ===
Про работу и оценки почитайте здесь: https://d.pr/143bq

Постарайтесь отнестись к этому с пониманием. Очень часто бодрое начало длится 3-4 недели и потом наступает тишина. Очень хочется, чтобы проекты доводились до запуска, а вы получали опыт успешной разработки и, возможно, работу в этих проектах уже в другом статусе. Но пока это для вас учебная работа, поэтому будем придерживаться описанных по ссылке правил и критериев. Спасибо!

=== Ориентировочное расписание занятий ===
Более точное расписание будет ясно после утверждения графика факультативов, пока ориентируемся на вторник, среду или пятницу во второй половине дня (после 15-16 часов).

На самом деле, для общения (как индивидуального, так и группового) удобно использовать средства видеосвязи -- это не заменяет очных встреч, но отлично дополняет их за счет возможности оперативно решать задачи "здесь и сейчас", сидя за удобным вам рабочим местом. Практически все темы проектов подразумевают работу в сети.