Livestream: Эффективность JPEG против MJPEG

У меня есть веб-сервер с изображением livecam.
Он имеет два режима:Livestream: Эффективность JPEG против MJPEG

JPEG (отображает текущее изображение при обновлении страницы)
MJPEG (отображает MJPEG поток)

На данный момент я использую режим JPEG. Я загружаю и показываю изображение 20 раз в секунду.
Это прекрасно работает без каких-либо задержек.
Но у него довольно высокая загрузка процессора (около 70% из 200% на моем iPhone 6S).

Код:

if let url = NSURL(string: "http://1.1.1.181:8085/?action=snapshot") { 
    let request = NSURLRequest(URL: url, cachePolicy: .ReloadIgnoringLocalAndRemoteCacheData , timeoutInterval: 1) 
    NSURLConnection.sendAsynchronousRequest(request, queue: NSOperationQueue.mainQueue()) { 
     (response: NSURLResponse?, data: NSData?, error: NSError?) -> Void in 
     if data != nil { 
      self.imageView.image = UIImage(data: data!)      
     } 
    } 
}

Мои вопросы:

Есть ли более эффективный способ загрузки и отображения изображения с в веб-страницу?
Эффективнее использовать поток MJPEG. (Если да: , какую схему вы можете порекомендовать)?

источник

2016-05-01 123FLO321

определяют эффективный. Что конкретно вы связываете для оптимизации? – szatmary

Процессор и аккумулятор. – 123FLO321

Я предполагаю, что вы имеете в виду на клиенте. Тогда вы тоже не хотите этого делать. Кодируйте на стороне сервера видео h264. В телефоне имеется специальное оборудование для воспроизведения. – szatmary

Да, вам нужно использовать видеокодек какого-то типа, поскольку у вас есть видео. Попытка отправить отдельные кадры, как это, является пустой тратой пропускной способности и процессора. Я впечатлен тем, что вы получаете 20 FPS из вашей текущей настройки.

MJPEG - это видеокодек, который работает, постоянно улучшая изображение, точно так же, как JPEG. Содержимое фреймов, которые меняются, подталкивается как усовершенствование того, что уже существует, что позволяет сохранить большую пропускную способность. MJPEG также прост в реализации, поскольку, если вы можете декодировать JPEG прогрессивным, вы уже можете декодировать MJPEG (возможно, с некоторыми незначительными улучшениями).

В любом случае, в наши дни доступны гораздо лучшие видеокодеки. Многие из них имеют аппаратные кодеки, что означает, что работа выгружается на этот чип кодека, а не напрямую обрабатывается ЦП. Это то, как высокопроизводительное видео запускается на аппаратном обеспечении, которое в противном случае не могло бы ускориться. Выясните, какой кодек вы хотите использовать на основе поддержки системы, которая уже существует для него на вашей целевой платформе. H.264 и VP8 довольно популярны, а VP9 подходит.

источник

2016-05-02 16:46:30 Brad

H.264 - вариант. – 123FLO321

Вряд ли разница между ними. Единственное различие заключается в том, что с M-JPEG поток отправляет последовательность из JPEG s вместо одного запроса, поэтому вы не тратите полосы пропускания, открывая новое соединение на кадр, что в некоторых случаях может быть незначительным по сравнению с размером изображения и M-JPEG может привести к задержкам изображения в соединениях с низкой пропускной способностью из-за буферизации вместо сброса кадров.

Motion JPEG — Encoding — Wikipedia

video surveillance on C# — CodeProject

источник

2018-01-31 12:06:37

Livestream: Эффективность JPEG против MJPEG

ответ

Смежные вопросы