Pull to refresh

Comments 19

Расскажите, пожалуйста, хотя бы немного о том, как устроена ваша поисковая система внутри? Как именно вы индексируете и храните такое множество кадров? Как справляетесь с тем, что кадры могут немного отличаться (шум, артефакты, лого каналов)?

upd: прошу прощения, увидел ваши остальные статьи. Оставьте на них ссылки в тексте для таких как я, пожалуйста :)

Да, пожалуй Вы правы. Так и сделаю.

Раз вы просите сообщество в помощи с наполнением контента, то может стоит опубликовать это в Open Source? К примеру, MusicBrainz хранит слепки звуков, их БД доступна как общественное достояние и полно свободного ПО для работы с этой БД.

Пока думаю над этим. Дело в том, что планируемый объём данных будет довольно большим, порядка 15-20 ТБ и это должны быть данные на SSD. Требуется довольно мощное и специфичное железо, что большинству не по карману и уже накладывает определённые ограничения.

А после можно будет продать эту систему как сервис для правообладателей, и будут банить ролики на тиктоке, да и не только

Основная идея сервиса - создать нечто подобное Shazam,но только для видео. А всё остальное - вторично.

Загрузить приложение можно с сайта https://www.aapsoftware.ru/product.php?id=78 . После загрузки Zip-архива его содержимое необходимо извлечь в рабочий каталог и запустить файл VideoColorCreator.exe.

Ссылка на приложение некорректная. Она ведёт на "Video Color Capture".

идея для фичи: как насчет уведомления пользователя о том что его поиск который он выполнял ранее нашел видео тк вы обновили базу и добавили новый хайповый сериал и тп

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

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

Попробовал данный алгоритм в действии.

Зарегистрировался, Проверил, что выбранного мной для теста фильма нет в библиотеке.

Скормил приложению фильм "Цой". Не будем сейчас о самом фильме. Просто я киноман бывший (хотя бывших не бывает) и стало интересно, что там наснимали. Потом наделал скринов с того же файла через VLC. Штук 10, примерно. Не распознался ни один. Я могу предположить, что фильм попадает в выборку через некоторое время, но в приложении он был уже виден в поиске, когда я проводил эксперементы.

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

Либо я слеп, либо вы добавили уже после прочтения мной абзац "Ожидание". Попробую через неделю.

Если проект взлетит, то это будет очень удобно. Буквально на днях искал старый фильм по не очень хорошим скринам. Нашёл в конце концов, но это заняло время.

Постараюсь в свободное время поглядывать за базой и дополнять.

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

Для такой такой проблемы есть стандартное решение: всё новое за день сливается в мелкую базу, которая индексируется в разы быстрее, например, ежечасно. Каждый день (или как удобнее) появляется новая маленькая база, а раз в неделю делаем полный ребилд, 7 мелких баз удаляем. А поиск ищет одновременно в нескольких базах, результаты объединяет.

Не всё так просто, на самом деле. Алгоритм работы такой, что для построения базы требуется файл указателей (некоторые подробности алгоритма есть в статьях). Он предназначен для быстрой работы с гигантским объёмом информации и сам тоже не маленький - 32 ГБ. Каждый день выделять по 32 ГБ (это не считая самих данных) - это около 214 ГБ в неделю быстрой SSD памяти. Тут ещё и износ и прочее. Если бы этим занимался Яндекс, Майкрософт или Гугл, то они бы на эти расходы чихали с высокой башни. А если этим занимается небольшая комманда с ограниченным бюджетом, то ...

32GB в день — пустяк, я думаю у меня столько SSD расходует на ребилде проектов ))

Проверил, так и есть. SMART на рабочем SSD пишет 18+ TB host writes за 8к часов, т.е. 2+GB в час. И это не вусмерть компилировать непрерывно, а обычная разработка.

В качестве предложения: можно использовать торрент-трекеры как источник контента. Есть небольшой опыт в этом деле (на одном из форумов часто не работали скринлисты, и я решил делать их самостоятельно): взял несколько самых дешевых VPS и один сайт для распределения задач. На VPS ставим transmission и vlc, по крону запускаем свои скрипты. Парсим форум, скачиваем torrent-файлы (оперируясь на раздел+название+размер раздачи), проверяем содержимое torrent-файла (что это не *.iso/*.bdmv/*.ifo), через API у transmission добавляем/удаляем раздачи, получаем их статус. Через cvlc делаем скрины (работает очень медленно, но я не нашел более всеядного варианта создания скринов по таймкоду).

Sign up to leave a comment.

Articles