либы для обработки дифов изображений...

← →
istok20 © (2016-08-28 16:26) [0]

программа на делфи должна делать много скриншотов
для экономии места, хотим сохранять мастер-скрины +дифы

какие есть готовые решения для создания таких последовательностей картинок в делфи?

желательно чтобы либа была кросплатформенная, собирать эти последовательности нужно будет в браузере на js ))

← →
Игорь Шевченко © (2016-08-28 17:06) [1]

Любой алгоритм сжатия видео к твоим услугам

← →
istok20 © (2016-08-31 11:55) [2]

> Любой алгоритм сжатия видео к твоим услугам

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

какой кодек при сопоставимом с mpeg4 сжатии выдаст более четкие шрифты?

картинки исходные в png, перегоняем вот так (пока на маке):
ffmpeg -f image2 -r 2 -i frame%04d.png -qscale 20 -y -an -r 24 -vcodec msmpeg4 -vtag MP43 out_scale_20.avi

← →
Pavia © (2016-08-31 12:07) [3]

В теории H.264 у него минимальная апертура косинусного преобразования в два раза меньше чем у mpeg4. И сжимает сильнее за счет обратных кадров поэтому при равных объемах число квантов у H.264 выше. А вообще в интернете есть тесты кодеков на все случае жизни.

← →
han_malign © (2016-09-01 14:55) [4]

https://msdn.microsoft.com/en-us/library/windows/desktop/ff819485%28v=vs.85%29.aspx

← →
istok20 © (2016-09-01 21:06) [5]

> Pavia © (31.08.16 12:07) [3]

да, H.264 с 20-30 потерей качества идеален для нас по размеру и качеству. проблемка лишь в том, что ест прилично цпу во время своей работы

можно же по идее запустить его процесс из нашей программы так, чтобы он скажем работал дольше, но ел меньше цпу? важно, чтобы конвертация не напрягала пользователя пк...

выставили процесск IDLE_PRIORITY_CLASS, но это его не останавливает, (что и понятно, тк остановит только при конкуренции за ресурсы, а не когда 90% цпу свободно...)

> istok20 © (01.09.16 21:06) [5]
>
>
> > Pavia © (31.08.16 12:07) [3]
>
>
> да, H.264 с 20-30 потерей качества идеален для нас по размеру
> и качеству. проблемка лишь в том, что ест прилично цпу во
> время своей работы

Ну как-то обычные видеорегистраторы без проблем работают с этим кодеком.
Вот например те, с которыми я работаю имеют плату видеозахвата на 16 каналов. Чуть более половины каналов записываются в режиме 10 fps, остальные в режиме 1 fps. Ну да. Там конечно картинка заметно меньше в пикселях. Но не на несколько порядков.

> можно же по идее запустить его процесс из нашей программы
> так, чтобы он скажем работал дольше, но ел меньше цпу? важно,
> чтобы конвертация не напрягала пользователя пк...выставили
> процесск IDLE_PRIORITY_CLASS, но это его не останавливает,
> (что и понятно, тк остановит только при конкуренции за
> ресурсы, а не когда 90% цпу свободно...)

1) сделать программку которая периодически будет усыплять процесс с кодеком и пробуждать. 30 мс даёт поработать 970 мс спит (выйдет 1 кадр в секунду).
http://stackoverflow.com/questions/11010165/how-to-suspend-resume-a-process-in-windows
2) Запустить через DX со своим таймером.
3) Взять код кодека, а он открытый и простой и подправить.

либы для обработки дифов изображений... Найти похожие ветки