Re: [rtcweb] TCP vs UDP for media

Cullen Jennings <fluffy@iii.ca> Thu, 31 May 2012 15:01 UTC

Return-Path: <fluffy@iii.ca>
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 CABA821F8710 for <rtcweb@ietfa.amsl.com>; Thu, 31 May 2012 08:01:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.432
X-Spam-Level:
X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599]
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 KTzOB6xVkY6p for <rtcweb@ietfa.amsl.com>; Thu, 31 May 2012 08:01:52 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 292D221F8700 for <rtcweb@ietf.org>; Thu, 31 May 2012 08:01:52 -0700 (PDT)
Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A23A722E25B; Thu, 31 May 2012 11:01:44 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="iso-8859-1"
From: Cullen Jennings <fluffy@iii.ca>
In-Reply-To: <4FB34CAD.80103@ericsson.com>
Date: Thu, 31 May 2012 09:01:42 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <E37AE3A9-2C5B-415F-BB37-D95488BF46BD@iii.ca>
References: <B236B24082A4094A85003E8FFB8DDC3C1A45AE47@SOM-EXCH04.nuance.com> <4FB2E8FC.40404@thaumas.net> <CABcZeBPWiGYaD6yBtBzeZMNgnz20JnHTyVHTev71KZagGRiqHw@mail.gmail.com> <B236B24082A4094A85003E8FFB8DDC3C1A45AFA0@SOM-EXCH04.nuance.com> <4FB34CAD.80103@ericsson.com>
To: Milan Young <Milan.Young@nuance.com>, public-media-capture@w3.org
X-Mailer: Apple Mail (2.1084)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] TCP vs UDP for media
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: Thu, 31 May 2012 15:01:53 -0000

You should take this as a requirement to the public-media-capture@w3.org list (added to thread). It seem reasonable to want to specify which codec the data returned from getusermedia should use. 

On May 16, 2012, at 12:43 AM, Magnus Westerlund wrote:

> On 2012-05-16 03:37, Young, Milan wrote:
>> Yes, existing web technologies for transport would work fine.  In
>> fact I wrote a demo based on WebSockets, the AudioAPI, and
>> getUserMedia.  But it's a bit cludgy and only transmits PCM audio.
>> 
>> Would my use case for live access to an encoded media stream be a
>> good fit for a revised MediaStreamRecorder?  Would this group the
>> right place to host such an effort?
> 
> I think this is something you should take to the W3C. As it appear to be
> primarily an API question. Getting access to the content in the JS
> application or request the browser to record to a local file which later
> can be uploaded it would not be in this WG.
> 
> Cheers
> 
> Magnus Westerlund
> WG chair
> 
>> 
>> Thanks
>> 
>> -----Original Message----- From: Eric Rescorla [mailto:ekr@rtfm.com]
>> Sent: Tuesday, May 15, 2012 4:47 PM To: Ralph Giles Cc: Young,
>> Milan; rtcweb@ietf.org Subject: Re: [rtcweb] TCP vs UDP for media
>> 
>> On Tue, May 15, 2012 at 4:38 PM, Ralph Giles <giles@thaumas.net>
>> wrote:
>>> On 12-05-15 4:22 PM, Young, Milan wrote:
>>> 
>>>> I'm wondering if any thought has been given to TCP as a media
>>>> transport.
>>> 
>>> Where low latency transmission isn't an issue, one can generally
>>> fall back to established TCP-based protocols, like HTTP streaming
>>> and websockets, so we haven't really worried about that angle in
>>> the context of webrtc.
>>> 
>>> Recording the stream is a requirement, so probably something could
>>> be built using that, merging recordings from each endpoint to fix
>>> up any dropped packets.
>> 
>> Agreed. This seems like something that could be done using just 
>> getUserMedia() plus existing Web technologies.
>> 
>> -Ekr _______________________________________________ rtcweb mailing
>> list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
>> 
> 
> 
> -- 
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb