- From: Varun Singh via GitHub <sysbot+gh@w3.org>
- Date: Thu, 07 Dec 2017 22:27:17 +0000
- To: public-webrtc-logs@w3.org
> Yes and even if you could discard concealed samples from framesDecoded (ugh, sometimes we talk about samples and sometimes frames, but whatever) what if there are decoding errors or what if frames are discarded for other reasons. if there is a decoding error, the framesDecoded wont go up. Perhaps framesCorrupted would go up... Media-source API says: a corrupted frame may or may not be dropped, depending of the corruption and of the browser algorithm. so...? > Or what if there are frames/samples still being decoded, does the decoded counter increase before or after they are processed? decoded counter goes up after decoding is complete. while it is being decoded, the jitter buffer emitted counter would go up... > Frames received could be dropped without ever entering the jitter buffer. Things like this could cause nonzero "3-2" or "3-1". The receiver puts packets into the Jitter buffer not frames... at least most implementations I have worked with in the past... Can someone confirm? Typically, the marker bit in the RTP header indicates that it is last packet of the frame, if there are packets out-of-order, the jitter buffer is used to re-order and combine the packets in to frame. Some one needs to confirm, otherwise this opens up the question to when the following are the following counters updated: + framesReceived; + keyFramesReceived; + partialFramesLost; + fullFramesLost; + framesDropped; In my mind, most of the counters are updated when the frame is emitted from the jitter buffer. And the following are updated at the time of decoding: + framesCorrupted; + framesDecoded; -- GitHub Notification of comment by vr000m Please view or discuss this issue at https://github.com/w3c/webrtc-stats/pull/268#issuecomment-350113845 using your GitHub account
Received on Thursday, 7 December 2017 22:27:18 UTC