Здравствуйте, DiPaolo, Вы писали:
DP>с этого и надо было начинать...
я всеравно напишу 1-2 из озвученных идей
DP>в таком случае я посоветую читать исходники референсных или просто опен-сорсных енкодеров/декодеров и разбираться, как оно устроено, сопоставляя со спеками на стандарты DP>ну далее и можно попробовать написать свой декодер с самым простым набором фичей и без оптимизаций
Здравствуйте, sergey2b, Вы писали:
S>мне надо подготовиться к собеседованию на программиста кодеков на verilog S>книгу по кодекам я нашел и начал читать нужна задачка для практики именно по внутреннЕму устройству кодеков
verilog это вообще не С и не С++
это вообще в другую степь
Здравствуйте, Alekzander, Вы писали:
J>>Сохранять каждый кадр в файл картинки и затем утилитой создавать из них видео — не предлагать.
A>А нет версии ffmpeg, оформленной как библиотека, а не файловая утилита командной строки?
Может, что-то типа ffmpeglib или libffmpeg поискать?
Здравствуйте, sergey2b, Вы писали:
Ф>>Попробуй, для начала, написать утилиту, которая сравнивает 2 видеофайла. Они могут иметь разное разрешение и вразных контэйнерах. Ф>>Это уже полезным делом будет.
S>мне надо подготовиться к собеседованию на программиста кодеков на verilog S>книгу по кодекам я нашел и начал читать нужна задачка для практики именно по внутренниму устройству кодеков
Здравствуйте, Великий Реверс, Вы писали:
ВР>verilog это вообще не С и не С++ ВР>это вообще в другую степь
Ну как сказать... На язык программирования — не очень похоже. На C++ — очень похоже
Основное отличие от плюсиков в том, что на плюсиках можно всю жизнь писать однопоточку и не знать горя, а там параллельность прямо в базе, от неё никак не отвертеться
Здравствуйте, Marty, Вы писали:
J>>>Сохранять каждый кадр в файл картинки и затем утилитой создавать из них видео — не предлагать.
A>>А нет версии ffmpeg, оформленной как библиотека, а не файловая утилита командной строки?
M>Может, что-то типа ffmpeglib или libffmpeg поискать?
Здравствуйте, DiPaolo, Вы писали:
A>>А нет версии ffmpeg, оформленной как библиотека, а не файловая утилита командной строки?
DP>FFmpeg – это и набор библиотек, и набор CLI. Все есть на оф. сайте
Я уже вчера посмотрел. У них на гитхабе код примеров выложен.
Здравствуйте, Marty, Вы писали:
Pzz>>Но у меня есть гипотеза, что если взять видеопоток, разбить его на фреймы, посчитать простые статистические характеристики каждого фрейма, типа размера по отношению к среднему, средней яркости, средней окрашенности и т.п., представить это в виде последовательности во времени, нормализовав точки отсчета и откоррелировать полученные последовательности, то степень корреляции будет неплохо показывать степень похожести фильмов, причем независимо от разрешающей способности и т.п. (но, возможно, зависимо от использованного кодека).
M>Во, это прямо моя мечта, хочу такое сделать, когда всё остальное переделаю и заняться будет категорически нечем
Есть такая штука, CDDB называется. Она довольно верно определяет CD-диски с музыкой, пользуясь глобальной базой данных.
Так вот, диски она идентифицирует не по контенту, а по продолжительности "песен" и пауз между ними. И в целом, зачастую угадывает.
Вот я предлагяаю сделать то же самое, но для видео. Только в отличии от CD, видео не размечено на траки и паузы. Но мне кажется, с помощью довольно незамысловатого анализа фреймов такую разметку можно получить. Ориентируясь, например, на степень сжатия фреймов, которая коррелирует с их "высокочастотностью" и отличием от предыдущих фреймов, и подобные характеристики.
M>Еще добавлю, что хотелось бы детектить вариант, когда один видос является фрагментом другого.
Это, как раз, можно в том, что я предлагаю.
M>Ещё — что бы умело детектить смену сцены/ракурса (когда изображение радикально меняется), выставлять тайминги, и выдавать описание сцены. И чтобы можно было помечать что вот это вот — реклама, или ещё какая-то лажа, и чтобы можно было это вырезать. Ну, или сделать нарезку сцен по размеченному списку.
А вот это уже явно требует анализа картинки. В этом я, во-первых, не копенгаген, а во-вторых, боюсь вычислительно это очень сложно/
M>Но это уже наверное пожелания к видеоредактору, альфа вроде делает тут? Чтобы прога нашла смены сцен, выдала скрипт к редактору, и бы потыкал по сценам, указал что удалить.
Pzz>Так вот, диски она идентифицирует не по контенту, а по продолжительности "песен" и пауз между ними. И в целом, зачастую угадывает.
Pzz>Вот я предлагяаю сделать то же самое, но для видео. Только в отличии от CD, видео не размечено на траки и паузы. Но мне кажется, с помощью довольно незамысловатого анализа фреймов такую разметку можно получить. Ориентируясь, например, на степень сжатия фреймов, которая коррелирует с их "высокочастотностью" и отличием от предыдущих фреймов, и подобные характеристики.
M>>Еще добавлю, что хотелось бы детектить вариант, когда один видос является фрагментом другого.
Pzz>Это, как раз, можно в том, что я предлагаю.
Да, это интересная мысль, про тайминги.
Я когда обдумывал как делать, тоже решил, что нужна какая-то глобальная база. Первое — по хешу детектить файл. Если не прокатило, то что-то пытаться локально сделать, и/или заливать на сервак для детального анализа
Тут навскидку придумал, брать какую-то центральную часть (после стандартизации кадра), например, 1/2ую по ширине высоте в центр, и искать её на следующем кадре. Тут тоже процессору попотеть придётся, но, может, есть какие-то готовые идеи на эту тему? Ну, а если не удалось узнать центр предыдущего кадра в следующем с каким-то смещением и с какой-то подходящей мерой схожести, то получается, что сцена изменилась.
Тут, скорее, три варианта:
1) Сцена та же, динамики нет, актёры просто руками машут, мимикрируют лицом. Должно прокатывать тупое сравнение кадров со степенью схожести условно 0.9
2) Камера перемещается/поворачивается за сценой, актёры машут руками, мимикрируют лицом. Сравниваемую часть берём в 3/4ти от оригинально кадра, ищем на следующем, при степени схожести в 0.9 считаем, что сцена та же
3) Камера быстро перемещается/поворачивается за сценой, актёры машут руками, мимикрируют лицом. Обычно в таких кадрах ГГ в центре кадра и руками машет с обычной скоростью, а фон может меняться быстро. Берём 1/2ую (или 1/3ю) в центре, ищем на следующем, при степени схожести в 0.9 считаем, что сцена та же.
Осталось решить вопросы:
1) Как вычислять степень схожести изображений? Есть ли алгоритмы?
2) Быстрый поиск части изображения в полном кадре, как это сделать быстрее? Может, что-то есть готовое?
В принципе, уже можно начинать пилить )))
А распознавание действующих лиц — это да, уже нейронки на сервере, и загрузка кина на него. Но та же предварительная разбивка на сцены локально может снять часть забот с сервака
Здравствуйте, Marty, Вы писали:
M>Кстати, ещё интересно, как детектить смену сцены?
А вот, например, если вычислить некоторые статистические параметры кадра, а именно:
— средняя освещённость
— средний окрас
— средняя сатурация (степень отличия окрашенности от серого)
— контрастность, как степень различия, скажем, 80-процентных персентилей между самыми светлыми и самыми тёмными участками
— доля мелких деталей (оценивается по степени сжатия или по преобладанию высокочастотных составляющих в кадре, если рассматривать его, как видеосигнал)
— степень отличия от предыдущего кадра (оценивается по объему выдали motion detector-а, но до нее еще добраться надо, это как раз те самые внутренности кодека, с которыми мечтает поближе познакомиться serkey2b)
То не будут ли границы сцен сопровождаться резкой сменой одного или нескольких из этих параметров?
Возможно, есть смысл разрезать кадр на небольшое количество прямоугольников, или отдельно рассматривать края/серединку.
Кстати, параметров-то получается немного, но трудно подобрать коэффициенты. Но при таком небольшом количестве параметров можно натренировать простенькую самодельную нейронную сетку (перцептрон), состоящую буквально из нескольких десятков нейронов — может получиться неплохой результат. Она, как раз, хороша в плане подбора коэффициентов.
Здесь, заметим, никакого image recognition не требуется. Но и 100% надежность не удастся гарантировать. С другой стороны, с иным кином и человеческому разуму не всегда легко угадать, где у него смена сцены.
Можно еще звуковой ряд учитывать, тоже по статистическим параметрам. Но возможен рассинхрон звука и изображения.
M>Осталось решить вопросы: M>1) Как вычислять степень схожести изображений? Есть ли алгоритмы?
Мне самому интересно, но на более специфическом уровне: как оценить, что изображение, отправленное на печать, после обработки всякими там фильтрами (1) всё то же самое изображение (2) не повёрнуто/не перевернуто (3) не обрезано по краям и не собрано в кучку (4) обладает ожидаемой разрешающей способностью (скажем, если изначально было 600 DPI, на выходе ожидается 300, то хотелось бы ибедиться, что итоговая чёткость где-то 250-300, а не 100-150) (4) цвета не уехали.
При этом, я моём случае, я могу произвольно выбирать входное изображение.
Здравствуйте, Великий Реверс, Вы S>>мне надо подготовиться к собеседованию на программиста кодеков на verilog S>>книгу по кодекам я нашел и начал читать нужна задачка для практики именно по внутреннЕму устройству кодеков ВР>verilog это вообще не С и не С++ ВР>это вообще в другую степь ВР>программист сергей опять себя обогнал
Меня тоже этот момент удивил. Верилог это ведь совсем другая степь. Я так понимаю,что на нем можно делать ISA и можно сделать спец инструкции для обработки видео -- ну да, особенности кодеков знать надо.
Здравствуйте, sergey2b, Вы писали:
S>мне надо подготовиться к собеседованию на программиста кодеков на verilog S>книгу по кодекам я нашел и начал читать нужна задачка для практики именно по внутренниму устройству кодеков S>то что вы пишите я могу написать используя avcodec
Здравствуйте, sergey2b, Вы писали:
S>подскажите пожалуйста идею для S>pet проекта что бы получить опыт с кодеками H.264/AVC, HEVC, and AV1.
По моему, если ты хочешь разобраться как конкретно устроены кодеки, самое действенное будет попробовать реализовать кодек самому.
Примерный план:
— Разберись почему кодеки работают в пространстве YUV. Чем отличаются 4:4:4 от 4:2:2 и от 4:2:0. Сделай быстрое преобразование туда сюда, пойми где теряется скорость, подумай как это соптимизиовать. Прореди цветовые плоскости в 2 раза, в 4 раза, в 16 раз. Посмотри как это отражается на кадре. Например был такой формат YUV9, где тратилось 9 бит на точку (8 — яркость и всего 1 бит на цвет).
— Основная идея видео кодеков это временная избыточность в соседних кадрах и вместо кодирования каждой точки в кадре, заменить это указателями на некие паттерны, которые уже известны и которые занимают гораздо меньше памяти. Описывает следующий кадр в терминах подобранных патчей, а потом вычитаем из оригинала. Чем точнее удастся подобрать паттерны, тем ближе к нулю будет разница, тем сильнее она сожмется в дальнейшем.
Для начала просто вычти один кадр из другого, посмотри что получится, попробуй закодировать разницу, посмотри как сильно она ужмется.
— Intra-frame`ы (кадры без ссылки на соседние), для тебя просто картинка. Сначала их сжимали подобно JPEG, используя DCT. Изучи как устроено. Попробуй реализовать. Сейчас в них также используется дифференциальное кодирование, но уже не по отношению к соседнему, кадру, а относительно специально подобранной таблицы шаблонов. Т.е. по таблице вместо макроблока (квадратика) ищется наиболее подходящий шаблон, из них составляется опорный кадр, а разница уже кодируется известными методами.
— Inter-frame`ы (вектора перемещения со ссылками на соседние кадры). Попробуй реализовать поиск макроблоков в соседнем кадре, посмотри как быстро у тебя это получится. Почитай, посмотри какая разница после восстановления и вычета у тебя получится, как сильно она будет сжиматься и т.д.
— изучи что такое CBR, VBR, ABR. Подумай как бы ты такое реализовал, какие сложности. Почитай, посмотри как это устроено в современных кордеках.
— посмотри алгоритмы для кодирования энтропии без потеть: кодирования Хафмана, арифметическое кодирования.
— Почитай как были устроены старые кодеки:
MPEG (h.261) — грубо просто JPEG для I-кадров. Макроблоки фиксированной длины 16х16, поиск векторов движения в P,B кадрах тоже строго для блоков 16x16.
MPEG2 (h.262) — просто развитие MPEG, но с расчетом на телевидение. Расширенная поддержка цветовых пространств, разрешения и чересстрочной развертки, плюс всякие сетевые дела, типа M2TS для вещания.
MPEG4 (h.264) — интрафреймы кодируются по таблице, макроблоки разного размера (типа ищем 16х16 — плохо получилось, 8х8, 4x4, ...), и т.д.
Даже если ты копнешь не глубоко и не сможешь до конца понять, проверить все идеи, поверь, у тебя останется хорошая база и будет неплохое понимание, что бы двигаться дальше уже в конкретном направлении.
