Subject: [AVTCORE] Clarification of marker bit in H.264 packetization

From: "Alfred E. Heggestad" <[email-masked]>
Date: Sat, 3 Mar 2018 14:08:20 +0100

Hi all,

I have a question about the RTP marker bit in
the H264 RTP Payload format:

   https://tools.ietf.org/html/rfc6184

is it safe to assume that;

* The usage of marker bit in H.264 is the same
   as in other video codecs, such as H.263 ?

* For fragmented packets, the first packets have
   marker=0 and the last packet have marker=1 ?

The background is that we are trying to find out
the exact meaning of the marker bit. Some SIP clients
seem to ignore the marker bit for incoming packets.

Reference:

   https://github.com/alfredh/baresip/issues/353

Best Regards,

Alfred

---

From: [email-masked] (Dale R. Worley)
Date: Sat, 03 Mar 2018 08:59:17 -0500

>    marker=0 and the last packet have marker=1 ?

In RFC 6184 (which you reference) section 5.1 is this definition:

   Marker bit (M): 1 bit
      Set for the very 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.

In regard to your first question, it says "in line with the normal use
of the M bit in video formats".

In regard to your second question, it says "Set for the very last packet
of the access unit indicated by the RTP timestamp".

So it seems that the answers are "Yes".  But you probably know more of
the context of video codecs than I do...

Dale

---

From: "Alfred E. Heggestad" <[email-masked]>
Date: Thu, 8 Mar 2018 19:25:39 +0100

> the context of video codecs than I do...

Thanks Dale,

I am a bit confused about this part:

       Decoders MAY use this bit as
       an early indication of the last packet of an access unit but MUST
       NOT rely on this property.

does it refer to the marker bit or something else ?

the VP8 spec says:

       Marker bit (M):  MUST be set for the very last packet of each encoded
       frame in line with the normal use of the M bit in video formats.
       This enables a decoder to finish decoding the picture, where it
       otherwise may need to wait for the next packet to explicitly know
       that the frame is complete.

the VP9 spec says:

       Marker bit (M):  MUST be set to 1 for the final packet of the highest
       spatial layer frame (the final packet of the super frame), and 0
       otherwise.  Unless spatial scalability is in use for this super
       frame, this will have the same value as the E bit described below.
       Note that a MANE MUST set this value to 1 for the target spatial
       layer frame when shaping out higher spatial layers.

in my opinion VP8 and VP9 spec makes sense. why is the
H.264 packetization different ?

would it be possible to change RFC 3550 and RFC 6184 to say that
the decoder MUST use the marker bit to find the very last packet
of an encoded frame ?

it would be great if all video codecs can be consistent on this,
then the decoder implementations does not have to fiddle with timestamps
and can always have precise and efficient playout using Marker bit.

/alfred

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 08 Mar 2018 22:41:13 -0500

> does it refer to the marker bit or something else ?

Clearly, "this bit" means the M bit.

>        frame in line with the normal use of the M bit in video formats.
[...]
>        otherwise.
[...]
> H.264 packetization different ?

In what way is the H.264 packetization different?

> the decoder MUST use the marker bit to find the very last packet

There would be no point in doing so.  The RFC is the definition of the
*protocol*, what bits go on the wire and their meaning.  The decoder is
free to do whatever it wants with the bits, so the fact that the RFCs
make different suggestions to decoders isn't important.  But the RFCs
say that for all three codec formats, the M bit must be set for the last
packet of a frame (for suitable definitions of "frame" in each case --
I'm assuming that an "access unit" is analogous to "frame").

Dale