multistream handling

[fippo]

multistream handling

[ggarber]

+1 although we can still add a feature to those tracks saying "numberOfStreamsInSameConnection"

[fippo]

we have usingMultistream and maxStreams :-)

[fippo]

going to tackle this now that I have a use-case. Currently we create one database row of features for each peerconnection. extractTrack() searches for a kind of track and returns all stats related to that track.

This mainly affects the features around

['audio', 'video'].forEach(kind => {
    ['send', 'recv'].forEach(direction => {
        module.exports[kind + capitalize(direction)] = function(client, peerConnectionLog) {

Additionally we need to have a stream (composed of an audio+video track) duration. We need to do it both for incoming and outgoing features, e.g. if the local client does both screensharing and video on the same connection.

Instead of having one row per peerconnection, we'll have one row per peerconnection and remote stream. This will require changing existing queries in order to avoid taking things like the duration twice when there are two remote streams. Rows with an identical peerconnection id should not be counted twice in those queries.

This also raises some questions about the database design, whether the current duplication of page features into each peerconnection row is ok but... its convenient.

[fippo]

an additional thing to take into consideration: a stream may not be active all the time.
How does that

1. affect averages like bitrate (ignore 0s?)
2. duration -- it can not be calculated as last - first

[fippo]

wire protocol bump required: fippo/rtcstats#83
WIP here

[fippo]

note: this needs to be stream-based, not track-based.

[fippo]

this is now on the master branch.