We would need the following info for exposing the RTP packetization for each frame:

dictionary RTCRTPFragment{
    attribute Buffer prefix;
    attribute ArrayBufferView payload; //Containing the correct fragment of the video frame payload
    attribute Buffer suffix;
}

partial interface RTCEncodedVideoFrame {
    attribute sequence<RTCRTPFragment> payload;
}

Note that the RTP packetization may require to prepend some RTP header stuff in each packet (nal headers in h264, vp8 picture headers) and may skip some data on the payload (the nal headers in h264, for example). I am not aware of any packetization that requires appending data at the end, but may be worthy.

Encrypting could be straight forward, as it could just put all the encrypted buffer as the prefix or sufix and skip the payload completely.

What is a bit more complex is in decryption, because as it is happening before the depacketization, we don't have a assembled video frame, and we would need to pass the raw RTPpacket instead (either just the payloads, or the full rtp packet info)

I like the idea of a prefix, which could also be used to address the A/V/data sync issue. You might want to make clear that the browser is expected to take care of RTP header/extension formatting (e.g. things like setting the Marker bit). The size of header extensions can vary with each packet, so that the available payload size needs to be provided for each packet.

Closing this as OBE in this context, given that TPAC 2023 discussions favored developing a separate spec for RTPTransport, which would define a packet level interface as one of its work products.