Subject: [Sframe] Proposal: SFrame && SPacket && !SIDU

From: Richard Barnes <[email-masked]>
Date: Thu, 2 Sep 2021 16:20:18 -0400

Hi folks,

I'd like to see if we can agree to limit our scope a bit.  There has been
discussion of multiple levels at which SFrame could be applied:

* "SFrame" - Whole media frames
* "SPacket" - Individual RTP media payloads
* "SIDU" - Some codec-specific "independently decodeable units"

I'd like to propose that we take "SIDU" off of the table, but keep the
other two.

It seems like SFrame and SPacket both have strengths in certain scenarios
(depending on how you want to trade off bandwidth vs. complexity), but
they're both pretty straightforward in terms of how they integrate with the
media processing pipeline.  In particular, they don't have any
codec-dependence.  SIDU, by contrast, seems like a world of pain.  It
requires that the encryption scheme be entangled with the codec, which
requires special per-codec integration logic in the specifications.  And
the bandwidth gains for all that complexity are not that large.

Is there anyone here who feels that SIDU is something this group needs to
spend time specifying?

--Richard

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 6 Sep 2021 20:53:44 +0200

Hi Richard,

Just one minor comment, the "media frames", should be spatial frames if SVC
is used so an SFU is able to not forward all spatial layers to the
receiver. Apart from that, I am ok with removing "SIDUs" from the scope.

Best regards
Sergio

On Thu, Sep 2, 2021 at 10:20 PM Richard Barnes <[email-masked]> wrote:

> --
> Sframe mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sframe
>

---

From: Richard Barnes <[email-masked]>
Date: Tue, 7 Sep 2021 15:46:02 -0400

I'm not totally sure what you mean by "spatial frames" here; looks like the
notion varies some by codec.  Assuming "spatial frames" are frames in the
sense of "something that comes out of depacketizater", I think we're
probably on the same page.

Maybe it would be clearer to state the proposal as: Encryption is done in
units of whole RTP payloads.  One payload for SPacket; all payloads in the
frame for SFrame.  We would not support cases where an encrypted unit would
span a partial RTP payload.  For example:

NOT OK
Payload 1: First part of SFrame unit A
Payload 2: Second part of A, first part of B
Payload 3: Second part of B

OK
Payload 1: SFrame unit A
Payload 2: First part of Sframe unit B
Payload 3: Second part of B

Does that line up with what you have in mind?

--Richard

On Mon, Sep 6, 2021 at 2:53 PM Sergio Garcia Murillo <
[email-masked]> wrote:

> Hi Richard,
>
> Just one minor comment, the "media frames", should be spatial frames if
> SVC is used so an SFU is able to not forward all spatial layers to the