- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Wed, 21 Apr 2021 17:28:38 +0000
- To: public-webrtc-logs@w3.org
I haven't looked at the readInto proposal. In general, I would prefer we use move/neuter behavior here, instead of relying on garbage collection. This is true for encoded chunks as well as raw data. There might be cases where we could also potentially reuse a buffer (say decryption). The typical flow is: I read a frame F from encoder, I change the frame F, I write the frame F in the packetizer. After writing the frame F, the slimmer frame F is, the better. Similar to transferring the frame. > For the metadata you're seeking, is it important that the metadata be carried through decoding/encoding, such that a VideoFrame corresponding to an EncodedVideoChunk has all the same values? For the typical RTC metadata we want, we do not need to get it exposed past the decoder. We might in the future have metadata that would go from MediaStreamTrack to WebRTC transform through encoder (or vice versa on decoder side). That could be a separate bucket of metadata. -- GitHub Notification of comment by youennf Please view or discuss this issue at https://github.com/w3c/webrtc-encoded-transform/issues/99#issuecomment-824232580 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 21 April 2021 17:28:41 UTC