Re: [payload] Addressing comments on 2nd WGLC of draft-ietf-payload-rtp-ancillary-08

John Fletcher <John.Fletcher@bbc.co.uk> Fri, 05 May 2017 17:38 UTC

Return-Path: <John.Fletcher@bbc.co.uk>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDA53129B0A for <payload@ietfa.amsl.com>; Fri, 5 May 2017 10:38:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMIwSHWSunbb for <payload@ietfa.amsl.com>; Fri, 5 May 2017 10:38:46 -0700 (PDT)
Received: from mailout0.telhc.bbc.co.uk (mailout0.telhc.bbc.co.uk [132.185.161.179]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63980129AEB for <payload@ietf.org>; Fri, 5 May 2017 10:38:46 -0700 (PDT)
Received: from BGB01XI1008.national.core.bbc.co.uk (bgb01xi1008.national.core.bbc.co.uk [10.161.14.22]) by mailout0.telhc.bbc.co.uk (8.15.2/8.15.2) with ESMTP id v45Hcg3k011317; Fri, 5 May 2017 18:38:42 +0100 (BST)
Received: from BGB01XUD1011.national.core.bbc.co.uk ([10.161.14.9]) by BGB01XI1008.national.core.bbc.co.uk ([10.161.14.22]) with mapi id 14.03.0319.002; Fri, 5 May 2017 18:38:41 +0100
From: John Fletcher <John.Fletcher@bbc.co.uk>
To: Thomas Edwards <Thomas.Edwards@fox.com>
CC: "payload@ietf.org" <payload@ietf.org>
Thread-Topic: Addressing comments on 2nd WGLC of draft-ietf-payload-rtp-ancillary-08
Thread-Index: AQHSw6cKJHsTJYrHE0yJGid5ElJJq6HissNP///+xwCAATe//IAAaGwAgAGtr1k=
Date: Fri, 05 May 2017 17:38:40 +0000
Message-ID: <B1D49063AD5FBD4688F3EEDEC68B2017C3815AFA@bgb01xud1011>
References: <26ED0D58-E6D6-4DD7-9801-4556FF67AAC2@fox.com> <B1D49063AD5FBD4688F3EEDEC68B2017C38150C0@bgb01xud1011> <5963166F-3FCC-4B88-8F60-1CBF4F5CFC0C@fox.com> <B1D49063AD5FBD4688F3EEDEC68B2017C3815690@bgb01xud1011>, <54FEE4EC-5366-4086-B656-820510264769@fox.com>
In-Reply-To: <54FEE4EC-5366-4086-B656-820510264769@fox.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.19.161.212]
x-exclaimer-md-config: c91d45b2-6e10-4209-9543-d9970fac71b7
x-tm-as-product-ver: SMEX-11.0.0.4179-8.100.1062-23052.000
x-tm-as-result: No--9.484200-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/payload/-mUlXPdHtuKtThWQYwptVSBu5gQ>
Subject: Re: [payload] Addressing comments on 2nd WGLC of draft-ietf-payload-rtp-ancillary-08
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/payload/>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 May 2017 17:38:49 -0000

Regarding the C bit, I think something like my originally suggested wording is better:

If the data corresponds to the color-difference data channel of an associated SDI interface, the C flag shall be set to "1".  If the data corresponds to the luma data channel of an associated SDI interface, or the interface does not have separate luma and color-difference data channels, or the data is not associated with an SDI interface, the C flag shall be set to "0".

Reasons being (a) you should mention that luma/color-difference channels are things in an SDI interface; (b) your suggested wording says  that if it is set to "0" the ANC data  corresponds to the luma (Y) data channel, but that is not necessarily true, it might be because there are no luma/color-difference channels or because  there is no associated SDI interface.

Regarding link number, you probably need to explain that if there are 2 links with 4 data channels each, you number the data channels across all links so that link 2, data channel 1 is the 5th data channel etc.   You might also want to allow another bit so you could go up to 24 Gbit/s interfaces.

Including the payload ID byte 1 value is a good idea.

It would be good to run all this by an SDI expert.

John

________________________________________
From: payload [payload-bounces@ietf.org] on behalf of Thomas Edwards [Thomas.Edwards@fox.com]
Sent: 04 May 2017 23:38
To: payload@ietf.org
Subject: Re: [payload] Addressing comments on 2nd WGLC of draft-ietf-payload-rtp-ancillary-08

>On 5/4/17, 4:16 AM, "John Fletcher" <John.Fletcher@bbc.co.uk> wrote:
> Regarding the C bit, I suggest deleting "for HD or UHD signals" because those those formats do not always map to an interface with luma and color-difference data channels.
> I also think you should use the term "data channel" as in ST 292-1 section 4.2

That would leave the description as:

“C: 1 bit
           This flag, when set to "1", indicates that
           the ANC data corresponds to the color-difference data channel (C).
           When set to "0", this flag indicates that the ANC data
           corresponds to the luma (Y) data channel.  For SD signals, this
           flag SHALL be set to "0".  For ANC data packets that do not
           originate from SDI sources, if the ANC data type definition
           requires the use of the C or Y data channel, the C flag SHALL
           reflect that requirement, otherwise the C flag SHALL be set
           to "0".”

Does that address your concerns?

>The link number change looks good.  It would be nice to add the data stream number as well using the other 4 bits (current max is 8 data streams in 12G SDI).
>To make sense of link number and data stream number, you really need to know the interface format (e.g. whether it is ST 372 dual-link 1.5G or ST 425-1 single-link 3G).  Could this be >included in the payload format parameters?

