Will calling VideoEncoder.configure trigger the next frame to be generated as a key frame?

[youennf]

As per https://w3c.github.io/webcodecs/#dom-videoencoder-configure, a new [[codec implementation]] is assigned, leading to a new internal encoder creation. This seems to indicate that the next frame to be encoded will be a key frame.

This does not go well with calling configure solely for changing the bitrate. I guess that either we should make it clear that calling configure should not always trigger a key frame, or there should be a way to update the bitrate out of configure (per frame level maybe).

[sandersdan]

My recollection is that the encoder is not required to emit a keyframe or a new VideoDecoderConfig.

Originally we discussed having two different kinds of configure() to account for this difference, but it wasn't clear that all encoders would be able to have the same behavior for all possible things we would want to be configurable.

We did end up with a second place to put configuration though, which is parameters passed to encode(). That seems to be where per-frame QP will be configured (#270).

Edit: Chrome's implementation doesn't (yet) have any optimizations for avoiding a full reconfiguration, so it's still worth being explicit about for interoperability reasons.

[youennf]

My recollection is that the encoder is not required to emit a keyframe or a new VideoDecoderConfig.

That is my understanding of the current spec as well.

We did end up with a second place to put configuration though, which is parameters passed to encode(). That seems to be where per-frame QP will be configured (#270).

This seems fine to me. Another possibility is to add a settable bitRate attribute (it would seem convenient to be able to get such values).

so it's still worth being explicit about for interoperability reasons.

Yes, I fear this might create interop issues if the spec is not explicit here. Also, web pages might start to account for that behavior as well and UAs might start to break things if they start doing optimizations.

Safari prototype is creating a new encoder as well at configure time, so a new key frame will be created. I would go for requiring a key frame after a configure call for simplicity and since it is matching implementations.

If a parameter can be changed without requiring a full reconfiguration, it should probably either go per frame or we should add specific APIs for these parameters.

[Djuffin]

In RTC scenarios It's very common to request a bitrate change quite frequently. Emitting a key frame after every configure() with bitrate adjustment would make webcodecs impractical for RTC.

[aboba]

Agree that automatically emitting a key frame after every configure() call is a bad idea.

[youennf]

Emitting a key frame after every configure() with bitrate adjustment would make webcodecs impractical for RTC.

Agreed, hence the idea to have an API to set the bitrate explicitly outside of configure if we decide to go there.

Agree that automatically emitting a key frame after every configure() call is a bad idea.

Why and in which case, except for identical parameters or bitrate/framerate only changes?

Full reconfiguration vs. encoder update is not simply a nice optimization that could be let to UA implementors. We need to get interoperability there and the spec should be explicit, at least with clear guidelines/expectations.

[dalecurtis]

We shouldn't require this, but implementations may need to insert one on some configuration changes.