You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
MediaStreamTrackGenerator does not specifiy any limits as to the speed at which data can be fed in. This can lead to problems if developers push 60s worth of audio data in 1s (see crbug.com/1184070).
There should be a note in the spec mentioning that developers are expected to feed tracks at a reasonable real-time rate.
The text was updated successfully, but these errors were encountered:
This issue is still ripe. A note should be a sooner rather than later. An author of the WebCodecs specification author filed a Chromium bug due to the expectation that a MediaStreamTrackGenerator in a MediaStream set as srcObject of an <audio> element could be written to in a synchronous for loop without delay between calls and the audio would be output at the element at the same pace as delaying writes between calls to write()https://bugs.chromium.org/p/chromium/issues/detail?id=1260519.
the input to the MSTG is a Stream. I would suggest that the note should say that the client of MSTG (or now: VideoTrackGenerator) needs to respect the high water mark of the stream, otherwise frames may be lost, and that one should expect the MSTG to process frames at a rate no slower than real time, but not much faster either.
MediaStreamTrackGenerator does not specifiy any limits as to the speed at which data can be fed in. This can lead to problems if developers push 60s worth of audio data in 1s (see crbug.com/1184070).
There should be a note in the spec mentioning that developers are expected to feed tracks at a reasonable real-time rate.
The text was updated successfully, but these errors were encountered: