Re: [rtcweb] MTI motion JPEG

Maik Merten <maikmerten@googlemail.com> Sat, 30 November 2013 23: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 B2D2A1AE4AD for <rtcweb@ietfa.amsl.com>; Sat, 30 Nov 2013 15:46:48 -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 QjoiLPPOOcB2 for <rtcweb@ietfa.amsl.com>; Sat, 30 Nov 2013 15:46:47 -0800 (PST)
Received: from mail-ea0-x235.google.com (mail-ea0-x235.google.com [IPv6:2a00:1450:4013:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id ED5B81AE4B0 for <rtcweb@ietf.org>; Sat, 30 Nov 2013 15:46:46 -0800 (PST)
Received: by mail-ea0-f181.google.com with SMTP id m10so7828412eaj.40 for <rtcweb@ietf.org>; Sat, 30 Nov 2013 15:46:44 -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=TjSPFJ7bd8k/t6eKlnri5pKd3fjQgLKt1361J0ZKy/0=; b=Tl8IfunfGAyGXoYfOS5Ty5uGFiov1HPRzyk/8faQE5v6CO1obxgfXbPpahlKgckgFC PVlLhI5EyayLKclWpv8LbqcWYOVtNzVyR+eGngX1ETxQWQKZ09qpjeVxlpBmlVtCErOo 0FdQbEgsP2XPrvhHTEJKoF7yyGU/oMSQKnZy96DtZPe4xTyvBRckqgalj/hiuiuGJyoJ c9wMwxnjXfnrolWjXqPM0rmyoKckaZdoUjbfXVsxScSg6AGR4sITRwKec2hG6SwJBO+H tv9bU1Kem+JGP1S1cJtMV/WXuWwPbacLwj9V5j5wc2ahpb0q7gq30KNnTWmlAu/FnswI IcKA==
X-Received: by 10.14.184.66 with SMTP id r42mr1008315eem.86.1385855204669; Sat, 30 Nov 2013 15:46:44 -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 g7sm6797695eet.12.2013.11.30.15.46.42 for <rtcweb@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 30 Nov 2013 15:46:43 -0800 (PST)
Message-ID: <529A78E0.4020106@googlemail.com>
Date: Sun, 01 Dec 2013 00:46:40 +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 23:46:48 -0000

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.

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