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

Материал из Wiki - Факультет компьютерных наук
Перейти к: навигация, поиск
Компания On-Air.Pro
Учебный семестр Осень 2017
Учебный курс 3-й курс
Максимальное количество студентов, выбравших проект: 5-10



Что это за проект?

В соседнем проекте предлагается разработка файлового менеджера для медиаархивов, расположенных в 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 провайдера).

Организация работы (Как студенты будут работать в команде?)

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

Далее организуется slack и трекер (обычно trello), где ведется рабочее общение и трекинг задач.

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

Компоненеты (Из каких частей состоит проект?)

  • Подключение к GoogleDrive
  • Базовый анализатор (основные метаданные)
  • Углубленные анализаторы в ассортименте
  • Менеджер ресурсов (запуск виртуальных машин - воркеров)

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

  • GoogleDrive API, OAuth.
  • Анализ изображений, видео, звука. От FFPROBE/ImageMagick до OpenCV и далее -- на сколько хватит фантазии.
  • Работа с виртуальными серверами на хостинг-провайдерах (API)

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

Какие начальные требования?

В зависимости от роли в проекте:

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

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

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

Темы вводных занятий

Не в порядке изложения:

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

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

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

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

Критерии оценки

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

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

Похожие проекты

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

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

Контактная информация

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

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

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

d.korolev@gmail.com