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

Richard, when you talk about "units" here, are you referring to things
coming out of the codec? or the RTP packetizer for said codec?

The recent IETF meeting ended with some confusion as to this specific
question and it would be good for us on this list to make sure we're all in
alignment.

On Tue, Sep 7, 2021 at 12:46 PM Richard Barnes <rlb@ipv.sx> wrote:

> 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
>>>
>> --
> Sframe mailing list
> Sframe@ietf.org
> https://www.ietf.org/mailman/listinfo/sframe
>