Re: [whatwg] createObjectURL(stream) protocol issue
Imho conceptually streamed media is not the same as data from a file and thus should be separated. Specifically the code for the video tag for example now has to ask around what this URL actually points to before taking action. /Tommy On Thu, Aug 11, 2011 at 22:08, Ian Hickson i...@hixie.ch wrote: On Thu, 11 Aug 2011, Tommy Widenflycht (á~[~Oá~Z®á~[~Xá~[~Xá~Z¤) wrote: Would it be possible to give the associated URL for a mediastream to have its own protocol, for example mediastream:, instead of the proposed blob:? window . URL . createObjectURL(stream) Mints a Blob URL to refer to the given MediaStream. This would tremendously help the implementation. Could you elaborate? In what sense does it impact the implementation? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' -- Tommy Widenflycht, Senior Software Engineer Google Sweden AB, Kungsbron 2, SE-11122 Stockholm, Sweden Org. nr. 556656-6880 And yes, I have to include the above in every outgoing email according to EU law.
[whatwg] createObjectURL(stream) protocol issue
Would it be possible to give the associated URL for a mediastream to have its own protocol, for example mediastream:, instead of the proposed blob:? window . URL . createObjectURL(stream) Mints a Blob URL to refer to the given MediaStream. This would tremendously help the implementation. Thanks in advance, Tommy -- Tommy Widenflycht, Senior Software Engineer Google Sweden AB, Kungsbron 2, SE-11122 Stockholm, Sweden Org. nr. 556656-6880 And yes, I have to include the above in every outgoing email according to EU law.
Re: [whatwg] PeerConnection, MediaStream, getUserMedia(), and other feedback
On Tue, Jul 26, 2011 at 07:30, Ian Hickson i...@hixie.ch wrote: If you send two MediaStream objects constructed from the same LocalMediaStream over a PeerConnection there needs to be a way to separate them on the receiving side. What's the use case for sending the same feed twice? There's no proper use case as such but the spec allows this. I also think it is a bit unfortunate that we now have a 'label' property on the track objects that means something else than the 'label' property on MediaStream, perhaps 'description' would be a more suitable name for the former. In what sense do they mean different things? I don't understand the problem here. Can you elaborate? label on a MediaStream is a unique identifier, while the label on a MediaStreamTrack is just a description like Logitech Vision Pro, Line In or Built-in Mic. I too find this a bit odd. On Wed, 20 Jul 2011, Tommy Widenflycht (á~[~Oá~Z®á~[~Xá~[~Xá~Z¤) wrote: On Mon, Jul 18, 2011 at 20:38, Ian Hickson i...@hixie.ch wrote: On Mon, 18 Jul 2011, Tommy Widenflycht (á~[~Oá~Z®á~[~Xá~[~Xá~Z¤) wrote: I am very confused regarding the below paragraph from the latest spec: When a track in a MediaStream parent is disabled, any MediaStreamTrack objects corresponding to the tracks in any MediaStream objects that were created from parent are disassociated from any track, and must not be reused for tracks again. If a disabled track in a MediaStream parent is re-enabled, from the perspective of any MediaStream objects that were created from parent it is a new track and thus new MediaStreamTrack objects must be created for the tracks that correspond to the re-enabled track. After cloning a LocalMediaStream it looks like this: LocalMediaStream - MediaStream1 Track1(E) Track1(E) Track2(E) Track2(E) Track3(E) Track3(E) and as I interpret the spec it looks like this if Track1 in the LocalMediaStream is disabled: LocalMediaStream - MediaStream1 Track1(D) Track2(E) Track2(E) Track3(E) Track3(E) Correct so far (though I'd avoid the term cloning since it's not quite what's going on here -- the spec uses forking, which may be closer though is still not ideal). So Track1 disappears from the MediaStream1 object and doesn't come back even if Track1 in the LMS object is enabled: LocalMediaStream - MediaStream1 Track1(E) Track2(E) Track2(E) Track3(E) Track3(E) No, it'll create a new track object: LocalMediaStream - MediaStream1 Track1(E) Track4(E) Track2(E) Track2(E) Track3(E) Track3(E) This is specified in the sentence that starts If a disabled track in a MediaStream parent is re-enabled Thanks for the explanation. To me this sounds overly complicated, why not just make it so that an disable of a track will override the track settings for forked MediaStreams? I don't understand what you mean. How would that be different? If I may make an analogy to the real world: plumbing. Each fork of a MediaStream is a new joint in the pipe, my suggestion introduces a tap at each joint. No matter how you open and close the tap at the end (or middle); if any previous tap is closed there's nothing coming through. The spec currently removes and add the entire pipe after the changed joint. Also some follow-up questions regarding the new TrackLists: What should happen when a track fails? Should the entire stream fail, the MSTrack silently be removed or the MSTrack disassociated with the track (and thus becoming a do-nothing object)? What do you mean by fails? Yanking the USB cable to the camera for example. This should imho stop the MS, not just silently send black video. What should happen when a stream with two or more video tracks is associated to a video tag? Just render the first enabled one? Same as if you had a regular video file with multiple tracks. And that is? Sorry, this might be written down somewhere and I have missed it. /Tommy -- Tommy Widenflycht, Senior Software Engineer Google Sweden AB, Kungsbron 2, SE-11122 Stockholm, Sweden Org. nr. 556656-6880 And yes, I have to include the above in every outgoing email according to EU law.
Re: [whatwg] Enabling/disabling tracks in MediaStreams
Thanks for the explanation. To me this sounds overly complicated, why not just make it so that an disable of a track will override the track settings for forked MediaStreams? This will definitely simplify implementation, and confuse web developers less imho. MSTracks coming and going doesn't feel right. Especially since there are no callbacks/events that a MS changes. Also some follow-up questions regarding the new TrackLists: What should happen when a track fails? Should the entire stream fail, the MSTrack silently be removed or the MSTrack disassociated with the track (and thus becoming a do-nothing object)? What should happen when a stream with two or more video tracks is associated to a video tag? Just render the first enabled one? /Tommy On Mon, Jul 18, 2011 at 20:38, Ian Hickson i...@hixie.ch wrote: On Mon, 18 Jul 2011, Tommy Widenflycht (á~[~Oá~Z®á~[~Xá~[~Xá~Z¤) wrote: I am very confused regarding the below paragraph from the latest spec: When a track in a MediaStream parent is disabled, any MediaStreamTrack objects corresponding to the tracks in any MediaStream objects that were created from parent are disassociated from any track, and must not be reused for tracks again. If a disabled track in a MediaStream parent is re-enabled, from the perspective of any MediaStream objects that were created from parent it is a new track and thus new MediaStreamTrack objects must be created for the tracks that correspond to the re-enabled track. After cloning a LocalMediaStream it looks like this: LocalMediaStream - MediaStream1 Track1(E) Track1(E) Track2(E) Track2(E) Track3(E) Track3(E) and as I interpret the spec it looks like this if Track1 in the LocalMediaStream is disabled: LocalMediaStream - MediaStream1 Track1(D) Track2(E) Track2(E) Track3(E) Track3(E) Correct so far (though I'd avoid the term cloning since it's not quite what's going on here -- the spec uses forking, which may be closer though is still not ideal). So Track1 disappears from the MediaStream1 object and doesn't come back even if Track1 in the LMS object is enabled: LocalMediaStream - MediaStream1 Track1(E) Track2(E) Track2(E) Track3(E) Track3(E) No, it'll create a new track object: LocalMediaStream - MediaStream1 Track1(E) Track4(E) Track2(E) Track2(E) Track3(E) Track3(E) This is specified in the sentence that starts If a disabled track in a MediaStream parent is re-enabled If you could explain how you are interpreting the current text I would be happy to fix the problematic area to be clearer (it's not clear to me what's unclear at the moment). On Mon, 18 Jul 2011, Harald Alvestrand wrote: What is the scenario in which this behavioiur is useful? The muting feature exists in order to allow authors to mute outgoing video while leaving outgoing audio and while still having a local video montior. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' -- Tommy Widenflycht, Senior Software Engineer Google Sweden AB, Kungsbron 2, SE-11122 Stockholm, Sweden Org. nr. 556656-6880 And yes, I have to include the above in every outgoing email according to EU law.
[whatwg] Enabling/disabling tracks in MediaStreams
I am very confused regarding the below paragraph from the latest spec: When a track in a MediaStreamhttp://www.whatwg.org/specs/web-apps/current-work/multipage/video-conferencing-and-peer-to-peer-communication.html#mediastream parent is disabled, any MediaStreamTrackhttp://www.whatwg.org/specs/web-apps/current-work/multipage/video-conferencing-and-peer-to-peer-communication.html#mediastreamtrack objects corresponding to the tracks in any MediaStreamhttp://www.whatwg.org/specs/web-apps/current-work/multipage/video-conferencing-and-peer-to-peer-communication.html#mediastream objects that were created from parent are disassociated from any track, and must not be reused for tracks again. If a disabled track in a MediaStreamhttp://www.whatwg.org/specs/web-apps/current-work/multipage/video-conferencing-and-peer-to-peer-communication.html#mediastream parent is re-enabled, from the perspective of any MediaStreamhttp://www.whatwg.org/specs/web-apps/current-work/multipage/video-conferencing-and-peer-to-peer-communication.html#mediastream objects that were created from parent it is a new track and thus new MediaStreamTrackhttp://www.whatwg.org/specs/web-apps/current-work/multipage/video-conferencing-and-peer-to-peer-communication.html#mediastreamtrack objects must be created for the tracks that correspond to the re-enabled track. After cloning a LocalMediaStream it looks like this: LocalMediaStream - MediaStream1 Track1(E) Track1(E) Track2(E) Track2(E) Track3(E) Track3(E) and as I interpret the spec it looks like this if Track1 in the LocalMediaStream is disabled: LocalMediaStream - MediaStream1 Track1(D) Track2(E) Track2(E) Track3(E) Track3(E) So Track1 disappears from the MediaStream1 object and doesn't come back even if Track1 in the LMS object is enabled: LocalMediaStream - MediaStream1 Track1(E) Track2(E) Track2(E) Track3(E) Track3(E) And to get it back again has to create a new MediaStream object from the LMS: LocalMediaStream - MediaStream2 Track1(E) Track1(E) Track2(E) Track2(E) Track3(E) Track3(E) Is this interpretation correct? /Tommy -- Tommy Widenflycht, Senior Software Engineer Google Sweden AB, Kungsbron 2, SE-11122 Stockholm, Sweden Org. nr. 556656-6880 And yes, I have to include the above in every outgoing email according to EU law.
[whatwg] Muting MediaStreamTracks?
The latest version of the spec mentions muting in several places, for example: (Merely muted tracks are not removed, so the tracks do not change when the parent is finished.) But there are no mute operators in the idl definitions... How is the mute function supposed to work? /Tommy -- Tommy Widenflycht, Senior Software Engineer Google Sweden AB, Kungsbron 2, SE-11122 Stockholm, Sweden Org. nr. 556656-6880 And yes, I have to include the above in every outgoing email according to EU law.
Re: [whatwg] Nullable types and MediaStreams
Great work! /Tommy On Tue, Jun 14, 2011 at 09:05, Ian Hickson i...@hixie.ch wrote: On Tue, 14 Jun 2011, Per-Erik Brodin wrote: Cameron McCormack wrote: Per-Erik Brodin: The DOMString arguments 'options' and 'configuration' are never referred to as being null, and thus I think it is safe to assume that they will not be null and that the default conversion rules apply (http://dev.w3.org/2006/webapi/WebIDL/#es-DOMString). The callback arguments are all referred to as being null so I think it is safe to assume that they can be null. Interface types now *do not* include null as one of their values unless you make the type nullable explicitly. The HTML spec hasn’t been updated for this yet, though I have written a patch to do so: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10640 I am aware of that. What I mean is the conclusions you can draw from reading the spec text. I would expect the expected behavior to be the same after this change, right? Thanks to Cameron's fantastic work, this is fixed now, so there should no longer be a need for reading between the lines. Please let me know if it's still ambiguous, though. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' -- Tommy Widenflycht, Senior Software Engineer Google Sweden AB, Kungsbron 2, SE-11122 Stockholm, Sweden Org. nr. 556656-6880 And yes, I have to include the above in every outgoing email according to EU law.
[whatwg] Nullable types and MediaStreams
So, as WebIDL has been extended with a is nullable operator ( http://www.w3.org/TR/WebIDL/#idl-nullable-type) I wonder if the MediaStreams draft can make use of it, please? Especially navigator.getUserMedia(options, successCallback [, errorCallback ] ) and PeerConnection(configuration, signalingCallback). /Tommy -- Tommy Widenflycht, Senior Software Engineer Google Sweden AB, Kungsbron 2, SE-11122 Stockholm, Sweden Org. nr. 556656-6880 And yes, I have to include the above in every outgoing email according to EU law.
[whatwg] Media Stream API: What is the intended behaviour for undefined mandatory arguments?
Hi Ian and the rest of the list, We are having a bit of discussion regarding the correct behaviour when mandatory arguments are undefined, see this webkit bug for history: https://bugs.webkit.org/show_bug.cgi?id=60622 Could we have some clarification for the below cases, please: var u; var n = null; // Should throw since u is undefined or just abort? navigator.webkitGetUserMedia(audio, u); // Will not throw but will abort. navigator.webkitGetUserMedia(audio, n); // Should throw because we are expecting at least two arguments. navigator.webkitGetUserMedia(audio); Thanks in advance, Tommy -- Tommy Widenflycht, Senior Software Engineer Google Sweden AB, Kungsbron 2, SE-11122 Stockholm, Sweden Org. nr. 556656-6880 This email may be confidential or privileged. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it went to the wrong person. Thanks! And yes, I have to include this message in every outgoing email according to EU law.
Re: [whatwg] The PeerConnection onmessage function attribute
Yes, I have read that part but what confuses me is that in the link I
sent in my original email MessageEvent is defined as follows:
interface MessageEvent : Event {
readonly attribute any data;
readonly attribute DOMString origin;
readonly attribute DOMString lastEventId;
readonly attribute WindowProxy source;
readonly attribute MessagePortArray ports;
void initMessageEvent(in DOMString typeArg, in boolean canBubbleArg,
in boolean cancelableArg, in any dataArg, in DOMString originArg, in
DOMString lastEventIdArg, in WindowProxy sourceArg, in
MessagePortArray portsArg);
};
/Tommy
On Wed, May 11, 2011 at 22:38, Per-Erik Brodin
per-erik.bro...@ericsson.com wrote:
Hi Tommy,
On 2011-05-11 14:59 CEST, Tommy Widenflycht (ᛏᚮᛘᛘᚤ) wrote:
Hi gang,
What is the event type for the onmessage event handler? I might have
missed something but I can't find a suitable event for this one. A
MessageEvent is already defined by the Communication spec
(http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html).
/Tommy
See step 18 under When a packet that is part of a data UDP media stream
is received in
http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#the-data-stream
Create an event that uses the MessageEvent interface, with the name
message, which does not bubble, is not cancelable, has no default
action, and has a data attribute whose value is /message/, and queue a
task to dispatch the event at the PeerConnection object responsible for
this side of the data UDP media stream.
The event type is message and the interface is MessageEvent.
//Per-Erik
--
Tommy Widenflycht, Senior Software Engineer
Google Sweden AB, Kungsbron 2, SE-11122 Stockholm, Sweden
Org. nr. 556656-6880
This email may be confidential or privileged. If you received this
communication by mistake, please don't forward it to anyone else,
please erase all copies and attachments, and please let me know that
it went to the wrong person. Thanks!
And yes, I have to include this message in every outgoing email
according to EU law.
Re: [whatwg] The PeerConnection onmessage function attribute
Ahh, thanks! I thought it was an all or nothing kind of class. Have
now implemented the onmessage using the right event.
/Tommy
On Thu, May 12, 2011 at 11:18, Per-Erik Brodin
per-erik.bro...@ericsson.com wrote:
On 2011-05-12 09:38 CEST, Tommy Widenflycht (ᛏᚮᛘᛘᚤ) wrote:
Yes, I have read that part but what confuses me is that in the link I
sent in my original email MessageEvent is defined as follows:
interface MessageEvent : Event {
readonly attribute any data;
readonly attribute DOMString origin;
readonly attribute DOMString lastEventId;
readonly attribute WindowProxy source;
readonly attribute MessagePortArray ports;
void initMessageEvent(in DOMString typeArg, in boolean canBubbleArg,
in boolean cancelableArg, in any dataArg, in DOMString originArg, in
DOMString lastEventIdArg, in WindowProxy sourceArg, in
MessagePortArray portsArg);
};
Could you perhaps be more specific about what confuses you? MessageEvent is
used in several places. If you are referring to the various properties then
data is the only one used everywhere. For example, the lastEventId property
is only set on message events dispatched on an EventSource object.
//Per-Erik
--
Tommy Widenflycht, Senior Software Engineer
Google Sweden AB, Kungsbron 2, SE-11122 Stockholm, Sweden
Org. nr. 556656-6880
This email may be confidential or privileged. If you received this
communication by mistake, please don't forward it to anyone else,
please erase all copies and attachments, and please let me know that
it went to the wrong person. Thanks!
And yes, I have to include this message in every outgoing email
according to EU law.
