-
Notifications
You must be signed in to change notification settings - Fork 115
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adding mediadiscarded event #29
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -10,11 +10,11 @@ | |
<meta content="text/html; charset=us-ascii" http-equiv="Content-Type"> | ||
<script class="remove" src="http://www.w3.org/Tools/respec/respec-w3c-common" | ||
type="text/javascript"> | ||
// // keep this comment // | ||
// // keep this comment // | ||
</script> | ||
<script class="remove" src="webrtc.js" type="text/javascript"> | ||
// // keep | ||
this comment // | ||
this comment // | ||
</script> | ||
</head> | ||
|
||
|
@@ -539,7 +539,7 @@ <h4>Operation</h4> | |
|
||
<p class="note">The creation of new incoming | ||
<code>MediaStream</code>s may be triggered either by SDP | ||
negotiation or by the receipt of media on a given flow. | ||
negotiation or by the receipt of media on a given flow. | ||
<!-- [[OPEN ISSUE: How many <code>MediaStream</code>s are created | ||
when you receive multiple conflicting pranswers?]] --></p> | ||
</li> | ||
|
@@ -1595,6 +1595,39 @@ <h3>Interface Definition</h3> | |
"#dom-peerconnection-ice-connection-state"><code>RTCPeerConnection</code> | ||
ice connection state</a> changes. | ||
</dd> | ||
|
||
<dt>attribute EventHandler ondiscardedmedia</dt> | ||
|
||
<dd> | ||
<p>This event handler, of event handler event | ||
type <code><a href="#event-discardedmedia">discardedmedia</a></code>, | ||
MUST be fired by all objects implementing the | ||
<code><a>RTCPeerConnection</a></code> interface. It is fired when | ||
inbound media is discarded.</p> | ||
|
||
<p>Media can be discarded by <code><a>RTCPeerConnection</a></code> | ||
for a number of reasons. Media packets that arrive from an answerer. | ||
Media packets that are successfully authenticated but can't be | ||
attributed to a <code>MediaStreamTrack</code>, can't be decoded, or | ||
have any other error also cause this event to fire. Unauthenticated | ||
packets are always silently discarded.</p> | ||
|
||
<p>Media packets for an SSRC that has been recently discarded SHOULD | ||
be discarded without generating | ||
a <code><a href="#event-discardedmedia">discardedmedia</a></code> | ||
event. This event MAY be suppressed entirely if the <a>user | ||
agent</a> determines that too many events of this type are being | ||
generated.</p> | ||
|
||
<p class="note">This event might be delayed while there is an | ||
outstanding offer (i.e., in a <a href= | ||
"#dom-peerconnection-signaling-state"><code>signalingState</code></a> | ||
of <code>have-local-offer</code> | ||
or <code>have-remote-pranswer</code>), since packets corresponding | ||
to an answer might arrive prior to the answer that describes them. | ||
In these states, unknown media might be buffered temporarily to | ||
allow time for an answer to arrive.</p> | ||
</dd> | ||
</dl> | ||
</section> | ||
|
||
|
@@ -1891,6 +1924,46 @@ <h4>RTCSdpError</h4> | |
</ul> | ||
</div> | ||
</section> | ||
|
||
<section> | ||
<h4>RTCMediaDiscardedEvent</h4> | ||
|
||
<p>The <code>mediadiscarded</code> event of the <code>RTCPeerConnection</code> uses | ||
the <code><a>RTCMediaDiscardedEvent</a></code> interface.</p> | ||
|
||
<p><dfn title="Fire a media discarded event">Firing an | ||
<code><a>RTCMediaDiscardedEvent</a></code> event named | ||
<var>e</var></dfn> means that an event with the name <var>e</var>, | ||
which does not bubble (except where otherwise stated) and is not | ||
cancelable (except where otherwise stated), and which uses the | ||
<code>RTCMediaDiscardedEvent</code> interface MUST be created and | ||
dispatched at the given target.</p> | ||
|
||
<dl class="idl" data-merge="RTCMediaDiscardedEventInit" | ||
title="interface RTCMediaDiscardedEvent : Event"> | ||
<dt>Constructor(DOMString type, RTCMediaDiscardedEventInit | ||
eventInitDict)</dt> | ||
|
||
<dt>readonly attribute unsigned long ssrc</dt> | ||
<dd>The Synchronization source (SSRC) number of the packet.</dd> | ||
|
||
<dt>readonly attribute unsigned byte payloadType</dt> | ||
<dd>The RTP payload type of the packet.</dd> | ||
|
||
<dt>readonly attribute DOMString? mid</dt> | ||
<dd>The value of any mid header extension on the discarded media | ||
packet, if that header is present.</dd> | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Since text above says that this is not fired once for every packet, what are the rules for multi-packet notifications? Do they contain data from the first packet? An exemplar packet picked at random? An aggregation of discarded packets? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We have a proposal for discardedPackets in stats, which is described as packets that arrived early or late and are discarded by the dejitter buffer, however in this case it would be because it cannot assign it to the correct dejitter buffer. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
This is written as though the first packet generates the event and subsequent packets (with the same SSRC) are simply discarded. I think that is correct. I imagine that the browser could add more information about the stream if the first packet had no header extension and later ones did, but I'm happy to leave that out from a requirement perspective. |
||
</dl> | ||
|
||
<dl class="idl" title="dictionary RTCMediaDiscardedEventInit : EventInit"> | ||
<dt>unsigned long ssrc</dt> | ||
<dd>See <a><code>RTCMediaDiscardedEvent.ssrc</code></a></dd> | ||
<dt>unsigned byte payloadType</dt> | ||
<dd>See <a><code>RTCMediaDiscardedEvent.payloadType</code></a></dd> | ||
<dt>DOMString mid</dt> | ||
<dd>See <a><code>RTCMediaDiscardedEvent.mid</code></a></dd> | ||
</dl> | ||
</section> | ||
</section> | ||
|
||
<section> | ||
|
@@ -4993,6 +5066,17 @@ <h2>Event summary</h2> | |
the script when an IdP encounters an error while validating an | ||
identity assertion.</td> | ||
</tr> | ||
|
||
<tr> | ||
<td><dfn id= | ||
"event-discardedmedia"><code>discardedmedia</code></dfn></td> | ||
|
||
<td><code><a>RTCMediaDiscardedEvent</a></code></td> | ||
|
||
<td> | ||
Unhandled media was discarded. | ||
</td> | ||
</tr> | ||
</tbody> | ||
</table> | ||
|
||
|
@@ -5072,6 +5156,7 @@ <h3>Changes since June 4, 2014</h3> | |
|
||
<ol> | ||
<li>Bug 25724: Allow garbage collection of closed PeerConnections</li> | ||
<li>Bug 21877: Adding mediadiscarded event</li> | ||
</ol> | ||
|
||
<h3>Changes since April 10, 2014</h3> | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we not spec this out? Either that no event is fired if there is an expected answer coming, or that it is delayed for up to x seconds or something.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#39 opened