Re: [rtcweb] H261/MPEG-1 video quality

Maik Merten <maikmerten@googlemail.com> Sun, 17 November 2013 19:43 UTC

Return-Path: <maikmerten@googlemail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0D711E91CD for <rtcweb@ietfa.amsl.com>; Sun, 17 Nov 2013 11:43:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.307
X-Spam-Level:
X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0r8-UhnL6yce for <rtcweb@ietfa.amsl.com>; Sun, 17 Nov 2013 11:43:04 -0800 (PST)
Received: from mail-bk0-x22d.google.com (mail-bk0-x22d.google.com [IPv6:2a00:1450:4008:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id E080B11E91B9 for <rtcweb@ietf.org>; Sun, 17 Nov 2013 11:40:33 -0800 (PST)
Received: by mail-bk0-f45.google.com with SMTP id mx13so90675bkb.18 for <rtcweb@ietf.org>; Sun, 17 Nov 2013 11:40:33 -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:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=1vzXyXK4LqsJpzsYkg12pXVSly966mpna/tprsrOyeY=; b=b9gvp6zsmuPPsB5/JfU2ZhI3CBV1Tx1W1X0Hg5DCOEiKvFsonp+K3RAA4b2sZg2IyU TDW8I/pm7kn9mK3TIjidS62V4lVo9gOm5vEkehaV2fgorerg7MpMpUELPywoMFbijPuF JcXAc3uYjcTWUEfIvaMc0cF7jqCMotbs5Rn5I6/Uwm5Qt2sH0fedvju1SlVUhAwrl4Tl MU+gH2swWiKBmVPeDDD3M+sHQqh4MWFK+AXX9ubQ58ySCNo2YxJ9UavTOjWMg4T1sRfv nAKkVrI8iL7dksCVrGgMYXkEr5Eaz0hpOxWoAjUL2s+FwpZ/eHjJfy//5LI1sxT5rvO8 I4FA==
X-Received: by 10.205.22.71 with SMTP id qv7mr9705236bkb.20.1384717232980; Sun, 17 Nov 2013 11:40:32 -0800 (PST)
Received: from [192.168.2.101] (dslb-188-101-189-061.pools.arcor-ip.net. [188.101.189.61]) by mx.google.com with ESMTPSA id qe6sm14133354bkb.5.2013.11.17.11.40.31 for <rtcweb@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 17 Nov 2013 11:40:31 -0800 (PST)
Message-ID: <52891BAD.50408@googlemail.com>
Date: Sun, 17 Nov 2013 20:40:29 +0100
From: Maik Merten <maikmerten@googlemail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
CC: rtcweb@ietf.org
References: <5284AB73.5030505@googlemail.com> <5285209D.7020407@googlemail.com> <CAGgHUiSROwRznKZWD4kjn8Vu7SrUVwOnHN1EJ-PTgR=WQmcxAQ@mail.gmail.com> <CAOJ7v-2najyMhcVNC8r0Sg+8xgkgDwasBSz476zA0BEpi2X5Pg@mail.gmail.com> <528559E4.3020903@nostrum.com> <5286272B.5000005@bbs.darktech.org> <CAOJ7v-3AT-5BHZAp2hvqm3Th20dk8Ec3orrj-voFMBwZroPdLA@mail.gmail.com> <DUB127-W49A2377699D81E3A1EA912E0FB0@phx.gbl> <CAOJ7v-27XiBGFT8=i=8ZyWYPP4UE64Jo41Pe_i1GAAUWfhDBuA@mail.gmail.com> <52877178.6040002@googlemail.com> <20131117175648.GB11012@cisco.com>
In-Reply-To: <20131117175648.GB11012@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] H261/MPEG-1 video quality
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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: Sun, 17 Nov 2013 19:43:05 -0000

Am 17.11.2013 18:56, schrieb Toerless Eckert:
> Right. I think the logics of the market space would make a choice
> of h261 as MTI just a big desaster and fruitless exercise
> in retro-engineering.
>
> - You start with legacy software, then it breaks under a lot
>    more/different use than what it was written for in the 90th and you
>    have to invest cycles fixing it.

Looking around I still see H.261 implementations that are available and 
maintained. Their coding technology may still be "meh", and unless you 
want to resurrect a specific implementation designed for Windows 3.11 
video phones I doubt it's an insurmountable challenge to get something 
up and running. Granted, supporting (n+1) codecs is always more work 
than supporting (n) codecs, and you'd always want to support either 
H.264 or VP8.


> - You wonder whether you should still optimize it, but ohh, wait,
>    lets check IPR on any possible optimization, oh wait, if i need
>    to start checking IPR, why the heck did i use this legacy codec.

Well, the one thing that makes H.261 somewhat interesting is that most 
people seem to agree that one *can* implement it without running into 
IPR - you don't *have* to strap rockets onto that pig. During the whole 
IPR discussion I think everybody focused on what IPR may or may not 
apply to the respective formats as defined by their normative *de*coder 
specifications - I guess because it's up to the implementor to decide 
upon advanced technologies employed by the *en*coder.

> - You try to figure how to make chips work whose native h261
>    support if at all still existing still works. YOu wonder if/how
>    the next generation of chips could do better on h261.

Would hardware support for H.261, if still existing, be actually 
relevant in a world where Skype is doing software encoding of H.264 on 
mobile devices?


Best regards,

Maik