On 04/02/2014 07:52 PM, Ian Hickson wrote:
On Mon, 3 Mar 2014, Ami Fischman wrote:
Looks like we're back in business:
Latest editor's draft:
http://dev.w3.org/2011/webrtc/editor/getusermedia.html
Thanks.
As a user, this scares me a lot. Why isn't it up to me to control this? I
don't
On 04/07/2014 06:20 PM, Ian Hickson wrote:
On Mon, 7 Apr 2014, Harald Alvestrand wrote:
On 04/02/2014 07:52 PM, Ian Hickson wrote:
On Mon, 3 Mar 2014, Ami Fischman wrote:
Looks like we're back in business:
Latest editor's draft:
http://dev.w3.org/2011/webrtc/editor/getusermedia.html
On 08/13/11 01:48, Darin Fisher wrote:
Putting implementation details aside, I agree that it is a bit unfortunate
to refer to a stream as a blob. So far, blobs have always referred to
static, fixed-size things.
This function was originally named createBlobURL, but it was renamed
Additional question:
What is the scenario in which this behavioiur is useful?
On 07/18/11 14:17, Tommy Widenflycht (ᛏᚮᛘᛘᚤ) wrote:
I am very confused regarding the below paragraph from the latest spec:
When a track in a
Not a comment directly on the spec, but you might want to check what
people are suggesting for interactive media handling in the WEBRTC
working group.
Streaming is different from interactive media, but it would be a shame
to have incompatibilities that can be avoided.
On 07/11/11 20:42,
On 05/31/11 23:45, Ian Hickson wrote:
On Sat, 9 Apr 2011, James Salsman wrote:
Sorry for the top posting, but I would like to reiterate my considered
opinion that Speex be supported for recording. It is the standard
format available from Adobe Flash recording, low bandwidth, open source
On 03/31/11 14:53, Bob Gezelter wrote:
Jonathan,
The WebSocket protocol currently presumes TCP as the underlying
transport.
TCP connections are an uninterrupted stream. If a packet is lost, the
connection will be aborted.
I do not believe that the TCP dependency is truly necessary or
On 04/28/11 20:55, Stefan Håkansson LK wrote:
Wouldn't it be possible to abstract this away for the web developer? I.e. the
send method should, like for WebSockets, not have a max size. Instead the
sending UA would be responsible for chopping up (the receiving UA for
re-assembling) the
On 04/26/2011 09:16 AM, Harald Alvestrand wrote:
On 04/26/11 00:27, Ian Hickson wrote:
On Fri, 22 Apr 2011, Harald Alvestrand wrote:
On 04/22/11 00:27, Ian Hickson wrote:
What is HTTP-in-SDP?
I misquoted - you said Currently, the HTML spec includes instructions
on how to identify
On 04/24/11 11:34, Stefan Håkansson LK wrote:
On Fri, 22 Apr 2011, Ian Hickson wrote:
On Mon, 11 Apr 2011, Justin Uberti wrote:
On Mon, Apr 11, 2011 at 7:09 PM, Ian Hicksoni...@hixie.ch wrote:
This has made UDP packets larger than the MTU pretty useless.
So I guess the question is do we
On 04/26/11 00:27, Ian Hickson wrote:
On Fri, 22 Apr 2011, Harald Alvestrand wrote:
On 04/22/11 00:27, Ian Hickson wrote:
What is HTTP-in-SDP?
I misquoted - you said Currently, the HTML spec includes instructions
on how to identify the stream in SDP - I was asking for chapter and
verse
On 04/22/11 00:27, Ian Hickson wrote:
and procedures for identifying the stream in SDP (if we continue to
use SDP) - I believe SDP implicitly assumes that all the streams it
describes are RTP streams.
That doesn't seem to be the case, but I could be misinterpreting SDP.
Since Ian seems to prefer to jumble all threads on a given group of
issues together in one message, I'll attempt to use the same format this
time.
On 04/12/11 04:09, Ian Hickson wrote:
On Tue, 29 Mar 2011, Harald Alvestrand wrote:
A lot of firewalls (including Google's, I believe) drop
On 04/08/11 18:51, Glenn Maynard wrote:
On Fri, Apr 8, 2011 at 4:41 AM, Harald Alvestrand
har...@alvestrand.no mailto:har...@alvestrand.no wrote:
My alternate proposal:
--
The initialization string looks like
On 04/13/11 13:35, Stefan Håkansson LK wrote:
-Original Message-
From: Ian Hickson [mailto:i...@hixie.ch]
Sent: den 12 april 2011 04:09
To: whatwg
Subject: [whatwg] PeerConnection feedback
On Tue, 29 Mar 2011, Stefan H kansson LK wrote:
The web application must be able to define the
Adding this to the public archive:
The current (April 8) version of section 9.4 says that the config string
for a PeerConnection object is this:
---
The allowed formats for this string are:
TYPE 203.0.113.2:3478
Indicates a specific IP address and port for the server.
On 03/29/11 03:00, Ian Hickson wrote:
It is stated that the data size can be up to 65467 bytes in send().
Our network guys tell us that this is unrealistic to get over such big
chunks using UDP.
Is that true? I thought they'd just get fragmented at the IP level, but
would still make it
On 03/29/11 03:00, Ian Hickson wrote:
On Wed, 23 Mar 2011, Harald Alvestrand wrote:
Is there really an advantage to not using SRTP and reusing the RTP
format for the data messages?
Could you elaborate on how (S)RTP would be used for this? I'm all in
favour of defering as much
I also believe that the recording interface should be removed from this
part of the specification; there should be no requirement that all
streams be recordable.
Recording of streams is needed for some use cases unrelated to video
conferencing, such as recording messages.
Having a
On 03/25/11 15:25, Satish Sampath wrote:
I agree that the WHATWG draft looks clearer at first glance. Having
two different proposals of such similar nature requires everyone
interested in them to read and digest before figuring out how they
differ specifically. And there would be differences in
.. but I digress.)
Or I may misunderstand the scenario you're talking about.
On Wed, Mar 23, 2011 at 5:13 PM, Matthew Kaufmanmatt...@matthew.at wrote:
On 3/23/2011 3:17 PM, Harald Alvestrand wrote:
I also fail to see the requirement for the masking, given that the
requirement for ICE (at least
On 03/24/11 07:14, Ian Hickson wrote:
On Wed, 23 Mar 2011, Julien Chaffraix wrote:
the EventSource specification states the current content-type header
should match the string text/event-stream. However following some
bugs opened inside the WebKit project [1], we relaxed the content-type
check
The proposal that I have put together, which is not detailed to the same
level as the PeerConnection API, is here:
https://docs.google.com/a/google.com/document/pub?id=1_lFKBgjNMVy98TMZT0kZ67RD57j1aL7ldPzv5zcJpgw
Note: It does NOT contain functions for camera/microphone access; I'm
happy to
On 03/24/11 20:45, Harald Alvestrand wrote:
Of course it turned out that I had overlooked a corporate security
policy. While I can share a document to individual accounts, I can't
publish it for everyone to look at.
The document is attached.
But the mailing list did not like the size
Is there really an advantage to not using SRTP and reusing the RTP
format for the data messages?
This is a well-known and well-analyzed encryption format, with
reasonably known security properties and library support (from libraries
that already have to be included in order to support
On 03/18/11 21:19, Glenn Maynard wrote:
On Thu, Mar 17, 2011 at 9:28 PM, Adam Barthw...@adambarth.com wrote:
So, the salt and the nonce play different roles. The salt is to make
sure the message appears random if you haven't read the spec (and so
don't know the salt). The nonce is to
On 03/23/11 23:43, Ian Hickson wrote:
On Wed, 23 Mar 2011, Harald Alvestrand wrote:
On 03/18/11 21:19, Glenn Maynard wrote:
On Thu, Mar 17, 2011 at 9:28 PM, Adam Barthw...@adambarth.com wrote:
So, the salt and the nonce play different roles. The salt is to make
sure the message appears
Up front statement, orthogonal to the details of the specification:
I've discussed this interface somewhat with Ian before in private, and
don't agree with his approach on several points - both technical and
organizational.
I also don't believe that quick iteration and rapid prototyping is
On 02/17/11 10:30, Jörn Zaefferer wrote:
Hi,
here at SoundCloud we're interested in an API for recording in the browser
( http://blog.soundcloud.com/2010/12/01/record/ ), without Flash and even on
mobile browsers. The get things moving with the current idea of a device API
(
On 02/28/11 15:35, Bjartur Thorlacius wrote:
On 2/28/11, Harald Alvestrandhar...@alvestrand.no wrote:
- Let users control access to microphone (whether my app can reach it or
not)
- Let users turn off and on their microphone
Seems to be out of HTML's scope.
I would very much want to avoid
On 02/28/11 15:55, Bjartur Thorlacius wrote:
On 2/28/11, Harald Alvestrandhar...@alvestrand.no wrote:
On 02/28/11 15:35, Bjartur Thorlacius wrote:
In effect, you want to create pipelines in JS/ES?
I need pipelines that can be manipulated from Javascript, yes.
Javascript is not a
On 02/28/11 16:10, Bjartur Thorlacius wrote:
On 2/28/11, Harald Alvestrandhar...@alvestrand.no wrote:
On 02/28/11 15:55, Bjartur Thorlacius wrote:
On 2/28/11, Harald Alvestrandhar...@alvestrand.no wrote:
On 02/28/11 15:35, Bjartur Thorlacius wrote:
In effect, you want to create pipelines
I went through exactly the same exercise some days ago.
It turns out that the perfectly clear specification is the
specification of the Javascript runtime environment, not in the
particular API specification.
obTangentEven in that case, I would prefer to see a separate open
call. It's just
Thank you Patrik, I enjoyed reading that!
Questions:
- In your experimentation, did you find any reasonable underlying
protocol to map sendFile, sendBitmap and their corresponding callbacks
to, or did you just ignore them for now?
- In connecting, did you operate with connections going via a
34 matches
Mail list logo
