Re: [rtcweb] MTI motion JPEG

Maik Merten <maikmerten@googlemail.com> Sat, 30 November 2013 20:46 UTC

Return-Path: <maikmerten@googlemail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBF7D1AE28F for <rtcweb@ietfa.amsl.com>; Sat, 30 Nov 2013 12:46:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id anv8jjn7cayv for <rtcweb@ietfa.amsl.com>; Sat, 30 Nov 2013 12:46:34 -0800 (PST)
Received: from mail-ea0-x22f.google.com (mail-ea0-x22f.google.com [IPv6:2a00:1450:4013:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id C15781AE1B4 for <rtcweb@ietf.org>; Sat, 30 Nov 2013 12:46:33 -0800 (PST)
Received: by mail-ea0-f175.google.com with SMTP id z10so7776997ead.34 for <rtcweb@ietf.org>; Sat, 30 Nov 2013 12:46:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=a5q/GoQh9iDKRohSY6zF2mz+uUgzb724ZsPqb90kXYg=; b=W2dtGh4XKu3C4wV4+VUYaEGWeXNEPztUonk3Ygoylj6ylwtHBP/TrgXiZp6LYA6mfF 9dEj6AJdpR1YVKEBmVUztbVWu4xRDBaRT5CldBZHNKL/v4bzxWa7N4q4L7UemJRtQq/j 0yZmtdN/DeSzP1RQZH78qWwACymzW33ZBdtaWn6qU2QYHYOVsL2bNzJawiiT+UNj8cXq uA8StG3ZfHAkklRKcE5ccB3boyAKL4NKAa1uWgpcIu2IY76ind/JKpn+L6R6jJewzViK RC7tqVTHsv/vBHTRN94CPlOflwWHQxzGZ/hzNoGwphBxKvHl/0joe+b9cuK6cA7RPlE+ tZew==
X-Received: by 10.15.76.6 with SMTP id m6mr3206329eey.37.1385844391691; Sat, 30 Nov 2013 12:46:31 -0800 (PST)
Received: from [192.168.2.109] (port-92-201-122-127.dynamic.qsc.de. [92.201.122.127]) by mx.google.com with ESMTPSA id v7sm37136738eel.2.2013.11.30.12.46.29 for <rtcweb@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 30 Nov 2013 12:46:30 -0800 (PST)
Message-ID: <529A4EA3.9010003@googlemail.com>
Date: Sat, 30 Nov 2013 21:46:27 +0100
From: Maik Merten <maikmerten@googlemail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <529935FD.7090409@thaumas.net>
In-Reply-To: <529935FD.7090409@thaumas.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] MTI motion JPEG
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Nov 2013 20:46:36 -0000

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


Am 30.11.2013 01:49, schrieb Ralph Giles:
> 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
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>