Additional space in the buffer

[lgrahl]

It would be useful to allow the user to request additional bytes to be prepended and appended for each frame, so adding a header/footer/nonce/whatever kind of additional data does not require to copy into a new ArrayBuffer which can be expensive and may require garbage collection.

This is useful for e.g. encryption modes with additional MACs and nonces that need to be transmitted.

Could look like:

createEncodedVideoStreams(optional EncodedVideoStreamsParameters)

dictionary EncodedVideoStreamsParameters {
  unsigned byteHeadroom = 0;
  unsigned byteLegroom = 0;
};

[fippo]

On a second thought I am not sure that it really buys us much. If you encrypt you'll have to copy the ciphertext (which is larger than the plaintext in many cases) into your new packet anyway unless webcrypto offers a way to do things in-place

[lgrahl]

In-place encryption can be done with tweetnacl and perhaps webcrypto can do it in the future, too. However, there are obviously use cases beyond double crypto that can make use of this, e.g. metadata.

[alvestrand]

In raw-videoframe-land, the tendency seems to be to declare the input object immutable and create a new buffer for the output object, given that any transform has to read from the input and write to the output (two memory accesses) anyway.
The videoframe object has a destroy() operation that declares its backing store freed; I wonder if it's possible to declare a destroyAndTakeOverAndTransform() operation that creates a new frame while doing an in-place operation on the buffer.

Seems hard.

[alvestrand]

On the assumption that we're going to update the spec to use EncodedVideoChunk from WebCodecs, I'm closing this issue here. Please reopen an issue in WebCodecs if this is still relevant.
(EncodedVideoChunk has its "data" member immutable.)