Данный пост создан исключительно с целью продемонстрировать, что реактор может иметь встроенный баянометр приемлемой функциональности без существенных затрат на его реализацию и сервера. Он ни в коем случае не пытается бросить тень на существующий баянометр от ExtraDj - вполне возможно его баянометр в сто раз круче (я не знаю).
Я совсем недавно начал создавать посты на реакторе, но уже успел ощутить всю проблематику поиска повторяющегося контента на этом ресурсе. И задумался о том, как много времени реактор мог бы сэкономить постерам, имей он встроенный баянометр. Сколько человек не смогли преодолеть сложности размещения контента на реакторе и сколько перестали это делать из-за большого количества времени, которое на это требуется (сужу исключительно по себе). 
А недавно ещё и получил разрешение от Вождя. Что ж, доступа к коду сайта и базе у меня нет. Выкачивать весь его контент, чтобы собрать отдельный баянометр я особо желанием не горю. Но могу, по крайней мере, разобраться в ситуации и продемонстрировать Proof of concept.
Я дотнетчик по большей части, поэтому технологии используются соответствующие. Вряд ли технологии, которые используются реактором, имеют какие-то существенные ограничения чтобы справиться с этой задачей.
Итак. Перцептивный хэш - похоже, то, что нам нужно. Проблема распространенная, поэтому сразу же нашлась библиотека, которая этот хэш считает - по крайней мере эту рутину писать не придётся. Как будто мы ещё ничего не сделали, а решение уже готово. Протестируем.
Первый кадр из видео. Разрешение 720х1280 против 320х568.
AverageHash и PerceptualHash - абсолютно одинаковые цифры. А это значит, что если вы сохраните этот хэш в БД рядом с картинкой, вы легко сможете достать по нему запись о картинке. Похоже баянометр в простейшем виде уже готов.
Извлечение данных. Т.к. некоторые реакторчане ссылались на проблему поиска в большом количестве данных, нужно протестировать и это. Приблизительно 7000000 картинок есть на реакторе. Возьмём MS Sql server. Создадим таблицу с 7000000 записей со случайными цифрами в качестве хэша. Чтобы всё было по-честному:
□ SELECT a,b FROM ( SELECT TOP 200 a,b FROM test ORDER BY a DESC) SQ ORDER BY a ASC .00 % - И Результаты ijl Сообщения a b 1 ! 6999800 ! 6964075964389932 2 6999801 16589863736228552 3 6999802 5026461835299065 4 6999803 43764015194280080 5 6999804 62220703321801248 6 6999805
Изменим одно из значение на реальный хэш с картинки выше. И посмотрим сколько надо времени чтобы её найти.
SET STATISTICS TIME ON select * from test where b=73051550389305359 JO % - IS Pe3yjibTaTbi ill Coo6mehMH A B 1 2000000 73051550389305359,баянометр,разработка,длиннопост
SET STATISTICS TIME ON select from test where b-73051550389305359 .00 % - Щ Результаты Ф Сообщения Время синтаксического анализа и компиляции SQL Server зремя ЦП = 0 мс, истекшее зремя = 0 мс. Зремя работы SQL Server: Зремя ЦП = 0 мс, затраченное зремя = 0 мс. Зремя синтаксического анализа и
По-моему проблем тут нет.
Дальше. Что если картинка немного отличается от оригинала. Например нам надо сравнить первый кадр видео с гифкой. Гифка, будет иметь кучу артефактов и, возможно, другой начальный кадр. Как тут:
Либо яркость на картинке выкручена на максимум, как тут:
Хэши не совпадают. Всё пропало? Не совсем. Обратите внимание на подсчёт "похожести" хэшей внизу картинок. Всё что нам нужно сделать, чтобы начать находить не только идентичные картинки, но ещё и похожие - это перенести логику подсчёта похожести в запрос к БД. Получим.
|SET STATISTICS TIME ON DECLARE @b Bigint = 73051550389305359 select from test where 64 Bit_Count(b @b)) 100 64)>92 100 % - ® Pe3>^bTaTbi ill Coo6mehMH A B 1 ! 100 218292640519487501 2 2000000 73051550389305359,баянометр,разработка,длиннопост
SET STATISTICS TIME ON DECLARE @b Bigint = 73051550389305359 select from test where ((64 - Bit_Count(b A @b)) 100 / 64)>92 .00 % - Щ Результаты Ф Сообщения Зремя скятахскчесхого анализа и компиляции SQL Server: время ЦП = 0 мс, истекшее время = 0 мс. Зремя работы SQL Server: Зремя ЦП = 0 мс,
Теперь по затратам времени и ресурсов. На этот Proof of concept ушло несколько часов - большая часть на подготовку и написание поста. Добавить его на любой свой сайт я могу за несколько часов. Нагрузку на сервер вы можете видеть в статистике запроса к БД. По-моему скромному мнению - она никакая. А если учесть, что эти запросы будут редкими - только при создании новых постов, то ими вообще можно пренебречь. Железу, на котором запущен sql сервер более пяти лет. Более того, пять лет назад это был бюджетный домашний комп.