Данный пост создан исключительно с целью продемонстрировать, что реактор может иметь встроенный баянометр приемлемой функциональности без существенных затрат на его реализацию и сервера. Он ни в коем случае не пытается бросить тень на существующий баянометр от 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 сервер более пяти лет. Более того, пять лет назад это был бюджетный домашний комп.