Subject: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC

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

#10: Marker bit in H.265/HEVC

 The draft says: " Marker bit (M): 1 bit Set for the last packet of the
 access unit indicated by the RTP timestamp, in line with the normal use of
 the M bit in video formats, to allow an efficient playout buffer handling.
 " However, in HEVC, in contrast to H.264, there may be SEI NAL units
 following the last VCL NAL unit in the access unit. (and those SEI NAL
 units are allowed to have higher TemporalId than the VCL NAL units). A
 MANE that removes those SEI NAL units must therefore change the value of
 the marker bit in an earlier packet.

 One option would be to change to "Marker bit (M): 1 bit Set for the last
 packet of the picture (i.e. the packet containing the last VCL NAL unit of
 a picture).." but that would of course have other implications.

-- 
-------------------------------------+-------------------------------------
 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/10>
payload <http://tools.ietf.org/payload/>

---

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

Comment (by [email-masked]):

 Yes, change according to the suggestion to exclude non-VCL NAL unit would
 at least have an implication on the purpose of setting the marker bit,
 i.e. for playout buffer handling. I am hesitant to agree with this change
 due to this reason, though frankly I have not carefully checked how
 exactly the marker bit plays its role in playout buffer handling.

 Does anyone else have an opinion here?

 Severity:  -                        |  Resolution:
 Keywords:                           |

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

---

From: "payload issue tracker" <[email-masked]>
Date: Wed, 26 Feb 2014 23:01:28 -0000

Comment (by [email-masked]):

 Yes, I do have an opinion.  I would leave things as is normatively, but
 add a note with a warning.
 I believe what Jonatan is concerned about here is related to a somewhat
 exotic use case: (a)  *very* low delay selective forwarding/thinning in a
 MANE wherein (b) one wants to forward a packet before all other packets of
 the same access unit (picture) have been received by the MANE and (c)
 wherein the post-picture SEI message(s) are packetized in their own
 packet(s), rather than being aggregated with a VCL NAL unit.
 A well-designed sender/encoder could trivially avoid the problem by
 placing the trailing SEI message(s) into an aggregation packet together
 with the final VCL NAL unit, at least assuming there is space left in the
 packet from an MTU viewpoint.  Most SEI messages are small, so the
 likelihood is high.  Further, extremely low delay systems typically have
 real-time encoders (why use an extremely low delay transmission path for
 pre-recorded content), so the encoder has a lot of control in what is
 going where in the packet stream.
 Even if all this were not the case, the MANE can still remain compliant by
 inserting some form of a dummy RTP packet containing a "throw away" NAL
 unit.  For that, the filler data NAL unit (which is suffix, I believe)
 would be a perfect example.

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