Очередная проблема. mjpeg дает слишком жирный трафик. Хочется сделать дельту изображения. Сейчас схема такая: отдается целиковый кадр, после чего следующие N кадров - это дельта. Разница между прошлым и текущими кадрами. Дельта жмется тем же jpeg-ом. И тут - проблема. Если считать дельту между двумя оригинальными кадрами, то позникает серьезная накопительная ошибка - смотрится ужасно. Если же считать дельту между текущим оригинальным и тем, что на клиенте (оригинальный предыдущий с учетом искажений, вросимых jpeg-ом), то дельта получается "шершавая" и ее компрессия жпегом не дает никакого выигрыша. Loseless алгоритмы дают размер в 2 раза привышающий размер кадра в жпеге.
Вопрос вдогонку. libjpeg даже на quality 100 дает ужасное качество жпега. Есть ли "современный" опенсорсный жпег?
Вообще-то принято иметь определённое кол-во ключевых кадров(оригинальных картинок), тогда погрешности будут не сильно заметны.
Ну я так и делаю. Ключевой кадр - N дельт - ключевой - N дельт - и т.д. Смысл в том, что лобовая loosing (как и looseless) компрессия тут не подходит. Я конечно понимаю, что mpeg4 не за час выдумывался, но все же...)
Jpeg жмет картинку квадратами, если сделать дельту между текущим кадром и предыдущим по квадратам а оставшееся место скажем залить "прозрачным" то должно хорошо и жаться и совмещаться
По-моему в looseless вообще не должно быть погрешностей, при работе с дельтами. Если они есть значит где-то баг с расчётами. Потом jpeg работает в несколько этапов. На первом искажает картинку. По идее нужно брать дельту с икажённой. Хотя утверждать наверняка не могу, лучше порыться в исходникаж mpeg, или вообще сразу юзать каку-нибудь готовую либу.
Pavia Очень тяжело для сервера. Нужно уметь кодировать десятки каналов на квадкоре. Честные mpeg-подобные алгоритмы боюсь не вытянет.
http://www.google.com.ua/search?q=ffmpeg+3gp&start=0&start=0&ie=utf-8&oe=utf-8&client=firefox-a&rls=org.mozilla:en-US:official 3gp делается телефоном на телефонном процессоре с одновременным выводом на экранчик и болтовней по телефону. довольно плотный формат. часовая запись со звуком около 30мб. ффмпег гугль уверяет делать его и из него умеет. ссылки выше
телефонные процессоры под гигарец частотой уже )) на первых телефонах с поддержкой видео записи были процы под 300 мгц и они с большим трудом переваривали 176*220*15кадров не говоря уже о том какое ужасное качество картинки дает сжатие в 3gp "на лету"
_basmp_ *тяжелый_вздох* Телефон делает decoding, а мне нужно encoding. Encoding это на порядок (на порядки) более тяжелая операция чем decoding.
_DEN_ Как вариант: на сервак если видюху поставить типа 9800гтх, и на ней всю обработку сделать на CUDA, например?
_DEN_ Как вариант: на сервак если видюху поставить типа 9800гтх, и на ней всю обработку сделать на CUDA, например?
