Re: [rtcweb] MTI motion JPEG
Basil Mohamed Gohar <basilgohar@librevideo.org> Mon, 02 December 2013 19:50 UTC
Return-Path: <basilgohar@librevideo.org>
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 CBE211AD7C1 for <rtcweb@ietfa.amsl.com>; Mon, 2 Dec 2013 11:50:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 ukAyzQMsjACG for <rtcweb@ietfa.amsl.com>; Mon, 2 Dec 2013 11:50:19 -0800 (PST)
Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 775981AC4A7 for <rtcweb@ietf.org>; Mon, 2 Dec 2013 11:50:19 -0800 (PST)
Received: from [10.10.40.120] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id DB80E9D91EF for <rtcweb@ietf.org>; Mon, 2 Dec 2013 14:50:16 -0500 (EST)
Message-ID: <529CE475.6000901@librevideo.org>
Date: Mon, 02 Dec 2013 14:50:13 -0500
From: Basil Mohamed Gohar <basilgohar@librevideo.org>
Organization: Libre Video
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <529935FD.7090409@thaumas.net> <529A78E0.4020106@googlemail.com> <529C57CC.209@alvestrand.no> <529C60E1.6060504@googlemail.com>
In-Reply-To: <529C60E1.6060504@googlemail.com>
Content-Type: text/plain; charset="ISO-8859-1"
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: Mon, 02 Dec 2013 19:50:21 -0000
For what it's worth, what you described sounds a lot like the "Smoke" video codec, which, as far as I know, exists only on the OLPC project via gstreamer. At least, that's about the only reference I've ever found for it. On 12/02/2013 05:28 AM, Maik Merten wrote: > Yes, I guess you're right, this is out of scope. It's just that its > tempting to come up with ideas for improvements, given the low-hanging > fruits in case of MJPEG are basically touching the ground. > > Maik > > Am 02.12.2013 10:50, schrieb Harald Alvestrand: >> Designing new video codecs is something that I don't think we should do >> in this WG at this time. >> >> >> On 12/01/2013 12:46 AM, Maik Merten wrote: >>> 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 -- Libre Video http://librevideo.org
- Re: [rtcweb] MTI motion JPEG Basil Mohamed Gohar
- Re: [rtcweb] MTI motion JPEG Harald Alvestrand
- Re: [rtcweb] MTI motion JPEG Maik Merten
- Re: [rtcweb] MTI motion JPEG Maik Merten
- Re: [rtcweb] MTI motion JPEG Maik Merten
- [rtcweb] MTI motion JPEG Ralph Giles
- Re: [rtcweb] MTI motion JPEG cowwoc
- Re: [rtcweb] MTI motion JPEG Maik Merten
- Re: [rtcweb] MTI motion JPEG Maik Merten
- Re: [rtcweb] MTI motion JPEG Leon Geyser
- Re: [rtcweb] MTI motion JPEG Basil Mohamed Gohar