Subject: [payload] #9 (rtp-h265): Empty FUs

From: "payload issue tracker" <[email-masked]>
Date: Tue, 25 Feb 2014 16:33:56 -0000

#9: Empty FUs

 The draft says: "An FU payload MAY have any number of octets and MAY be
 empty." with the motivation: "If zero-length FU payloads were not allowed,
 the sender would have to generate at least one bit of data of the
 following fragment of the NAL unit before the current FU could be sent.
 Due to the characteristics of HEVC, where sometimes several CTUs occupy
 zero bits."

 While it is true that several CTUs may occupy zero bits, the last CTU of a
 slice segment will always occupy at least one byte (containing the
 rbsp_stop_one_bit) so I don't really see in which situation you would end
 up with the need to send an empty FU.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-payload-
  [email-masked]    |  [email-masked]
     Type:  defect                   |     Status:  new
 Priority:  major                    |  Milestone:
Component:  rtp-h265                 |    Version:  2.0
 Severity:  -                        |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/payload/trac/ticket/9>
payload <http://tools.ietf.org/payload/>

---

From: "payload issue tracker" <[email-masked]>
Date: Wed, 26 Feb 2014 21:48:22 -0000

#9: Empty FUs

Comment (by [email-masked]):

 Good catch. I think you are right. This was inherited from RFC 6184. After
 checking, it seems that the reason does not hold for H.264/AVC, either.

 I'd suggest that we disallow any FU to be empty. Unless otherwise
 concluded, I will include this change to the next version of the draft.

 Severity:  -                        |  Resolution:
 Keywords:                           |

Ticket URL: <http://trac.tools.ietf.org/wg/payload/trac/ticket/9#comment:1>
payload <http://tools.ietf.org/payload/>

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 26 Feb 2014 21:56:29 +0000

Sounds good to me.
Stephan

On 26.2.14, 13:48, "payload issue tracker"
<[email-masked]> wrote:

>Ticket URL: 
><http://trac.tools.ietf.org/wg/payload/trac/ticket/9#comment:1>