Comments (6)
Related issue: #751
from webrtc-stats.
Not sure if we are consistent with RFC though since we made it so that "bytesSent includes RTX" and the RTX could be sent over a separate SSRC if separate RTX stream is supported.
from webrtc-stats.
There is some confusion here about whether or not probes need/should be included. I suspect they should be included on both send and receive side - but I'm not sure what we do today. @fippo can you help break down the current state of things?
Edit: Especially what the state of the probes are as those seem to account for a large percentage of overall traffic
from webrtc-stats.
The overall definition of "this SSRC" should probably be "this SSRC and all the SSRCs related to it such as retransmissions or FEC" in a lot of places. This relationship is commonly defined via ssrc-group, not sure if JSEP in its "we don't need SSRCs" narrative actually solves that problem or not.
The spec seems fine apart from pointing out that "This includes retransmissions" for inbound-rtp which is easy to fix, I'll do a PR.
RTX probes (for which we don't have an actual spec definition, whoops) are a bit tricky. They look like retransmitted packets on the receiver (one can try to be smart but given the lack of a spec that is a bad idea). Which means they will get accounted for differently, on outbound-rtp they might get accounted for as padding (maybe, like padding probes).
This means that retransmittedPacketsReceived may be nonzero even when there is no packet loss. That is a bit asymmetric but ok and according to the definition.
from webrtc-stats.
If I may quote you @fippo running https://jsfiddle.net/fippo/hvpxf5L0/3/ with and without https://webrtc-review.googlesource.com/c/src/+/295260 which did modify inbound-rtp counters:
with this patch yields (--force-fieldtrials=WebRtcStatsReportIdl/Disabled/ helps)
SENT outbound-rtp p=58066 h=5980 packetsSent=98 retransmittedPacketsSent=0
SENT transport p=66422 h=undefined packetsSent=103 retransmittedPacketsSent=undefined
RECV inbound-rtp p=58066 h=5980 packetsReceived=98 retransmittedPacketsReceived=21
RECV transport p=66422 h=undefined packetsReceived=103 retransmittedPacketsReceived=undefinedwhile without it the following (from a different connection)
SENT outbound-rtp p=83872 h=3536 packetsSent=108 retransmittedPacketsSent=0
SENT transport p=89814 h=undefined packetsSent=112 retransmittedPacketsSent=undefined
RECV inbound-rtp p=78714 h=2536 packetsReceived=97 retransmittedPacketsReceived=undefined
RECV transport p=89814 h=undefined packetsReceived=112 retransmittedPacketsReceived=undefined
from webrtc-stats.
If I may quote you @fippo running https://jsfiddle.net/fippo/hvpxf5L0/3/
The fiddle demonstrates that after stopping a transceiver and waiting a bit for things to settle we should have roughly the same number of inbound-rtp packetsReceived as we have on outbound-rtp packetsSent.
from webrtc-stats.
Related Issues (20)
- Conformance criteria incompatible with standards-track HOT 7
- RTX and FEC stats are incomplete. HOT 12
- Should we flatten the hierarchy? HOT 5
- Change playoutdelay to jitterbuffertarget HOT 2
- RTCAudioSourceStats.audioLevel - what algorithm described in totalAudioEnergy? HOT 3
- Delete the obsolete section, "track" and "stream" stats - they don't exist anymore HOT 3
- Improve test coverage HOT 1
- add framesInput stats to rtcoutboundrtpstreamstats HOT 6
- Stats example uses confusing variable names
- Exposing audio interruption metrics to JavaScript
- Define a mechanism for setting the trigger duration for a video freeze
- Sender-side packetsReceived can be negative from garbage RRs HOT 1
- Change "Does not" to "must not"
- Make "not present" reference "map/exist"
- Is codec.sdpFmtpLine present when there is no fmtp line in the SDP? HOT 2
- Lifetime of outbound-rtp should start BEFORE first packet is sent HOT 3
- Should RTCRtptransceiver.stop() cause inbound-rtp stats to disappear?
- RTCCodecStats.clockRate - media sampling rate or the codec clock rate?
- RTCStats.timestamp - fingerprinting and since epoch
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from webrtc-stats.