Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a blackFrames counter to MediaStreamTrackVideoStats #144

Open
guidou opened this issue May 28, 2024 · 7 comments
Open

Add a blackFrames counter to MediaStreamTrackVideoStats #144

guidou opened this issue May 28, 2024 · 7 comments

Comments

@guidou
Copy link

guidou commented May 28, 2024

VC applications currently detect black frames by inspecting the payload of each frame.
In some cases, the system can provide information that the frames are black due to a camera occlusion.
Exposing this via a stat would allow the application to implement the same functionality with lower resource usage.

cc @youennf @jan-ivar

@youennf
Copy link
Contributor

youennf commented May 30, 2024

In some cases, the system can provide information that the frames are black due to a camera occlusion.

If some OSes already expose that information, this seems ok to me.
The question we could discuss is whether a track should be muted instead in that case.

Another question is how web application would know whether the OS supports it or not.
One option would be to have the counter property be undefined for OSes that do not support this.
For OSes that expose that information, the counter property would be exposed with 0 as the default value.

@eladalon1983
Copy link
Member

eladalon1983 commented May 30, 2024

The question we could discuss is whether a track should be muted instead in that case.

I'd say that it's likely helpful to mute in this case (more efficient), *if* we ensure that the app can detect the reason.

@guidou
Copy link
Author

guidou commented May 30, 2024

If some OSes already expose that information, this seems ok to me. The question we could discuss is whether a track should be muted instead in that case.

Some OSes do for some machines. I think muting would be useful since that would give a signal to the application to stop using the less efficient frame inspection and look at the counter.

Another question is how web application would know whether the OS supports it or not. One option would be to have the counter property be undefined for OSes that do not support this. For OSes that expose that information, the counter property would be exposed with 0 as the default value.

That makes sense to me.

@eladalon1983
Copy link
Member

eladalon1983 commented May 30, 2024

I think muting would be useful since that would give a signal to the application to stop using the less efficient frame inspection and look at the counter.

Ideally, an app running on a UA that would mute in this case, would not even need to run the less efficient black-frame-detection at all. Maybe we should give the app the ability to detect that.

@guidou
Copy link
Author

guidou commented May 30, 2024

I think muting would be useful since that would give a signal to the application to stop using the less efficient frame inspection and look at the counter.

Ideally, an app running on a UA that would mute in this case, would not even need to run the less efficient black-frame-detection at all. Maybe we should give the app the ability to detect that.

Correct. @youennf 's idea of not exposing the counter on systems that don't support this would be a way to detect it.

@alvestrand
Copy link
Contributor

Are we sure a browser can always tell if the OS exposes this information or not?
Or might it be camera driver specific?

@guidou
Copy link
Author

guidou commented May 30, 2024

Are we sure a browser can always tell if the OS exposes this information or not? Or might it be camera driver specific?

I think we can expose that the OS can potentially expose this, but I guess it's camera/laptop/driver/somethingelse specific. So this is would not be a full substitute for applications detecting black frames, but a way to do it more efficiently (and perhaps more accurately) in some cases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants