Потоковая передача MJPEG

в https://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Video/pktvideoaag.html

он говорит:

Другой тип сжатия видео — MJPEG… результирующий видеопоток больше, но размеры пакетов более стабильны — 1316 байт (полезная нагрузка).

это правда?

Вероятно. Mjpeg не имеет межкадрового сжатия. Делает скорость передачи данных более предсказуемой.
@DigiVisionMedia Хорошо, это как-то связано с размером пакета?
Я не знаю. Я просто размышляю. В схеме сжатия, такой как mjpeg, каждый кадр обычно очень близок по размеру к кадрам непосредственно перед и после него. Протокол интеллектуального потока может использовать это в своих интересах.
См . статью о MJPEG в Википедии . «Потоковая передача HTTP [MJPEG] создает пакеты из последовательности изображений JPEG, которые могут быть получены клиентами». Поддерживает мое предположение. Что касается проверки точного размера пакета, я ничего не могу найти. Часть проблемы заключается в том, что для MJPEG нет официального стандарта. Это как прапрадед современного веб-видео, родившийся, когда Интернет был еще диким.
@DigiVisionMedia, наверное. Я думаю, что каждый кадр никогда не будет помещаться в спутниковый пакет Ethernet, IP, RTTY, ATM, X.25 или Ku Band QAM. Таким образом, одинаковый размер кадров не имеет ничего общего с пакетами. Вы собираетесь заполнить кучу пакетов, тысячи и тысячи, прежде чем получите хотя бы полный кадр. Заполните ли вы этот последний пакет до 1299 или 1305, не будет иметь никакого значения.
@DigiVisionMedia Во-вторых, я видел, что MJPEG также сильно различается по битрейту, все зависит от сложности контента. Если у вас есть баннерный экран, такой как «WORLD TV», и это полностью белый экран с большими черными буквами, квантизатор JPEG разбивает каждый кадр до 98 или 200 тыс. ТАК, что отсутствие внутрикадрового временного сжатия не имеет значения, потому что, когда вы получаете кадр после кадров «WORLD TV», который содержит около 400 различных цветов, шестьдесят семьдесят различных силуэтов животных, людей и т. д., вы получаете представление о скорости передачи данных. ракеты до 1М 2М 3Мбит/сек.
Это верно для всех сжатий. Если видео очень активное, оно требует больше данных. Но осмысленные видеоролики редко перескакивают со статических 2-битных цветов на 16-битные сцены природы с большим количеством движения. По крайней мере, не чаще, чем несколько раз здесь и там. Как я уже сказал, я предположил. Я хорошо понимаю mjpeg. Я вообще в сетях не разбираюсь. Я мог быть полностью выключен.
@DigiVisionMedia Ну, просто имейте в виду, что передача данных по сети всегда происходит небольшими порциями, например, РЕАЛЬНО небольшими, например, 1316 BYTES . Так что даже в 8-битном цвете 320x288 будет много пакетов. Это утверждение в документе CICSO выглядит так, как будто кто-то только что прислал его по почте, потому что я не могу придумать ничего, что имело бы в этом какой-то смысл.
@DigiVisionMedia Я думаю, может быть, если вы посмотрите на АРЕНДУЕМУЮ ЛИНИЮ или СПУТНИКОВЫЙ ТРАНСПОНДЕР, вы знаете, что у вас есть определенная скорость соединения, и если вы не используете ее на этой скорости, вы все равно будете платить, поэтому, если вы в конечном итоге сожмете свой Видео H264 до 800 КБ/с просто глупо, потому что вы платите за 10 МБ/с. Итак, вы знаете, что MJPEG снизит скорость до 8 МБ/с и будет в основном выше, чем h264. Я все еще не уверен в вашем утверждении, что скорость передачи данных более предсказуема.

Ответы (1)

Хотя MJPEG может иметь более стабильный и более высокий локальный средний битрейт во времени, его битрейт может сильно варьироваться в зависимости от входного контента. См. Сжатие MJPEG ; утверждение, что результирующие сетевые кадры/пакеты будут более согласованными, совершенно необоснованно. Возможно, на макроуровне, учитывая, скажем, спутниковый транспондер Ku Band 10 Мбит/с, MJPEG может фактически имитировать функцию HARD MUXRATE, которую обычно выполняет мультиплексор транспортного потока MPEG, но даже это сомнительно, учитывая высокую изменчивость MJPEG. битрейт с учетом очень простого контента.

Жесткий мультиплексор: https://stackoverflow.com/questions/44392689/ffmpeg-vbr-cbr-conversion-and-streaming-of-mpeg-2-ts-video-files