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

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 <
sergio.garcia.murillo@cosmosoftware.io> 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
> 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 <rlb@ipv.sx> wrote:
>
>> 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
>> --
>> Sframe mailing list
>> Sframe@ietf.org
>> https://www.ietf.org/mailman/listinfo/sframe
>>
>