Re: [rtcweb] Alternative decision process in RTCWeb

Maik Merten <> Wed, 04 December 2013 09:21 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 75F3C1ADFD0 for <>; Wed, 4 Dec 2013 01:21:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EcP9Q-ij1u1b for <>; Wed, 4 Dec 2013 01:21:17 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4008:c01::22e]) by (Postfix) with ESMTP id 170E91AE218 for <>; Wed, 4 Dec 2013 01:21:06 -0800 (PST)
Received: by with SMTP id u15so6380657bkz.5 for <>; Wed, 04 Dec 2013 01:21:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=3/voxlAyBZmd8L13XP9mghKciQ0g9nYWJTG/WwFyx60=; b=jfM+KjkVn4SruSde/9b+NPr1nJ5Udhx/RSpk7Y3NCPyk6e0kgXWhysOtzifiTFTiTd OarC+nlEgk4f9bEBW7IlJ380yxVogdK3B4xM0sVLilTnhjV/qFWwcLiZ3ihhH+37Zoct u+kGxG+YOCUL9VaXRmIrU83vcxdVVvSzcr3ng6Xz1cEJtqAdjFgs1TI9Mpz1zm4POsiV wBe6SnizLZ+tDasjLW0jp2q0+ledEZG20bDhYqbZfMqey5Bk9wGb9qfzrgy2wlXJ1HIw QGRigEFoX033yjRKvidTCfxeDLR1FGqJjdrMPxEq1GfFYpJJo40NcSSHxxhgXHqGgswN aX5Q==
X-Received: by with SMTP id z8mr79653bko.126.1386148863297; Wed, 04 Dec 2013 01:21:03 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id tb8sm549441bkb.10.2013. for <> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Dec 2013 01:21:01 -0800 (PST)
Message-ID: <>
Date: Wed, 04 Dec 2013 10:22:30 +0100
From: Maik Merten <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
References: <> <> <> <> <> <> <BLU169-W1176AB7AECF0757C380A70E93EE0@phx.gbl> <20131129060936.GV3245@audi.shelbyville.oz> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] Alternative decision process in RTCWeb
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 04 Dec 2013 09:21:18 -0000

Am 04.12.2013 02:25, schrieb David Singer:
> Nonetheless, I still think H.263 deserves a more careful look.  I know Stephan is negative, but so far, he’s the only one.  For those who DON’T currently implement H.263, could/would you?

Quite clearly H.263 is not yet in the "so old it's as safe as it can 
get" realm, and the MPEG-4 visual patent pool lists numerous patents 
tagged as "H.263".

Of course, this does not necessarily mean that these patents read on the 
proposed H.263 baseline, but this is certainly difficult to assess 
without legal consultation. An interesting, if not conclusive, data 
point would be if those who deploy H.263 have a licensing agreement of 
any sorts in place.

Then again I wonder if the IPR-situation of H.263 (or MPEG-1 Part 2, or 
Theora, ...) can be simplified by mandating support only for 
Intra-frames (a decoder would be allowed, but not required, to skip 
decoding other frame types). This would mostly boil down to "mimick 
MJPEG", but with a clear upgrade path to "real video codec" for those 
who feel that the IPR situation for additional bitstream features is 
under control (by age of the codec, by IPR research, by licensing, ...).

Best regards,