Actually your comment on stream number and reading through all of the various dual and quad-link interfaces has lead me to believe that stream number is the key, not link number.  A stream number, for a given video format standard, should define the link number, thus there is no reason to signal both.  We need to handle up to 32 data streams for the extreme case of SMPTE ST 2082-12: 4320-line and 2160-line Source Image and Ancillary Data Mapping for Quad-link 12G-SDI.

So let’s forget the “Channel Assignment” field, and instead have a “Data Stream Number” field:

    “Data Stream Number: 6 bits

    This field can indicate the data stream number of a multi-stream data mapping used to transport the ANC data packet.
    If the first bit of this field is ‘0’, then this field provides no guidance regarding the data stream number of the ANC data packet.
    If the first bit of this field is ‘1’, then the following five bits MUST carry the data stream number minus one of the ANC data packet.

    For multi-stream interface formats that do not have numbered data streams, but instead have lettered data stream links
    (such as SMPTE ST 372), the following numbers SHALL be used in this field: ‘0’ for link A data stream, ‘1’ for link B data stream.

    For stereoscopic multi-stream interface formats that do not have numbered streams, the following numbers SHALL be used in
    this field: ‘0’ for left eye stream, ‘1’ for right eye stream.”

And I think it is reasonable to have the Video Payload Identification Codes as an optional parameter in the Media Type Definition:

“VPID_Code:
        This integer parameter specifies the Video Payload ID (VPID) Code of the source interface of ANC data packets using the value
from byte 1 of the VPID as defined in SMPTE ST 352.  The integer SHALL be made with bit 7 of VPID byte 1 being the most significant bit,
and bit 0 of VPID byte 1 being the least significant bit.  For example, 132 shall refer to SMPTE ST 292-1, 720-line video payloads on a 1.5 Gbps
(nominal) serial digital interface.”

-Thomas

    John
    ________________________________________
    From: payload [payload-bounces@ietf.org] on behalf of Thomas Edwards [Thomas.Edwards@fox.com]
    Sent: 03 May 2017 22:49
    To: payload@ietf.org
    Subject: Re: [payload] Addressing comments on 2nd WGLC of draft-ietf-payload-rtp-ancillary-08

    Sorry, for some reason the C bit change did not get noted.

    The original text from SMPTE ST 2038-2008 is:

    “c_not_y_channel_flag: For HD, this flag, when set to ‘1’, indicates the ANC data corresponds to the color difference channel. When set to ‘0, this flag indicates the ANC data corresponds to the luminance channel. For SD, this flag shall be set to ‘0’.”

    I think it is best to keep the description close to this proven data model, so I suggest that we simply change the first sentence of the C bit ANC data packet header field to read:

    “For HD or UHD signals, this flag, when set to "1", indicates that the ANC data corresponds to the color-difference channel (C).”

    Regarding the link number, I see your argument that it really should be carried in the ANC data packet header fields.  We have a few reserved bits now after Horizontal_Offset, so I guess we can use them.

    To try to do this correctly, I think we should reference the SMPTE ST 352 use of bits b7 to b5 of byte 4 of the default payload identifier as a channel assignment field for channels 1-8.

    This would result in a new ANC data packet payload header field:

    “Channel Assignment: 4 bits

    This field can indicate the channel number of a multi-channel link used to transport the ANC data packet.
    If the first bit of this field is ‘0’, then this field provides no guidance regarding the channel placement of the ANC data packet.
    If the first bit of this field is ‘1’, then the following bits MUST carry the channel identification information of section 5.5.1 of SMPTE ST 352 contained in byte 4 of the payload identifier.
    The second bit of the channel assignment field carries bit b7 of byte 4 of the payload identifier, the third bit carries bit b6, and the fourth bit carries bit b5.”

    With the addition of the Channel Assignment ANC data packet header field, I think it is appropriate to remove LinkNumber from the Media Type Definition.  In truth, looking through various multi-link SDI interfaces and their use of SMPTE ST 352, I’m not 100% sure the current definition of LinkNumber would always be clear & appropriate, but the bits in Byte 4 from SMPTE ST 352 will always be clear.

    -Thomas

    On 5/3/17, 7:55 AM, "John Fletcher" <John.Fletcher@bbc.co.uk> wrote:

        Regarding the C bit, I don't see any change.
        I suggest: "If the data corresponds to the color-difference data channel of the SDI interface, the C flag shall be set to "1".  If the data corresponds to the luma data channel of the SDI interface, or the interface does not have separate luma and color-difference data channels, or the data is not associated with an SDI interface, the C flag shall be set to "0"."

        And a further comment...
        The LinkNumber parameter cannot be used if there is data from more than one link in the RTP stream.  And a single number is inadequate for interfaces that mave multiple links and multiple data streams per link.  If it is a requirement to  reproduce link/data stream when going SDI->RTP->SDI then link number and data stream number need to be in the payload header for each ANC packet.

        John


    _______________________________________________
    payload mailing list
    payload@ietf.org
    https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_payload&d=DwIF-g&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=__cAFj6LOkUA89j9fGP9CGciM2-M4ExhUSqjK-175QM&s=pAmH8LqbSlkQikYxG71ieJyiPcxIFxBQWQ4kqGgKbKo&e=



_______________________________________________
payload mailing list
payload@ietf.org
https://www.ietf.org/mailman/listinfo/payload