AudioFrame/VideoFrame should be marked as serializable/transferable

[tguilbert-google]

This might be a duplicate issue, or already in a PR, but I'm opening this to make sure it isn't missed.

The Chrome implementation already supports this, but it is not called out in the spec.

[chcunningham]

Thanks for filing this. Agree, spec should change (it's straitforward once the ref-counting PRs land).

[chcunningham]

Triage note: marking extension, as these are add-on attributes/behaviors

[chcunningham]

Having said that, they are already implemented in Chrome, so we should firm up consensus on their semantics ASAP.

Fortunately, I think these are not controversial.

For those reading along, some background:

• postMessage() will serialize things by default, and transfer things that are mentioned in the transfer list.
• Transfer is generally a "move". "Transferring is effectively recreating the object while sharing a reference to the underlying data and then detaching the object being transferred."
• Serialize is generally a "copy". It used to be called "clone". I don't have a perfect quote like for transfer, but you can read the serialize steps for things like ArrayBuffer and find that the source buffer is not detached (i.e. not moved).

The chrome impl behaves in the following way:

• serializing is effectively a clone(). Serializing a frame creates a record of its "media resource" without detaching that frame's "resource reference". The deserialize operation will create a new VideoFrame/AudioData that points to this same "media resource".
• transferring the close()s the source frame, producing a new frame on the other end that refers to the same media resource while the original frame is now detached.

@padenot @aboba WDYT?

[padenot]

Yes, I think that's uncontroversial, but what API should be used? An old-school transfer list, or the new way of doing things? Also, this needs to be designed at the same time as #212, so that the ergonomics can be the best possible for memory management.

[dalecurtis]

EncodedAudioChunk and EncodedVideoChunk will also need to be serializable/transferable. Especially if we end up with worker only exposure.

[dalecurtis]

(The associated metadata pieces too)

[chcunningham]

EncodedAudioChunk and EncodedVideoChunk will also need to be serializable/transferable. Especially if we end up with worker only exposure.

Tracked in #289