Re: [rtcweb] MTI Video Codec: a novel proposal

cowwoc <> Tue, 11 November 2014 21:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AB7441AC42C for <>; Tue, 11 Nov 2014 13:02:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LYQsKMYhmAun for <>; Tue, 11 Nov 2014 13:02:42 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 525D41A7003 for <>; Tue, 11 Nov 2014 13:02:31 -0800 (PST)
Received: by with SMTP id tp5so12197387ieb.22 for <>; Tue, 11 Nov 2014 13:02:30 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=tI1tibAwRtTV6HUPd+yL59cjpCYMBlwodpiufEshco4=; b=m1k5SL8v7XqDT/YPCqYPHsRHj3+VKuFXTpObu2iqUinGkMHz6n3us7AizCZkBYqgK1 DdTwoh5DnNv4zjEDX4vGyilhkLrzGP/TXJobDx/xKWexGCYpURy1m811TL5YejOpgXN0 EhxQFCdtN9ddPuV9YhqNjVAWvPlZ8a11cufollg5Zh2YIk+24p1RWibhEG2WJaLnrX1A iNMy3Q9CdSSD4soNbECIfYljyzAbG85B1i9n8ZrU962tEL7hKrW9fAK70RZ5oQvD3ufB RfJuW2S2noGF01eCs/T1BbMHZhXORdBLpwirk7ePWKr+Ee/RFOE5MreTsUzlYGNbUUb+ Es5Q==
X-Gm-Message-State: ALoCoQmPBPtod1ezDnRISkuoqdtaVrmMMlDbZduw07BbWf4g+dZHXULhnOIaY2yYPVqIEDecs8N+
X-Received: by with SMTP id fs3mr19794657igb.6.1415739750670; Tue, 11 Nov 2014 13:02:30 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id fm2sm6838750igb.6.2014. for <> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Nov 2014 13:02:30 -0800 (PST)
Message-ID: <>
Date: Tue, 11 Nov 2014 16:02:28 -0500
From: cowwoc <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
References: <> <> <> <20141111011054.GR8092@hex.shelbyville.oz> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] MTI Video Codec: a novel proposal
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: Tue, 11 Nov 2014 21:02:43 -0000

On 11/11/2014 3:13 PM, tim panton wrote:
> My personal preference would be to replace ‘both’ with ‘either’ in the 
> device rule, but I understand
> the thinking behind the ‘both’ phrasing.

Same here. I would also prefer replacing "both" with "either" in the 
device rule. What is the practical benefit of forcing both codecs on 
non-browsers? If you proceed this way, won't most applications accept 
being declared non-compliant instead of investing the extra work/cost of 
implementing both codecs?

Implementing both codecs only makes sense when you need interoperability 
between applications written by different authors. The same argument 
does not apply when both endpoints are written by the same author. 
Furthermore, I would argue that when separate authors want their 
applications to inter-operate they will have the necessary incentive to 
make that happen, with or without the specification dictating how it 
should be done.

Another spin on this would be to say: all libraries/platforms 
(abstraction layers used to write applications) must implement both 
codecs, whereas applications (end-users) can implement as many codecs as 
they'd like.