Re: [rtcweb] Video codec selection: Dropping options

Leon Geyser <lgeyser@gmail.com> Thu, 28 November 2013 10:20 UTC

Return-Path: <lgeyser@gmail.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 C6B071ADF47 for <rtcweb@ietfa.amsl.com>; Thu, 28 Nov 2013 02:20:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 ZH2JhX1IYe5T for <rtcweb@ietfa.amsl.com>; Thu, 28 Nov 2013 02:20:27 -0800 (PST)
Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 1746F1ADF46 for <rtcweb@ietf.org>; Thu, 28 Nov 2013 02:20:26 -0800 (PST)
Received: by mail-lb0-f171.google.com with SMTP id q8so5997226lbi.16 for <rtcweb@ietf.org>; Thu, 28 Nov 2013 02:20:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vdhAWXXCs66C48bewr/irODpSymNk+37da51g8tkv18=; b=U5XdE0YB9LeHFqN7ixk5xyX2ZzOEEKZrrrP9tavsR2dfPFJE6XKi/EKR2Whi6iNcyA BSFO2JWJ4h/I3ByRr2hj4t3NZUJkQCmgktH9oNUN54M7wC67b0rt+3m5urwYOMUg203P Ww61eYk1/JSd0+YVFzi0OvCwGYuQIRpCsPXi0Iwik6zx8MFLPITEeMGj2eBE0szpZcRD DRRZYZp9DVzKP1mCO3plwH0fTCZD+X11VZjQB4pJaBtTI1eTEdYcabLCXjeSp0qIBywK kwEDkNTnue/NpP7FEQFV9+9KCmK0sZ5hNjjcX5pQG+9f+IKnapQCP4tadGcEh0a00zJC 7UlQ==
MIME-Version: 1.0
X-Received: by 10.152.6.201 with SMTP id d9mr15670029laa.25.1385634025578; Thu, 28 Nov 2013 02:20:25 -0800 (PST)
Received: by 10.114.168.70 with HTTP; Thu, 28 Nov 2013 02:20:25 -0800 (PST)
In-Reply-To: <E44893DD4E290745BB608EB23FDDB7620A13AE73@008-AM1MPN1-041.mgdnok.nokia.com>
References: <E44893DD4E290745BB608EB23FDDB7620A13AE73@008-AM1MPN1-041.mgdnok.nokia.com>
Date: Thu, 28 Nov 2013 12:20:25 +0200
Message-ID: <CAGgHUiQLXSzU+AvCcvDa383DA=OGd9-NTedfFOAVGt+OmyKwwg@mail.gmail.com>
From: Leon Geyser <lgeyser@gmail.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Content-Type: multipart/alternative; boundary="089e013d1a94e2226b04ec3a0f9c"
Subject: Re: [rtcweb] Video codec selection: Dropping options
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: Thu, 28 Nov 2013 10:20:30 -0000

I also agree on this.

Also 5 does not mean anything.
I don't like my own option of 8 that much, because 10 is much better :)
11 and 13 are scary options.
If 12 is possible it would be a great option. Do most patents only apply
for encoding?

I am a bit confused about option 15. How does that one work?
Let's say I have a two sides: H.264 encoding/decoding + Theora decoder and
the other side has VP8 encoding/decoding + Theora decoder. How do they
communicate?


On 28 November 2013 10:22, <Markus.Isomaki@nokia.com> wrote:

> Hi,
>
> I'm not much in favor of the voting, but if we do it:
>
> Based on the consensus call we already held in Vancouver, I would propose
> to drop from the list in [1] any options that make exclusively VP8
> mandatory to implement or exclusively H.264 mandatory to implement. I think
> we have already established that much, and including those options in any
> vote seems wrong.
>
> In practice I'm talking about these four options:
> 1. All entities MUST support H.264
> 2. All entities MUST support VP8
> 3. All entities MUST support both H.264 and VP8
> 4. Browsers MUST support both H.264 and VP8, other entities MUST support
> at least one of H.264 and VP8
>
> What the WG should focus on is to see if there is a consensus on any of
> the so called "fallback" options vs. no MTI. I think these are all valid as
> such as a "fallback":
>
> 5. All entities MUST support at least one of H.264 and VP8
> 6. All entities MUST support H.261
> 7. There is no MTI video codec
> 8. 5+6, i.e. All entities MUST support H.261 and all entities MUST support
> at least one of H.264 and VP8
> 9. All entities MUST support Theora
> 10. All entities MUST implement at least two of {VP8, H.264, H.261}
> 11. All entities MUST implement at least two of {VP8, H.264, H.263}
> 12. All entities MUST support decoding using both H.264 and VP8, and MUST
> support encoding using at least one of H.264 or VP8
> 13. All entities MUST support H.263
> 14. All entities MUST implement at least two of {VP8, H.264 CBP, Theora}
> 15. All entities MUST support decoding using Theora.
>
> I think it would be problematic even if one of options 1-4 came out as a
> winner from a voting procedure, since it would force a large part of the
> community to implement something they have valid reasons to avoid. Some of
> the options 5-15 may have issues as well, but at least a consensus call
> among them would still be in order, since we haven't really had it so far.
> And presumably the issues and polarization are "smaller" than with the VP8
> vs. H.264 argument.
>
> Regards,
>         Markus
>
> [1] http://trac.tools.ietf.org/wg/rtcweb/trac/wiki/WikiStart
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>