Re: [AVTCORE] Magnus Westerlund's No Objection on draft-ietf-payload-tsvcis-04: (with COMMENT)

<[email protected]> Tue, 29 Oct 2019 15:11:21 -0400
Newsgroups gmane.ietf.avt
Message-ID <[email protected]>
Hi Magnus,

Let me address the comment you make.  Yes indeed you need to parse from the bottom up one frame at a time.  This had to be done with RFC8130 for MELP payloads already.  Keep in mind that TSVCIS coder frames consist of two portions, a fixed size MELP 2400 and variable size TSVCIS.  Its is permitted for the TSVCIS portion to vary in size within a single RTP payload.  That would allow the VDR speech coder to act as it should (if enabled to do so).  In practice, TSVCIS payload would likely always be a fixed size.  

Language had been added to make it clear that other MELP rates are not to be mixed.  That is consistent with RFC8130 and prevents complexities such as different timestamp advances for MELP frames of different rates (600, 1200 and 2400).  

> (now)
>    TSVCIS coder frames in a single RTP packet MAY have varying TSVCIS
>    parameter octet counts.  Its packed parameter octet count (length) is
>    indicated in the trailing byte(s).  All MELPe frames in a single RTP
>    packet MUST be of the same coder bitrate.  For all MELPe coder
>    frames, the coder rate bits in the trailing byte identify the
>    contents and length as per Table 1.

I hope this is satisfactory.

Victor

-----Original Message-----
From: Magnus Westerlund via Datatracker <[email protected]> 
Sent: Tuesday, October 29, 2019 7:24 AM
To: The IESG <[email protected]>
Cc: [email protected]; Ali Begen <[email protected]>; [email protected]; [email protected]; [email protected]
Subject: Magnus Westerlund's No Objection on draft-ietf-payload-tsvcis-04: (with COMMENT)

Magnus Westerlund has entered the following ballot position for
draft-ietf-payload-tsvcis-04: No Objection

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-payload-tsvcis/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for addressing the discusses and comments.

I leave this comment, as something that could have been more explicit about decoding, however one skilled in the art will figure it out.

        A. Section 3.3:
           TSVCIS coder frames in a single RTP packet MAY be of different coder
   bitrates.  With the exception for the variable length TSVCIS
   parameter frames, the coder rate bits in the trailing byte identify
   the contents and length as per Table 1.

        If I understand this correctly in an RTP payload that contain mulyiplr
        bit-rate frames the safest way of decoding this payload is to work from
        the end of the payload towards the start identifying a frame at a time.
        Then after having figured out how many frames actually are present, one
        can calculate the timestamp value for each frame.


_______________________________________________
Audio/Video Transport Core Maintenance
[email protected]
https://www.ietf.org/mailman/listinfo/avt