#c #zlib #vnc #libjpeg
#c #zlib #vnc #libjpeg
Вопрос:
Я начинаю внедрять какое-то клиент-серверное программное обеспечение для удаленного скринкастинга (похожее на VNC) на C (платформа Windows), которое просто передает обновления экрана (фрагменты изображений) по сети.
Экран разделен на блоки, и каждый фрагмент сжимается в формат JPEG (вероятно, я буду использовать libjpeg-turbo) перед отправкой по сети. Итак, мой вопрос в том, будет ли полезно реализовать другой уровень сжатия (без потерь) для этих (уже сжатых в формате JPEG) фрагментов, например, с использованием zlib?
У меня такое ощущение, что zlib не даст какого-либо существенного улучшения с точки зрения пропускной способности, поскольку файлы JPEG уже будут сжаты. Я хотел бы избежать дальнейших затрат времени и денег на внедрение дополнительного уровня сжатия только в целях тестирования, поэтому я хотел бы услышать ваши предложения.
PS: В качестве дополнительного вопроса, есть ли какие-либо альтернативы получше, чем кодирование фрагментов в формате JPEG? Может быть, сжатие без потерь сразу? Является ли вышеупомянутый метод (разделение экрана на плитки => выбор обновленных плиток => сжатие их в формат JPEG => отправка по сети) хорошим способом реализации такого программного обеспечения?
Любой вид ввода был бы высоко оценен!
Комментарии:
1. Вряд ли вам удастся выжать дополнительное сжатие из фрагментов, сжатых в формате JPEG (если по какой-либо другой причине, то потому, что в противном случае JPEG был бы довольно плохим компрессором). Преобразованные квантованные данные JPEG уже сжаты (обычно с кодировкой Хаффмана). Кроме того, вы можете ожидать разумного сжатия от LZ только при наличии большого объема данных. Поскольку у вас есть «фрагменты», данные будут небольшими.
2. Понял, спасибо всем за ваши ответы.
Ответ №1:
Файлы JPEG уже сжаты настолько, насколько это возможно. Вы могли бы сэкономить несколько байт в заголовке, но это может быть компенсировано накладными расходами на дополнительное сжатие.
Если вам нужно выполнить быструю проверку, просто чтобы доказать свою точку зрения, должно быть легко заархивировать коллекцию примеров файлов jpeg и посмотреть, в чем разница.
Ответ №2:
Абсолютно не нужно.
Лучшим вариантом является использование обоих методов: подсчет цветов в блоке и использование zlib / rle / etc для нескольких цветов и jpeg для многих. Это самый простой подход. Я рекомендую вам ознакомиться с протоколом удаленного буфера кадров VNC.
Комментарии:
1. Владимир, когда ты говоришь: «посчитай цвета в блоке и используй zlib / rle / etc для нескольких цветов и jpeg для многих», что это мне даст? Сэкономит ли этот метод пропускную способность, процессор или качество изображения (из-за сжатия без потерь)? Или для этого потребуется больше некоторых ресурсов (пропускная способность или процессор)? Другими словами, каков компромисс в таком случае? Спасибо
2. Этот подход позволяет сжимать объекты пользовательского интерфейса, такие как окна и шрифты, без потерь, сохраняя при этом низкий битрейт, если на экране есть фото / видео контент. Таким образом, общее качество изображения остается высоким в обмен на циклы процессора.
3. Не уверен, что именно вы имеете в виду, но я предполагаю, что это не улучшает пропускную способность или производительность процессора, а только качество изображения для некоторых регионов.