Нечеткие дубликаты видео — приблизительно одинаковые видео, которые могут отличаться параметрами кодирования, светоизмерительными параметрами (цветность, яркость), применением монтажа (титры, логотип), или наложением аудио. Идентичные видео с соответствующей дополнительной информацией, в любом из них (изменения длины клипа или сцен) рассматриваются как НДВ. Два различных видео с разным представлением и сценарии, считают НДВ, если они используют одинаковую семантику, и ни одного из них нет дополнительной информации.
Нечеткие дубликаты видео — изображение того же эпизода (например, «беспилотный летательный аппарат в воздухе») при различных точках обзора, размерах видео, ландшафте, погодных условиях, моделях БПЛА и движениях камеры. Одна и та же смысловая концепция может быть выражена в различной форме, при разном освещении, и параметрах сцены.
[Content based video matching using spatiotemporal volumes]
Нечеткие дубликаты видео — клипы, которые похожи или почти дублируют друг от друга, но выглядят по-разному. Они отличаются в силу разных условий съемки (точка обзора и настройки камеры, условия освещения, фон, передний план, и т. д.), преобразований (формат видео, частота кадров, разрешение, сдвиг, обрезка, гамма, контраст, яркость, насыщенность, размытие, выдержка, резкость и т. д.), операции монтажа (вставка, удаление, перемена мест кадров и модификация содержимого).
[UQLIPS: a real-time near-duplicate video clip detection system]
На самом деле, интересно обратиться к формальному определению дубликатов видео.
Нечеткие дубликаты по Ву
Например, по Ву, Нечеткие дубликаты видео — идентичные или приблизительно идентичные видео, почти точные копии друг друга, но отличающийся форматами файлов, параметрами кодирования, светоизмерительными параметрами (цветность, яркость), применением монтажа (титры, логотип, рамка), длиной и набором модификаций (вставка или удаление кадров) (doi: 10.1145/1291233.1291280)
На самом деле, не только его. Некоторые отечественные компании активно используют некоторые из описанных методов. Проблема в том, что все еще очень мало работ в этой области, а реализация и тестирование остаются пока дорогими.
Может очень сильно зависеть, от того что это были за ребята. У алгоритмов разные сферы применения, в том числе и в «обратную» сторону. «Кинжал хорош для того, у кого он есть. И горе тому, у кого его не окажется в нужную минуту.»(Черный Абдулла из к/ф Белое солнце пустыни).
Мне кажется, что вопросы авторских нужно решать цивилизованно, и не учитывать позицию только одной стороны.
Да, но как понимаю, в этом случае подойдет что угодно, втч «замечательные проекты на php». На тему быстро — требуется время на изучение фреймворка. Во некоторых подобных случаях удобнее и быстрее решить свою конкретную задачу руками.
Фремворки, кроме того, не всегда прозрачны (если, фреймворк написали не вы сами). Времени на понимание и отладку может уйди безумно много. А может и не уйти.
Про pyramid ничего сказать не смогу, — не пользовался.
А вот та же самая Django:
ограничение на схему бд;
крайне тяжело адаптировать к существующей базе;
сложно адаптировать к существующей инфраструктуре;
не удобно, и не всегда возможно оптимизировать;
есть проблемы с потокобезопасностью, не всегда ясно как их разруливать;
...
писать что хочешь.
Опять зависит от того, что Вы конкретно хотите.
Не всегда задача авторов фреймворка совпадает и вашей текущей задачей.
Очень хорошо изучать подходы, а не их конкретные реализации. И потом использовать в своих проектах.
Под конкретную задачу — конкретное решение.
Фреймворки плохо, ибо ограничивают в средствах.
Библиотеки (втч) аксепторы — хорошо, ибо есть много что готового, но это готовое, ты прозрачно можешь заменить на свое.
O(n^2) по времени?
Ну как минимум операций больше.
Сложность весьма очевидна в C, и то не всегда (компиляторы умнеют быстро).
Тут мы имеем компилятор, который потенциально может разгуливать подобные ситуации,
и оптимизировать. Для конкретного случая надо проверять. Константа может перекрыть сложность.
А развернул бы в другом месте со сходной семантикой.
Иногда это влечет трудно находимые ошибки.
То что lists:flatten — убийство, и использовать надо, только там где он действительно нужен, проверено многократно, на практике. Собственно из-за него я и сделал сравнение.
я как истинный нуб в Эрланге предположил и попробовал.
Так нельзя. Лучше сначала разобраться в вопросе, и потом уже строить предположения.
Есть много чего, о чем мне хочется тут рассказать,
но пока я не буду уверен в правильности и полезности,
делать это бессмысленно. Просто потрачу время, и свое и чужое.
Если это Ваши предположения, то не плохо бы это как-то пометить.
Выглядит как категоричное утверждение.
А неверное предположение, выданное за истину, вызывает негатив.
github.com/w495/bulk-video-converter/blob/master/examples/featured/scene-detection/scene-detection.expected.yaml#L28
А расскажите, где и как пригодилась?
Нечеткие дубликаты по Ву
Например, по Ву, Нечеткие дубликаты видео — идентичные или приблизительно идентичные видео, почти точные копии друг друга, но отличающийся форматами файлов, параметрами кодирования, светоизмерительными параметрами (цветность, яркость), применением монтажа (титры, логотип, рамка), длиной и набором модификаций (вставка или удаление кадров) (doi: 10.1145/1291233.1291280)
А какие алгоритмы Вам кажутся непонятными?
Мне кажется, что вопросы авторских нужно решать цивилизованно, и не учитывать позицию только одной стороны.
github.com/zavr/nodectl
Мы пользуемся, пока нареканий не было.
Да, но как понимаю, в этом случае подойдет что угодно, втч «замечательные проекты на php». На тему быстро — требуется время на изучение фреймворка. Во некоторых подобных случаях удобнее и быстрее решить свою конкретную задачу руками.
Фремворки, кроме того, не всегда прозрачны (если, фреймворк написали не вы сами). Времени на понимание и отладку может уйди безумно много. А может и не уйти.
Про pyramid ничего сказать не смогу, — не пользовался.
А вот та же самая Django:
Опять зависит от того, что Вы конкретно хотите.
Не всегда задача авторов фреймворка совпадает и вашей текущей задачей.
Очень хорошо изучать подходы, а не их конкретные реализации. И потом использовать в своих проектах.
./tplлучше убирать в ./privФреймворки плохо, ибо ограничивают в средствах.
Библиотеки (втч) аксепторы — хорошо, ибо есть много что готового, но это готовое, ты прозрачно можешь заменить на свое.
Ну как минимум операций больше.
Сложность весьма очевидна в C, и то не всегда (компиляторы умнеют быстро).
Тут мы имеем компилятор, который потенциально может разгуливать подобные ситуации,
и оптимизировать. Для конкретного случая надо проверять. Константа может перекрыть сложность.
Если позволяет логика приложения я бы сделал так:
А развернул бы в другом месте со сходной семантикой.
Иногда это влечет трудно находимые ошибки.
То что lists:flatten — убийство, и использовать надо, только там где он действительно нужен, проверено многократно, на практике. Собственно из-за него я и сделал сравнение.
Так нельзя. Лучше сначала разобраться в вопросе, и потом уже строить предположения.
Есть много чего, о чем мне хочется тут рассказать,
но пока я не буду уверен в правильности и полезности,
делать это бессмысленно. Просто потрачу время, и свое и чужое.
Если это Ваши предположения, то не плохо бы это как-то пометить.
Выглядит как категоричное утверждение.
А неверное предположение, выданное за истину, вызывает негатив.