Return-Path: 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 5FF3712B02A for ; Wed, 31 Aug 2016 08:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 1yzIWba8BOub for ; Wed, 31 Aug 2016 08:58:23 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1933512D1D7 for ; Wed, 31 Aug 2016 08:53:20 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id c133so38829080wmd.1 for ; Wed, 31 Aug 2016 08:53:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=PorvA5PGEX3seZ1xUUC0SCUym+9f/uxQMhfLDy45Dgs=; b=FLs1Th9KNhjd3em4LSB/sEC6hde2zzgA6bdA/kppKmo/wSnWkkoTuNZUjd1H8eU3cu iGm7YDaSYtkk4h60WJsZFuHjpB51RH6NlHI0c7XC9+jIctthtLBy7ej7cw9Jx9r4F1Xt 5M9KpG4QaVwax8PWQ7sRKdlMVVc3VHV6PmzToupDVJ/JFskzmJcf88OrZxurO37+vA3s LA1osmky0BRRhLt1p8JKYfaV1jWmEVJTDmvrt+zqWb8OZTa/3B/w7mmHHqiBkwZWjN6r +gqrRpjZvytKJQMOjI4pyoE5RhFkSjHt7fT1IfiqgsbX0+hE2EAouSyPs9/R/6rV+wvf f1/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=PorvA5PGEX3seZ1xUUC0SCUym+9f/uxQMhfLDy45Dgs=; b=hOJvnIUR0vd2yvbDSWHesm075FGVNW8CPoe8XlOfZG8S5nMBV6YUdiU4NHSvAc/MpW /y4cJHp0ZDo7tcvMOZpb39Oo3fIwNpOyA7a91mVt8Enwsm7Y+H57iFr2RhGv7Nm3+CTl ZNdgCLT8TuuG8QqEAS84vPYyLlVfDuXxug2rDs3m81qQKtFpFYN3x6wxRfO7Zw3Plzan 04+qQzCgTkew6m1grScWD+y6m6GvqmjZ7QxjRBVG2JSfgqxAhbeWQ7yiR2B/DK2fd0TG p+WnvWYHXugwMxK8R/Wj1oUa9WHAmQsTkYKPrlcMES+vk/ZKGVHqayXkluEEL9yUSBEb YpBw== X-Gm-Message-State: AE9vXwNz1aCEmL9uCozdrxC1uCHuum8xZ49xiLMqe4cnI0QBsc2ZGtYn6RYsEJ7vR3zadA== X-Received: by 10.28.125.80 with SMTP id y77mr10692475wmc.25.1472658798381; Wed, 31 Aug 2016 08:53:18 -0700 (PDT) Received: from [192.168.1.37] (50.red-88-6-120.staticip.rima-tde.net. [88.6.120.50]) by smtp.googlemail.com with ESMTPSA id m5sm25714010wmd.1.2016.08.31.08.53.17 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 Aug 2016 08:53:17 -0700 (PDT) To: rtcweb@ietf.org References: <724F4BD9-521C-47F7-AA33-155323F25ED3@iii.ca> <127876fa-32a5-473c-3820-af28dd82ab10@jesup.org> From: Sergio Garcia Murillo Message-ID: Date: Wed, 31 Aug 2016 17:53:16 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <127876fa-32a5-473c-3820-af28dd82ab10@jesup.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] Is support for non square pixels MTI X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 31 Aug 2016 15:58:24 -0000 On 31/08/2016 17:27, Randell Jesup wrote: > So we should be defining how MediaStreamTracks and PeerConnections > deal with this. Must all MSTs be square pixels always? (and what if > the source just isn't, must it be converted to square at the input > point (typically GetUserMedia)? Can PeerConnection carry a > non-square-pixel stream (separate from the MST requirement) for use > outside of the W3 environment? If so, how is it signaled? (I suspect > there's some way to do so in the SDP, haven't checked). At least in H264, pixel aspect ratio is handled internally by the encoder/decoder and signaled on the sar-understood, sar-supported sdp fmtp attributes. Not sure if VP8 has something similar. Best regards Sergio