Идея вроде неплоха, но, если честно, я проектировал систему исходя из того, что она будет обрабатывать сотни поисковых запросов в секунду (даже сейчас на слабом неттопе даёт под сотню), и, если хотя бы половина из них будет иметь отрицательный результат, то даже база под эту информацию будет довольной большой. Не говоря уж о том, что потом эти запросы надо заново прогнать и отправить пользователю сообщение... Большая нагрузка. И нужен ли этот результат пользователю спустя неделю или месяц?
Абзац был там с самого начала. Почему не обновляется сразу? Алгоритм требует перестройки всей базы (помимо базы с описаниями фильмов, она обычная) для быстроты поиска. Делать это после добавления каждого видео - слишком большие затраты и износ SSD. Поэтому обновление происходит через значительный промежуток времени.
Спасибо за проделанную работу! Вы правы в списке фильмов приложения добавленный фильм появляется сразу, хотя проверка и добавление в базу происходят не так часто. В статье я указал, что сборка базы происходит раз в неделю, думаю, что через указанное время он там появится.
Пока думаю над этим. Дело в том, что планируемый объём данных будет довольно большим, порядка 15-20 ТБ и это должны быть данные на SSD. Требуется довольно мощное и специфичное железо, что большинству не по карману и уже накладывает определённые ограничения.
По-поводу хэш функции: тут, не столько она плоха, сколько сами данные. Здесь я должен извиниться и сказать, что в данной публикации не описал механизм получения исходных данных для вычисления хэша, а они получаются путём загрубления значений R,G,B.
R'=R/8; G'=G/8; B'=B/8;
Иначе флуктуации значений (от пережатых версий видео или JPEG компрессии скриншотов) будут зашкаливать.
Самое большое количество кадров приходится на значения R=G=B=0. Потом R=G=B=255, ну и дальше - градации серого.
Что касается 32 битного целого, то тут ситуация такова. То, что кадров больше, чем значений хэша - в этом нет ничего плохого. Просто когда мы ищем наш кадр, мы анализируем группу с этим значением хэша. Если их там несколько десятков, то мы их быстро проанализируем. Даже если несколько сотен, то на SSD всё летает. Проблема, когда их тысячи и больше. А в выше упомянутых ячейках R'=G'=B'=0 их в той базе может быть несколько миллиардов, что уже очень плохо. Но, плюс U32 в том, что база указателей имеет фиксированный размер в 32 ГБ и она по первому же fseek'у и read'у даёт нам место, где читать данные уже в файле с записями и сколько их читать! Для U64 файл указателей будет нереально большой. Кроме того, это потребует много аппаратных и вычислительных ресурсов при перестроении данных (если мы добавим информацию о новых видео).
Всё же поиск в отдельных случаях требует дополнительного ускорения и я для этого использую перцептивные хэши (об этом в следующей публикации). Как я их использую? Внутри группы с конкретным индексным хэшем данные сортируются по перцептивному хэшу. Получается двойное механизм индексации. Это реально помогает, хотя там есть некоторые нюансы. И, несмотря на это, для некоторых значений R'=G'=B'=0 и некоторых других внутри данной группы могут быть очень длинные подгруппы с одинаковым значением перцептивного хэша. Вот такие цепочки я отбрасываю.
Что касается последнего Вашего замечания, то я его не понял. Хэш я вычисляю для каждого кадра, а mjpeg используется для видео (т.е. множества кадров).
Совершенно верно. Велосипед. Но не детский трёхколёсный, а спортивный, многоскоростной.
Моя система по загруженному изображению может сказать не только из какого фильма данный кадр или отрывок, но и показать место из которого данный кадр или отрывок взяты. На данный момент есть готовый поисковый инструментарий, работающий веб-сайт и клиентский софт как для добавления информации, так и для поиска. От пользователя требуется лишь заполнить информацию о видео (название, режиссёр и пр.) и всё.
Что касается упомянутых Вами алгоритмов, то у них другая задача, да и требования к памяти, насколько я могу судить, совсем другие.
По поводу Джины. Судя по описанию на сайте, это некий инструмент, а не готовый к использованию продукт, хотя могу ошибаться, т.к. не имел опыта работы с ней.
Идея вроде неплоха, но, если честно, я проектировал систему исходя из того, что она будет обрабатывать сотни поисковых запросов в секунду (даже сейчас на слабом неттопе даёт под сотню), и, если хотя бы половина из них будет иметь отрицательный результат, то даже база под эту информацию будет довольной большой. Не говоря уж о том, что потом эти запросы надо заново прогнать и отправить пользователю сообщение... Большая нагрузка. И нужен ли этот результат пользователю спустя неделю или месяц?
Абзац был там с самого начала. Почему не обновляется сразу? Алгоритм требует перестройки всей базы (помимо базы с описаниями фильмов, она обычная) для быстроты поиска. Делать это после добавления каждого видео - слишком большие затраты и износ SSD. Поэтому обновление происходит через значительный промежуток времени.
Спасибо за проделанную работу! Вы правы в списке фильмов приложения добавленный фильм появляется сразу, хотя проверка и добавление в базу происходят не так часто. В статье я указал, что сборка базы происходит раз в неделю, думаю, что через указанное время он там появится.
Основная идея сервиса - создать нечто подобное Shazam,но только для видео. А всё остальное - вторично.
Вы правы, спасибо, я исправил.
Пока думаю над этим. Дело в том, что планируемый объём данных будет довольно большим, порядка 15-20 ТБ и это должны быть данные на SSD. Требуется довольно мощное и специфичное железо, что большинству не по карману и уже накладывает определённые ограничения.
Да, пожалуй Вы правы. Так и сделаю.
Спасибо за развёрнутый комментарий!
По-поводу хэш функции: тут, не столько она плоха, сколько сами данные. Здесь я должен извиниться и сказать, что в данной публикации не описал механизм получения исходных данных для вычисления хэша, а они получаются путём загрубления значений R,G,B.
R'=R/8; G'=G/8; B'=B/8;
Иначе флуктуации значений (от пережатых версий видео или JPEG компрессии скриншотов) будут зашкаливать.
Самое большое количество кадров приходится на значения R=G=B=0. Потом R=G=B=255, ну и дальше - градации серого.
Что касается 32 битного целого, то тут ситуация такова. То, что кадров больше, чем значений хэша - в этом нет ничего плохого. Просто когда мы ищем наш кадр, мы анализируем группу с этим значением хэша. Если их там несколько десятков, то мы их быстро проанализируем. Даже если несколько сотен, то на SSD всё летает. Проблема, когда их тысячи и больше. А в выше упомянутых ячейках R'=G'=B'=0 их в той базе может быть несколько миллиардов, что уже очень плохо. Но, плюс U32 в том, что база указателей имеет фиксированный размер в 32 ГБ и она по первому же fseek'у и read'у даёт нам место, где читать данные уже в файле с записями и сколько их читать! Для U64 файл указателей будет нереально большой. Кроме того, это потребует много аппаратных и вычислительных ресурсов при перестроении данных (если мы добавим информацию о новых видео).
Всё же поиск в отдельных случаях требует дополнительного ускорения и я для этого использую перцептивные хэши (об этом в следующей публикации). Как я их использую? Внутри группы с конкретным индексным хэшем данные сортируются по перцептивному хэшу. Получается двойное механизм индексации. Это реально помогает, хотя там есть некоторые нюансы. И, несмотря на это, для некоторых значений R'=G'=B'=0 и некоторых других внутри данной группы могут быть очень длинные подгруппы с одинаковым значением перцептивного хэша. Вот такие цепочки я отбрасываю.
Что касается последнего Вашего замечания, то я его не понял. Хэш я вычисляю для каждого кадра, а mjpeg используется для видео (т.е. множества кадров).
Моя система по загруженному изображению может сказать не только из какого фильма данный кадр или отрывок, но и показать место из которого данный кадр или отрывок взяты. На данный момент есть готовый поисковый инструментарий, работающий веб-сайт и клиентский софт как для добавления информации, так и для поиска. От пользователя требуется лишь заполнить информацию о видео (название, режиссёр и пр.) и всё.
Что касается упомянутых Вами алгоритмов, то у них другая задача, да и требования к памяти, насколько я могу судить, совсем другие.
По поводу Джины. Судя по описанию на сайте, это некий инструмент, а не готовый к использованию продукт, хотя могу ошибаться, т.к. не имел опыта работы с ней.
Да, пожалуй. Хотя в данный момент это не первоочередная задача.
Не совсем понял идею. Чем их заинтересовать?
Вот здесь тоже делают стеганографию со сжатием именно в JPEG.
Делать это в BMP или PNG — детская забава!