Subject: Re: [payload] WGLC Feedback for draft-ietf-payload-rtp-h265-09

From: Magnus Westerlund <[email-masked]>
Date: Mon, 1 Jun 2015 11:45:13 +0200

Hi,

I looked at the changes and one thing made me react.

Wang, Ye-Kui skrev den 2015-05-30 00:24:
> Hi Ben,
>
> Thanks for your careful review and the detailed comments. Our answers
> to your other questions are in below, each starting with "[YK]". We
> will submit the new version containing these changes soon.
>
> *** Substantive ***
>
> -- 1.1.4, forbidden_zero_bit, "HEVC declares a value of 1 as a syntax
> violation."
>
> Does that mean that setting the bit is a syntax violation in itself,
> or that it _indicates_ a syntax violation? As worded, it sound like
> the former, but later examples seem to suggest the latter. (e.g. last
> sentence of 4.4.3)
>
> [YK]: It is the former from the HEVC spec point of view. The HEVC
> spec just says that the value of the bit shall be equal to 0. A MANE
> (in the context of this memo) can use the bit to indicate a syntax
> violation, as you noticed in the last sentence of 4.4.3. We will
> change the wording as follows (plus the addition of RFC 3828 as an
> informative reference) unless there is objection:
>
> [Current wording] forbidden_zero_bit.  Required to be zero in [HEVC].
> HEVC declares a value of 1 as a syntax violation.  Note that the
> inclusion of this bit in the NAL unit header is to enable transport
> of HEVC video over MPEG-2 transport systems (avoidance of start code
> emulations) [MPEG2S].
>
> [Changed wording] forbidden_zero_bit.  Required to be zero in [HEVC].
> Note that the inclusion of this bit in the NAL unit header was to
> enable transport of HEVC video over MPEG-2 transport systems
> (avoidance of start code emulations) [MPEG2S].  In the context of
> this memo, the value 1 MAY be used to indicate a syntax violation.
> For example, when RTP is transported over UDP-lite [RFC3828] and the
> receiver decides to feed the video decoder NAL unit(s) where the
> corresponding UDP-lite packet failed a checksum test, then this bit
> can be set to alarm the decoder of possible bit errors.

The example in the new wording is not practically possible. The point of 
UDP-Lite is that you calculate the checksum only over a selected initial 
part of the IP/UDP packet. Any checksum violations will commonly result 
in that the whole packet is discarded. What UDP-Lite is offering is that 
any error in the unprotected part will not result in the packet being 
discarded. However, the receiver has no knowledge if the unprotected 
part of the UDP payload was damaged or not. Thus, no information is 
available to set the syntax violation bit.

Thus, the example should be removed. No practical example came to mind, 
except maybe for a RTP middlebox forwarding a known uncomplete 
fragmented NALU where the end is missing.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 01 Jun 2015 09:00:24 -0500

On 1 Jun 2015, at 4:45, Magnus Westerlund wrote:

> The example in the new wording is not practically possible. The point 
> of UDP-Lite is that you calculate the checksum only over a selected 
> initial part of the IP/UDP packet. Any checksum violations will 
> commonly result in that the whole packet is discarded. What UDP-Lite 
> is offering is that any error in the unprotected part will not result 
> in the packet being discarded. However, the receiver has no knowledge 
> if the unprotected part of the UDP payload was damaged or not. Thus, 
> no information is available to set the syntax violation bit.
>
> Thus, the example should be removed. No practical example came to 
> mind, except maybe for a RTP middlebox forwarding a known uncomplete 

So is there ever value in setting the "forbidden_zero_bit"?

Ben.

---

From: Stephan Wenger <[email-masked]>
Date: Mon, 1 Jun 2015 17:18:28 +0000

Hi,
The UDP-lite text was from me.  After re-reading it, I agree with Magnus
that it is incorrect as written.  However:
One can use (and some folks have used) the forbidden zero bit to advise
the decoder that there *may* be bit errors in the payload.  Similar
markers have been used in H.324/M carrying H.263 for ages, and it was
always a mess that there was no way in the bitstream to tell a
(chip-based) decoder to be ready for the worst...
In at least one implementation I am aware of, H.264¹s forbidden zero bit
has been used for precisely this purpose.  In that case, the UDP-lite
checksum covered only the UDP and RTP headers, and left the H.264 payload
unprotected.  The receiver was made aware that there may be something
fishy in the H.264 NAL unit by the forbidden zero bit set in all such NAL
units.  Due to the failure of UDP-lite in general, this product never made
any significant market impact, but it is my understanding that the vendors
at that time had kind-of agreed (in IMTC?) that this would be the right
thing to do.
There were also ideas to set the forbidden zero bit in gateways, just as
Magnus described.
As a resolution, I can think of two ways forward, and I don¹t really have
a preference:
1. Remove the note.  Has the advantage of being correct, but may lead
people on the wrong path, just as perhaps Ben may be right now)
2. Change the note:
OLD: For example, when RTP is transported over UDP-lite [RFC3828] and the
receiver decides to feed the video decoder NAL unit(s) where the
corresponding UDP-lite packet failed a checksum test, then this bit
can be set to alarm the decoder of possible bit errors.
NEW: For example, when RTP is transported over UDP-lite [RFC3828] and the
receiver decides to feed the video decoder NAL unit(s) where the
corresponding UDP-lite packet checksum-protected only parts of the packet
(and
therefore the the remainder of the packet can include bit errors with a
likelyhood
Several orders of magnitude higher than a UDP packet would have) then this
bit
can be set to alarm the decoder of possible bit errors.
Stephan

