Re: [webrtc-stats] TimingInfo metrics (#704)

Yes, it's very useful.
It makes sense to create a new type for all of it, I agree. All these
numbers correspond to the same frame.

The GetStats reports the frame with the longest e2e time for the last
second, so that if polled at 1s interval, the worst frames would be
observed by the application.
The reports are attached to the frames because either timer or because the
frame is bigger than average.
The metrics are timestamps mostly:

   - RTP timestamp: obvious
   - Capture time: timestamp when this frame was captured
   - Encode start: timestamp when this frame started to be encoded
   - Encode finish: timestamp when this frame finished encoding
   - Packetization finish: timestamp when this frame was split into packets
   and was ready to be sent over the network
   - Pacer exit: timestamp when last packet of this frame was sent over the
   network by the sender at this timestamp
   - Network timestamp1/2: place for the SFU to mark when the frame
   started/finished being forwarded. Application specific.
   - Receive start: timestamp when the first packet of this frame was
   received
   - Receive finish: timestamp when the last packet of this frame was
   received
   - Decode start:  timestamp when the frame was passed to decoder
   - Decode finish:  timestamp when the frame was decoded
   - Render time:  timestamp of the projected render time for this frame
   - Boolean for "is outlier": this frame is bigger in encoded size than
   the average frame by at least 5x.
   - Boolean for "triggered by timer": this report was triggered by the
   timer (The report is sent every 200ms)

Because some timestamps are send-side and some are receive-side, a clock
synchronisation is performed by the browser. But before this happens,
First 7 timestamps (capture ... network2) would be reported as negative. In
that case, the app can't compare send-side and receive-side timestamps. But
it would still be fine to subtract timestamps from the same side.
If the capture time is non-negative, when all clocks are synchronised and
the app can subtract whatever it want to calculate e.g. end-to-end delay.

On Fri, Oct 7, 2022 at 1:23 PM henbos ***@***.***> wrote:

> I want things deemed "too useful to be dropped" to migrate into
> standardized getStats() so that we can delete legacy getStats(). My sense
> is that we're close to being able to unship it, but then stuff like this
> crops up.
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/w3c/webrtc-stats/issues/704#issuecomment-1271465833>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AF74EIY4JXL5NZWUZEXKIBDWCAB4LANCNFSM6AAAAAAQ7P4LKU>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>


-- 
Best regards,
Ilya


-- 
GitHub Notification of comment by ilyanikolaevskiy
Please view or discuss this issue at https://github.com/w3c/webrtc-stats/issues/704#issuecomment-1271487560 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 7 October 2022 11:46:47 UTC