I think this needs some discussion around what can happen why, and what we need to report.

List discussion needed.

What do people think of "one notification per SSRC " ?

I'd be OK with that, or maybe "at most one notification per SSRC". There are lots of SSRCs and I don't want to be obligated to report on all of them.

Good point, don't want to be DOS'd by ssrc, but on the other hand I'd be sad if I got 3 different SSRC and only got notified about one of them. In the early media case, this notification might trigger the JS app to decide which provisions answer to push into setRemote as different media arrives.

RFC7002 defines a metric for packets that are discarded by the jitter/playout buffer, either due to early or late arrival. The early packets in this case occur when the timestamp of the packets are too far in the future compared to current playout and therefore discarded. Consequently, the late ones are those with timestamp in the past compared to the current playout timestamp.

I suppose these packets should not trigger the onmediadiscarded in these cases?

On 04/06/2015 09:27 PM, Varun Singh wrote:

RFC7002 defines a metric for packets that are discarded by the
jitter/playout buffer, either due to early or late arrival. The early
packets in this case occur when the timestamp of the packets are too
far in the future compared to current playout and therefore discarded.
Consequently, the late packers are packets whose timestamp are in the
past compared to the current playout timestamp.

I suppose these packets should not trigger the |onmediadiscarded| in
these cases?

—
Reply to this email directly or view it on GitHub
#29 (comment).

I would say that "mediadiscarded" should happen when you discard an
entire RTP encoded stream (= ssrc), not when you discard a packet from a
stream.

"mediastreamdiscarded" might be a better name.

Surveillance is pervasive. Go Dark.

Yes, mediastreamdiscarded aligns better with the intention.

I would also like to weigh in on getting at most a notification per SSRC. Additionally, getting the number of packets discarded before playback started via the statsAPI.

Per discussion in Dallas: We really need to separate the cases of "hey - stuff arrived that we can't associate with any configured track" and "data has been thrown away, we thought you might like to know".

Mozilla has working code that, on the first instance, is able to configure a track that will take the incoming packets and do something sensible with them. Calling the event that triggers that handling "mediadiscarded" just seems wrong.

Martin will write a new proposal.

@alvestrand could you elaborate a bit more about the difference between "hey - stuff arrived that we can't associate with any configured track" and "data has been thrown away, we thought you might like to know"? (I was not in Dallas). The original discussion concluded (if memory serves) that if stuff arrives that can't be associated with a track it would be dropped on the floor - which means the two cases are the same. Apparently this was advanced a bit in Dallas.

The Dallas conversation included a claim by @martinthomson (I think) that he had examples of applications where data would arrive on a previously unconfigured SSRC, the signal went up to Javascript, and the signal contained enough information that the Javascript could modify the SDP, do a setLocalDescription (or setRemoteDescription or both?), get an addtrack event, and receive the incoming packet on the newly configured track.
Calling the signal that caused this to happen "mediadiscarded" seemed disingenious, since in fact media is not discarded at all.
Of course we can't guarantee that the javascript would be able and willing to do that, and the media subsystem can't hang on to an infinity of incoming packets forever, so there has to be some signal that says that media has really been discarded.

That's what I remember of the conversation.

Then I understand better. But it feels like a timing thing then. Say a "new unknown media" event is fired, if the JS does not apply a new SDP that takes care of it a "mediadiscarded" event should be fired after a while (which should be defined).

Anyway, this PR does not address "unknown media". I'll take this to the list.

Closing this PR. Solving the problem will require new PRs.