W3C home > Mailing lists > Public > public-webrtc@w3.org > October 2016

[webrtc-pc] How to properly manage TrackEvent or privide the current AddStreamEvent?

From: Miguel París via GitHub <sysbot+gh@w3.org>
Date: Thu, 20 Oct 2016 09:11:28 +0000
To: public-webrtc@w3.org
Message-ID: <issues.opened-184174712-1476954687-sysbot+gh@w3.org>
mparis has just created a new issue for 

== How to properly manage TrackEvent or privide the current 
AddStreamEvent? ==
analysing the usage of TrackEvent I think that it is not easy.
The point is that at the end developers need to use MediaStream 
objects to render the media in a VideoTag, and typically some 
MediaStreamTracks are included in the same MediaStream.
Taking this into account, with the current API developers have to deal
 with the next problem:

- Know if the MediaStream associated to the track received in the 
onTrack handler has been already rendered (because it is the same that
 the MediaStream associated to a previous track received in the 
onTrack). For example, if mediaStream has 2 MediaStreamTrack (audio 
and video) it will be set twice.

pc.ontrack = function (evt) {
    mediaStream = evt.streams[0];
    remoteView.srcObject = mediaStream;

This is a simple case, but the developers can also know which 
MediaStreamTracks are into the MediaStreams to apply a more complex 
logic (for example: only render some of them, split them in different 
MediaStreams, etc.)
In that cases they typically would have to store all 
MediaStreamTracks/MediaStream received in the  onTrack handler and 
wait until the setRemoteDescription returns to perform the logic.

Taking this difficulties into account:

- Should we provide an AddStreamEvent and a onAddStream handler as the
 current implementations?
- Should we provide some examples (or even utilities) to show how to 
manage this kind of cases?

Best regards!!

Please view or discuss this issue at 
https://github.com/w3c/webrtc-pc/issues/876 using your GitHub account
Received on Thursday, 20 October 2016 09:11:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:20 UTC