Subject: [rtcweb] Gaelle Martin-Cocher's and Andrew Allen's choices (Was: Straw Poll on Video Codec Alternatives)

From: Hervé W. <[email-masked]>
Date: Wed, 8 Jan 2014 21:30:53 +0100

On 8 January 2014 20:04, Andrew Allen <[email-masked]> wrote:
>
>
> 6.    All entities MUST support H.261
>
> a.    Are you in favor of this option [Yes/No/Acceptable]: No
>
> b.    Do you have any objections to this option, if so please summarize
> them:
>
> ·         H263 would be better if we are going back in time. H.261 quality
> is very poor.
>
> ·         H261 is obsolete and took years to remove from use.

[...]

> 16.  All entities MUST support Motion JPEG
>
> a.    Are you in favor of this option [Yes/No/Acceptable]: Acceptable
>
> b.    Do you have any objections to this option, if so please summarize
> them:

What makes MJPEG more acceptable than H.261 ?

- Hervé

---

From: Gaelle Martin-Cocher <[email-masked]>
Date: Wed, 8 Jan 2014 21:20:38 +0000

MJPEG is still available/in use on hardware platforms. It has a higher probability to be effectively supported than a request to re-implement H261. 

If MJEPG becomes the MTI, I am hopeful that RTCWeb will mandate a more advance codec (H264 CHP, HEVC, VP9, Dhalaa, AVS2 etc) sooner than if any one of the other proposed codecs becomes MTI. 

Sincerely,
Gaëlle

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of Hervé W.
Sent: Wednesday, January 08, 2014 3:31 PM
To: [email-masked]
Subject: [rtcweb] Gaelle Martin-Cocher's and Andrew Allen's choices (Was: Straw Poll on Video Codec Alternatives)

[...]

- Hervé
_______________________________________________
rtcweb mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: cowwoc <[email-masked]>
Date: Wed, 08 Jan 2014 16:23:00 -0500

> What makes MJPEG more acceptable than H.261 ?

I was just about to post the same question. I fail to see the logic :)

Gili

---

From: David Singer <[email-masked]>
Date: Thu, 09 Jan 2014 11:37:53 -0800

> I was just about to post the same question. I fail to see the logic :)

I think I explained before, as well.  We all have JPEG implementations (optimized) as support for JPEG in general is hardly optional.  The RTP format is easy.  Bit-rate is linear with frame rate (unlike predictive codecs, where as the frames get further apart the prediction finds life harder).  JPEG can do decent quality at low frame rates, or low pictures sizes, or...

H.261 isn’t implemented, and I think few will even if mandated. Even when given a lot of bits I seem to recall it wasn’t great.  It has size and other odd limitations.

David Singer
Multimedia and Software Standards, Apple Inc.

---

From: Maik Merten <[email-masked]>
Date: Thu, 09 Jan 2014 21:40:40 +0100

> H.261 isn’t implemented, and I think few will even if mandated. Even when given a lot of bits I seem to recall it wasn’t great.  It has size and other odd limitations.

Just for the sake of completeness: Provided one can live with the 
resolution limitations, H.261 should and probably will always deliver 
better results than MJPEG for a given bitrate. So if one recalls H.261 
not being great even with "lots of bits", MJPEG will most likely be 
(much) worse. The ultimate image quality limit for H.261 is the smallest 
available quantizer, which allows for virtually artifact-free visual 
reproduction. Enclosed is screenshot of the p64 H.261 encoder using the 
smallest available quantizer on frame 42 of the sign_irene_cif sequence.

This is merely to show that H.261 is not by design locked to a picture 
quality of "always bad" (you did not claim that, but one could misread). 
In practice I fully expect H.261 to deliver workable quality in 
scenarios where MJPEG just cannot deliver video content.

This of course doesn't mean that MJPEG already being "everywhere" is not 
a very nice aspect or that the H.261 resolution restrictions are not 
unfortunate.

Maik