- From: Bernard Aboba <Bernard.Aboba@microsoft.com>
- Date: Tue, 10 Aug 2021 14:03:49 +0000
- To: youenn <youenn@apple.com>, "sergio.garcia.murillo@cosmosoftware.io" <sergio.garcia.murillo@cosmosoftware.io>
- CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
- Message-ID: <PH0PR00MB0997C6591FCD928D4589531CECF79@PH0PR00MB0997.namprd00.prod.outlook.com>
"Bernard, please correct me if I am wrong, my understanding of the current situation at IETF is that: - There is consensus for SFrame as a binary format. - There is consensus on how to apply SFrame to audio content over RTP. - There is no consensus on how to apply SFrame to video content over RTP." [BA] At IETF 110 AVTCORE meeting, there were objections to the idea of a generic packetizer of encrypted frames transported over RTP. The objectors felt that existing packetizations might have advantages (e.g. allowing slices to be decoded). Because most of the objections used video examples, I suspect that these objections related more to video than audio, but I can't say for sure. At IETF 111 AVTCORE meeting, Sergio presented an alternative to SFrame (SPacket). In this approach, encryption is done after packetization, not before. So this allows the existing packetization to be retained, although overhead is increased. However, since the original objectors to SFrame weren't present at the meeting, it is hard to say whether SPacket addressed their objections or not. So now there are two proposals for the transport format over RTP. It is a bit confusing because so far there is only one implemented transport for SFrame (RTP) and in that transport, it is not clear whether there is consensus for it. With respect to the statements above, given the lack of a consensus call on those issues, I don't think we can draw a conclusion. The first topic (SFrame format) is on the agenda for discussion at the SFRame interim so I suspect there are issues that still need to be resolved. If you have ideas on how to move things along within IETF, it might be good for you to post them there. For example, getting a reading on the consensus questions you pose above might be helpful in clarifying things. ________________________________ From: Youenn Fablet <youenn@apple.com> Sent: Tuesday, August 10, 2021 2:59 AM To: Bernard Aboba <Bernard.Aboba@microsoft.com>; Sergio Garcia Murillo <sergio.garcia.murillo@cosmosoftware.io> Cc: public-webrtc@w3.org <public-webrtc@w3.org> Subject: [EXTERNAL] Re: Call for Consensus (CfC): WebRTC Encoded Transform as a WG Draft +Sergio with whom we worked on the presentation of SFrame and SPacket at last AVTCore meeting. Bernard, please correct me if I am wrong, my understanding of the current situation at IETF is that: - There is consensus for SFrame as a binary format. - There is consensus on how to apply SFrame to audio content over RTP. - There is no consensus on how to apply SFrame to video content over RTP. On 10 Aug 2021, at 00:23, Bernard Aboba <Bernard.Aboba@microsoft.com<mailto:Bernard.Aboba@microsoft.com>> wrote: (Chair hat off). I object to promoting this document to WG Draft, due to concerns about Section 4 (SFrameTransform). Within the IETF, proposals for SFrame over RTP have been controversial and so far have not been adopted by a WG. At IETF 111, an alternative to SFRame over RTP (SPacket) was proposed. It therefore seems premature to me to introduce an API that is specific to a protocol proposal that may not gain traction. I have filed a GitHub issue here: Protocol Reference for SFrameTransform · Issue #112 · w3c/webrtc-encoded-transform (github.com)<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fwebrtc-encoded-transform%2Fissues%2F112&data=04%7C01%7CBernard.Aboba%40microsoft.com%7C1a0e2c95866e431861e508d95bcc7722%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637641756012822732%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=k9gFqGA3AoJK3ZJgWkZXjOeJTslSwr6DwK1%2B4j4PWME%3D&reserved=0> Thanks for filing this issue. Let’s dig into that there.
Received on Tuesday, 10 August 2021 14:04:06 UTC