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
As of #113, The Output EncodedVideoChunk algorithm specifies that parts of the output config are to be copied from the "active encoder config". But the spec doesn't guarantee that the "active encoder config" was actually used to encode the given output (as opposed to some earlier config).
One fix is to specify that videoEncoder.configure() must flush all pending outputs before applying the new configuration. This is a little heavy though - we don't really want to require UAs to flush in this way (even though chromium currently does). There are some scenarios where the pipeline may be fairly deep and the configuration change fairly small such that a flush is not required and inefficient. I think a flush may not actually be observable though (as the running the configure control message is not observable), so maybe it leaves implementers the option to pursue equivalent alternatives.
Another fix is just to write out in english (rather than in algorithm steps) how the emitted VideoDecoderConfig is to be populated.
The text was updated successfully, but these errors were encountered:
As of #113, The Output EncodedVideoChunk algorithm specifies that parts of the output config are to be copied from the "active encoder config". But the spec doesn't guarantee that the "active encoder config" was actually used to encode the given output (as opposed to some earlier config).
One fix is to specify that videoEncoder.configure() must flush all pending outputs before applying the new configuration. This is a little heavy though - we don't really want to require UAs to flush in this way (even though chromium currently does). There are some scenarios where the pipeline may be fairly deep and the configuration change fairly small such that a flush is not required and inefficient. I think a flush may not actually be observable though (as the running the configure control message is not observable), so maybe it leaves implementers the option to pursue equivalent alternatives.
Another fix is just to write out in english (rather than in algorithm steps) how the emitted VideoDecoderConfig is to be populated.
The text was updated successfully, but these errors were encountered: