Add QP statistics to video tracks about webrtc-stats HOT 7 CLOSED

Is there guidance on what low and high mean here?

from webrtc-stats.

It's well defined for VP8, H.264, VP9 and HEVC, I think. Not redefining it would seem to be a Good Thing.
(low means not very compressed, high means very compressed, if I remember right).

from webrtc-stats.

Yes, the CL states the value is between 1-127. which would important to add. I suppose there is sufficient information to guess what low and high means. A value in the 20s is better than in the 50s.

from webrtc-stats.

To make use of this, we need to know the video codec in use, reset it on codec change, and also ensure this is per-track since each track will have different QP (or even different codecs)..

I think it is a reasonable thing to feed back to the application.

from webrtc-stats.

Hm. I'm trying to work out how this hangs together.
Frames are counted in RTCMediaStreamTrackStats, and you have to divide the sum-of-QP by the number of frames to get the average QP value.

But the codec information (necessary to know what the QP value means) hangs off RTCCodecStats, which is linked to the codecId of the RTCRtpStreamStats. The linkage between the two is taht RTCMediaStreamTrackStats has a sequence of SSRCs that can be used to find the RTCRtpStreamStats involved.

Should we put the sum of QP values on the RTCRtpStreamStats, since that has a single codec? Should we then put the FramesReceived there too, so that if a MediaStreamTrack switches codecs mid-flight, the QP values can be counted sensibly for each codec?

from webrtc-stats.

Frames that are not decoded but received do not have a QP value, ergo, FramesDecoded would be more appropriate than Frames Received.

Frames may be received by the endpoint and not decoded, may occur when a new user joins and starts receiving an existing stream or a user that was not in the filmstrip starts speaking. The decoding depends if the first frame is a full reference or not.

I suppose this would not be an issue if a stream is paused and resumed by the sender?

from webrtc-stats.

Summarizing status:

• The basic approach makes sense. The question is where to place the counters.
• To interpret the number, we need to know the codec. That's only visible in RTCRtpStreamStats (via "codecId" that references an RTCCodecStats object).
• To get the average QP on reception, we need to know the number of decoded frames. At the moment, that's an RTCMediaStreamTrackStats value.

Suggestion:

• Add the proposed counters to RTCRtpStreamStats
• Add a FramesDecoded value to RTCRtpInboundStreamStats
• Add a FramesEncoded value to RTCRtpOutboundStreamStats

I think that should make the counters usable without too much tree-walking.
As long as RTCRtpStream remains 1:1 with RTCMediaStreamTrack, the counters should have the same value as those other counters, but that won't necessarily be true always - the big exception is simulcast, where there would be multiple RtpStreams all pointing to the same RTCMediaStreamTrack.

from webrtc-stats.