- From: Cullen Jennings <fluffy@iii.ca>
- Date: Mon, 23 Jan 2012 17:55:50 -0800
- To: Aleksandr Avseyev <alexn74@gmail.com>
- Cc: public-webrtc@w3.org
On Jan 23, 2012, at 15:21 , Aleksandr Avseyev wrote: > I wonder if anybody else mentioned to add metrics "fps" and "frames dropped". They're very useful for video quality monitors. They may require low level access to codec though. Agree these types of things can be useful. Lets talk about the error we have in video for a second. If you loose a packet, it will probably just corrupt a small part of a single frame but the bulk of the frame will still be ok. But sometimes that packet will cause the whole frame to fail and other times it may cause several other frames to fail as well. The RTP stack typically can't figure out which of these three cases it is but instead needs to pass it to the video decoder which will know. But in many cases, the video decoder is in hardware on the graphics card. In my mind, the right thing to report is probably the totalNumberOfFrameElapsed totalNumberOfPartiallyCorruptedFrames totalNumberOfFullyCorruptedFrames For the stream to report these, it will probably have to rely on the video decoder to feed this data back to the stream object. From that we can compute fps and such. This make any sense ?
Received on Tuesday, 24 January 2012 13:13:52 UTC