---

From: "Wang, Ye-Kui" <[email-masked]>
Date: Mon, 1 Jun 2015 18:02:01 +0000

Ben noted earlier (in his initial reviewing comments) that we have the following use of this bit specified at the end of 4.4.3:

"A receiver in an endpoint or in a MANE MAY aggregate the first n-1 fragments of a NAL unit to an (incomplete) NAL unit, even if fragment n of that NAL unit is not received.  In this case, the forbidden_zero_bit of the NAL unit MUST be set to one to indicate a syntax violation."

This is also more-or-less aligned with what Magnus mentioned below.

Thus, maybe it is better to remove the UDP-Lite example, and mention its actual use in this document, as follows:.

"forbidden_zero_bit.  Required to be zero in [HEVC].  Note that the inclusion of this bit in the NAL unit header was to enable transport of HEVC video over MPEG-2 transport systems (avoidance of start code emulations) [MPEG2S].  In the context of this memo, the value 1 may be used to indicate a syntax violation, e.g. for a NAL unit resulted from aggregating a number of fragmented units of a NAL unit but missing the last fragment, as described in Section 4.4.3."

If agreeable, I can quickly update the document and submit -v11. 

BR, YK

-----Original Message-----
From: Stephan Wenger [mailto:[email-masked]] 
Sent: Monday, June 01, 2015 10:18 AM
To: Ben Campbell; Magnus Westerlund
Cc: Wang, Ye-Kui; [email-masked]; [email-masked]
Subject: Re: [payload] WGLC Feedback for draft-ietf-payload-rtp-h265-09

Hi,
The UDP-lite text was from me.  After re-reading it, I agree with Magnus that it is incorrect as written.  However:
One can use (and some folks have used) the forbidden zero bit to advise the decoder that there *may* be bit errors in the payload.  Similar markers have been used in H.324/M carrying H.263 for ages, and it was always a mess that there was no way in the bitstream to tell a
(chip-based) decoder to be ready for the worst...
In at least one implementation I am aware of, H.264¹s forbidden zero bit has been used for precisely this purpose.  In that case, the UDP-lite checksum covered only the UDP and RTP headers, and left the H.264 payload unprotected.  The receiver was made aware that there may be something fishy in the H.264 NAL unit by the forbidden zero bit set in all such NAL units.  Due to the failure of UDP-lite in general, this product never made any significant market impact, but it is my understanding that the vendors at that time had kind-of agreed (in IMTC?) that this would be the right thing to do.
There were also ideas to set the forbidden zero bit in gateways, just as Magnus described.
As a resolution, I can think of two ways forward, and I don¹t really have a preference:
1. Remove the note.  Has the advantage of being correct, but may lead people on the wrong path, just as perhaps Ben may be right now) 2. Change the note:
OLD: For example, when RTP is transported over UDP-lite [RFC3828] and the receiver decides to feed the video decoder NAL unit(s) where the corresponding UDP-lite packet failed a checksum test, then this bit can be set to alarm the decoder of possible bit errors.
NEW: For example, when RTP is transported over UDP-lite [RFC3828] and the receiver decides to feed the video decoder NAL unit(s) where the corresponding UDP-lite packet checksum-protected only parts of the packet (and therefore the the remainder of the packet can include bit errors with a likelyhood Several orders of magnitude higher than a UDP packet would have) then this bit can be set to alarm the decoder of possible bit errors.
Stephan

On 6/1/15, 07:00, "Ben Campbell" <[email-masked]> wrote:

>>> Thanks for your careful review and the detailed comments. Our 
>>> answers to your other questions are in below, each starting with 
>>> "[YK]". We will submit the new version containing these changes soon.
>>>
>>> *** Substantive ***
>>>
>>> -- 1.1.4, forbidden_zero_bit, "HEVC declares a value of 1 as a 
>>> syntax violation."
>>>
>>> the former, but later examples seem to suggest the latter. (e.g. 
>>> last sentence of 4.4.3)
>>>

---

From: Stephan Wenger <[email-masked]>
Date: Mon, 1 Jun 2015 18:28:03 +0000

OK with me.
S.

On 6/1/15, 11:02, "Wang, Ye-Kui" <[email-masked]> wrote:

