Subject: [rtcweb] MTI motion JPEG

From: Ralph Giles <[email-masked]>
Date: Fri, 29 Nov 2013 16:49:01 -0800

I'd like propose motion JPEG as the manditory-to-implement video codec,
per RFC 2435 or similar.

Yes, I'm serious. I didn't propose this earlier to avoid splitting the
vote at the last meeting.

Our goal here is to to avoid negotiation failure. We don't have
concensus for either h.264 or VP8, but no one is happy with the
performance of the older formats we've been discussing.

Since we can't have acceptable performance in our fallback we should
instead optimize for minimum complexity. We all have to ship this and
hope it's never used in practice.

While not as trivial as G.711 audio, mjpeg+rtp is simpler to implement
than the more recent obsolete codecs we've been discussing. JPEG decode
is already universally supported for still images. As the simplest
compressed format it has advantages for testing and legacy
interoperation, just like G.711. It works fine over a LAN and for the
WAN...well, you can have a couple of blurry frames a minute if you like
that better than nothing at all.

 -r

---

From: cowwoc <[email-masked]>
Date: Fri, 29 Nov 2013 20:07:20 -0500

This reminds me of a joke from Google's keynote in the WebRTC World 
conference, where they demoed http://idevelop.ro/ascii-camera/

Didn't we say there were multiple mature implementations of H.261 in the 
wild? As such, what does it matter how complex the implementation is?

Gili

On 29/11/2013 7:49 PM, Ralph Giles wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Maik Merten <[email-masked]>
Date: Sat, 30 Nov 2013 21:46:27 +0100

Actually that may work. Toying around with mjpeg I found that, for 
instance, CIF video can be transmitted with somewhat usable quality at 
full framerate at slightly over one mbit/s. Usable quality at around 
half a mbit/s can be achieved by decreasing the framerate. Perceived 
picture quality can be increased by postprocessing (deblocking, 
deringing) or the decoding technique described in "William B. 
Pennebaker, Joan L. Mitchell - JPEG: Still Image Data Compression 
Standard, 1993". I would also assume that support for the arithmetic 
encoder could be mandated by now, increasing coding efficiency.

So this makes for a lousy video codec, but at least it's fast, 
"everywhere", presumably free of additional IPR risk, and flexible 
regarding frame size. I can also be used to occasionally push 
high-quality pictures (think slide shows), a use case H.261 included a 
hack for (4CIF) but would be better handled by MJPEG anyways.

Maik

---

From: Maik Merten <[email-masked]>
Date: Sat, 30 Nov 2013 21:48:53 +0100

Am 30.11.2013 21:46, schrieb Maik Merten:
>  I can also be used to occasionally push
> high-quality pictures (think slide shows)

*It* (MJPEG) can be used to occasionally push high-quality pictures.

I transmit only low-quality pictures.

Maik

---

From: Leon Geyser <[email-masked]>
Date: Sat, 30 Nov 2013 22:50:23 +0200

I don't mind MJPEG at high bitrates like 1Mbit/s, but at 256Kbps I
struggled to get something acceptable out of ffmpeg's MJPEG encoder. I have
a 256Kbps connection btw :)

On 30 November 2013 22:46, Maik Merten <[email-masked]> wrote:

> instance, CIF video can be transmitted with somewhat usable quality at full
> framerate at slightly over one mbit/s. Usable quality at around half a
> mbit/s can be achieved by decreasing the framerate. Perceived picture
> quality can be increased by postprocessing (deblocking, deringing) or the
> decoding technique described in "William B. Pennebaker, Joan L. Mitchell -
> JPEG: Still Image Data Compression Standard, 1993". I would also assume
> that support for the arithmetic encoder could be mandated by now,
> increasing coding efficiency.
>
> regarding frame size. I can also be used to occasionally push high-quality
> pictures (think slide shows), a use case H.261 included a hack for (4CIF)
> but would be better handled by MJPEG anyways.
>
>
> Maik
>
>

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Sat, 30 Nov 2013 16:57:48 -0500

> hack for (4CIF) but would be better handled by MJPEG anyways.

Maik,

Can you share your technique for making your test clip(s)?  I am trying
but ffmpeg (the only tool I know how to do this with) keeps overshooting
severely the bitrate I set for it.

-- 
Libre Video
http://librevideo.org

---

From: Maik Merten <[email-masked]>
Date: Sat, 30 Nov 2013 23:31:30 +0100

> severely the bitrate I set for it.

Basically I'm either forcing a fixed quantizer with -qmin and -qmax or 
asking for really low bitrates via -vb. Yes, bitrate control in ffmpeg 
seems to be somewhat unreliable in ffmpeg.

Maik

---

From: Maik Merten <[email-masked]>
Date: Sun, 01 Dec 2013 00:46:40 +0100

> I'd like propose motion JPEG as the manditory-to-implement video codec,

Is it feasible to extend the RFC with, e.g., a run-length coded list of 
skipped MCUs ("macroblocks")? Picture data for those would be copied 
over from the last frame. This may even work with unmodified JPEG 
decoders (either by filling in stub data for the skipped MCUs at the 
receiving end or by encoding skipped MCUs compact run of zeroed 
coefficents) and a postprocessing step.

(If coding an explicit list of skipped MCUs is not practical, one can 
regard MCUs with all-zero coefficients as "skipped". An encoder will 
have to take this into account so no MCUs are skipped by accident, though.)

This contradicts the minimal-effort argument to some degree, but at 
least this would enable efficient transmission of screencasts, increase 
coding efficiency for "talking head" content, and offer additional means 
for bitrate management (partial screen updates).

Maik