Closed henbos closed 9 months ago
TPAC decision: merge this PR and file follow-ups, I filed #107 and #108.
- deliveredFrames has a dependency on the sink. Does that mean it only counts while hooked up to a sink?
No, the deliveredFrames counter is already defined as "A frame is considered delivered if it either was delivered to a sink or would have been delivered to a sink, if one was connected." But the name is confusing. Should I file an issue to rename deliveredFrames to deliverableFrames? (That's what I called them in the underlying layers in my impl)
Can I merge and prepare follow-up PRs? I think that is easier than tweaking (want follow up PRs to be diffed against this and I don't know how if one can make PR chains)
Comments on this PR have now been resolved, or follow-up issues have been filed.
- If low light lowers totalFrames, when would totalFrames != deliveredFrames + discardedFrames? Might we make due with one less stat here?
Even if the camera produces less frames than getSettings().frameRate, such as due to low light, we would still expect totalFrames = deliveredFrames + discardedFrames. This is because the camera never produced those frames to begin with, so no frames were dropped.
The only reason totalFrames might be != deliveredFrames + discardedFrames is if the user agent drops frames for other reasons.
I'm eager to create follow-up PRs which would be easier to do after this merges, @jan-ivar do I have editors can integrate
permission?
This issue was mentioned in WEBRTCWG-2023-09-12 (Page 55)
Fixes #105
Preview | Diff