>Ben noted earlier (in his initial reviewing comments) that we have the
>following use of this bit specified at the end of 4.4.3:
>
>"A receiver in an endpoint or in a MANE MAY aggregate the first n-1
>fragments of a NAL unit to an (incomplete) NAL unit, even if fragment n
>of that NAL unit is not received.  In this case, the forbidden_zero_bit
>of the NAL unit MUST be set to one to indicate a syntax violation."
>
>Thus, maybe it is better to remove the UDP-Lite example, and mention its
>actual use in this document, as follows:.
>
>"forbidden_zero_bit.  Required to be zero in [HEVC].  Note that the
>inclusion of this bit in the NAL unit header was to enable transport of
>HEVC video over MPEG-2 transport systems (avoidance of start code
>emulations) [MPEG2S].  In the context of this memo, the value 1 may be
>used to indicate a syntax violation, e.g. for a NAL unit resulted from
>aggregating a number of fragmented units of a NAL unit but missing the
>last fragment, as described in Section 4.4.3."
>
>units.  Due to the failure of UDP-lite in general, this product never
>made any significant market impact, but it is my understanding that the
>vendors at that time had kind-of agreed (in IMTC?) that this would be the
>right thing to do.
>people on the wrong path, just as perhaps Ben may be right now) 2. Change
>the note:
>corresponding UDP-lite packet failed a checksum test, then this bit can
>be set to alarm the decoder of possible bit errors.
>(and therefore the the remainder of the packet can include bit errors
>with a likelyhood Several orders of magnitude higher than a UDP packet
>would have) then this bit can be set to alarm the decoder of possible bit
>errors.
>Stephan
>
>

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 2 Jun 2015 10:07:28 +0200

> If agreeable, I can quickly update the document and submit -v11.

Yes, that appears a good solution.

Cheers

Magnus Westerlund

---

From: Bo Burman <[email-masked]>
Date: Tue, 2 Jun 2015 12:11:45 +0000

I checked -09 and -10 versions. Besides the comment made by Magnus and the solution suggested below, which I agree to, I  found only the following nit:

Section 4.1, below Figure 2:
OLD:
Marker bit (M): 1 bit
       Set for the last packet carried in the current RTP stream of
       the access unit.  This is in line with the normal use of the M
NEW:
Marker bit (M): 1 bit
       Set for the last packet of the access unit, carried in the current
       RTP stream.  This is in line with the normal use of the M

Cheers,
Bo

> From: payload [mailto:[email-masked]] On Behalf Of Magnus Westerlund
> Sent: den 2 juni 2015 10:07
> To: Wang, Ye-Kui; Stephan Wenger; Ben Campbell
> Cc: [email-masked]; [email-masked]
> > "A receiver in an endpoint or in a MANE MAY aggregate the first n-1 fragments of a NAL unit to an (incomplete) NAL
> unit, even if fragment n of that NAL unit is not received.  In this case, the forbidden_zero_bit of the NAL unit MUST be
> set to one to indicate a syntax violation."
> >
> > "forbidden_zero_bit.  Required to be zero in [HEVC].  Note that the inclusion of this bit in the NAL unit header was to
> enable transport of HEVC video over MPEG-2 transport systems (avoidance of start code emulations) [MPEG2S].  In the
> context of this memo, the value 1 may be used to indicate a syntax violation, e.g. for a NAL unit resulted from
> aggregating a number of fragmented units of a NAL unit but missing the last fragment, as described in Section 4.4.3."
> >
> _______________________________________________
> payload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/payload

---

From: "Wang, Ye-Kui" <[email-masked]>
Date: Tue, 2 Jun 2015 16:26:42 +0000

Thanks Bo - the suggested change is indeed an improvement! Thanks Magnus as well for confirming the other change. 

I will now go ahead to make these two changes and submit -11. 

BR, YK

-----Original Message-----
From: Bo Burman [mailto:[email-masked]] 
Sent: Tuesday, June 02, 2015 5:12 AM
To: Magnus Westerlund; Wang, Ye-Kui; Stephan Wenger; Ben Campbell
Cc: [email-masked]; [email-masked]
Subject: RE: [payload] WGLC Feedback for draft-ietf-payload-rtp-h265-09

Cheers,
Bo

> > Ben noted earlier (in his initial reviewing comments) that we have 
> > the following use of this bit specified at the end of
> 4.4.3:
> >
> > fragments of a NAL unit to an (incomplete) NAL
> unit, even if fragment n of that NAL unit is not received.  In this 
> case, the forbidden_zero_bit of the NAL unit MUST be set to one to indicate a syntax violation."
> >
> > inclusion of this bit in the NAL unit header was to
> (avoidance of start code emulations) [MPEG2S].  In the context of this 
> memo, the value 1 may be used to indicate a syntax violation, e.g. for a NAL unit resulted from aggregating a number of fragmented units of a NAL unit but missing the last fragment, as described in Section 4.4.3."
> >