Time to decoded frame: The calculation methodology for was incorrect. The way it was being measured would not give an accurate representation of the actual time taken to decode the first received frame. The application current uses inbound-stats to measure this value and these stats are polled every 1 second, which means, there is a possibility that the time calculated is 1 second more than what it actually took to decode the first frame. This PR fixes it by listening in on the [onloadeddata](https://www.w3schools.com/jsref/event_onloadeddata.asp) event tied to the master video element which is invoked when the first frame is received.
Time to P2P: The calculation for this is from the start of viewer button click to when the first track event is received. This is not a real measure of P2P, or atleast it is not clear what the intent of this is. This PR gets rid of this and instead adds 3 more metrics: Time taken for signaling setup, Time to set up viewer video view element and time taken from offer to first frame decode.
Time from viewer button click to first frame decode: Added a new measure to indicate the total time taken to get the remote view on the screen.
Selected candidate pair: Added details on the selected local and remote candidate which will show up after 10 seconds.
Modified time unit to ms display for latency measurements to be accurate.
Before this change:
Initial view:
After 120 seconds:
After this PR:
Initial view:
After 10 seconds:
Note from the screenshot how there is a 931ms difference between Time to decoded stream (as seen from inbound stats) and Time from viewer button click to first decoded frame.
To do:
Debug why prflx candidate information is empty.
Firefox doesnt display local candidate details.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
Issue #, if available:
Description of changes:
Time to decoded frame: The calculation methodology for was incorrect. The way it was being measured would not give an accurate representation of the actual time taken to decode the first received frame. The application current uses
inbound-statsto measure this value and these stats are polled every 1 second, which means, there is a possibility that the time calculated is 1 second more than what it actually took to decode the first frame. This PR fixes it by listening in on the[onloadeddata](https://www.w3schools.com/jsref/event_onloadeddata.asp)event tied to the master video element which is invoked when the first frame is received.Time to P2P: The calculation for this is from the start of viewer button click to when the first
trackevent is received. This is not a real measure of P2P, or atleast it is not clear what the intent of this is. This PR gets rid of this and instead adds 3 more metrics: Time taken for signaling setup, Time to set up viewer video view element and time taken from offer to first frame decode.Time from viewer button click to first frame decode: Added a new measure to indicate the total time taken to get the remote view on the screen.
Selected candidate pair: Added details on the selected local and remote candidate which will show up after 10 seconds.
Modified time unit to ms display for latency measurements to be accurate. Before this change:
Initial view:
After 120 seconds:
After this PR:
Initial view:
After 10 seconds:
Note from the screenshot how there is a 931ms difference between
Time to decoded stream (as seen from inbound stats)andTime from viewer button click to first decoded frame.To do:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.