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

Describe more precisely the handling of disabled tracks #199

Open
youennf opened this issue May 11, 2020 · 2 comments
Open

Describe more precisely the handling of disabled tracks #199

youennf opened this issue May 11, 2020 · 2 comments

Comments

@youennf
Copy link
Contributor

youennf commented May 11, 2020

The spec currently says:
If any Track within the MediaStream is muted or not enabled at any time, the UA will only record black frames or silence since that is the content produced by the Track.

While the intent is clear in terms of rendering of the generated data, it is not clear what the encoder should do. webrtc-pc states that one black video frame should be sent per second, given webrtc transmission might be lossy. No audio is sent at all.

It would be nice to describe what should be done more precisely for MediaRecorder. Given recording is not lossy, a single video black frame might be sufficient to record for instance.

@guest271314
Copy link

Is the expected result a "paused" MediaStreamTrack where the resulting video is a single "black frame" when enabled is set to false following start() no matter how long MediaRecorder records before dataavailable (Chromium 85, potentially due to mute event of MediaStreamTrack of kind "video" fired consistently at ~4 seconds), or the resulting video is a series of "black frames" (Firefox 78)?

@guest271314
Copy link

canvas.captureStream(0) and requestFrame() provide means to record either a single frame or multiple frames with enabled.false, depending on the use case, using the appropriate code.

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

3 participants