[AVTCORE] VP9 discardable non-reference frame indicator

["Mo Zanaty (mzanaty)" <[e-mail]>]

VP9 experts,

While updating frame marking to add back VP9, I had difficulty finding an indicator for discardable non-reference frames in the VP9 RTP payload draft to map to the frame marking “D” bit. VP8 has the “N” bit for this in the first payload byte (payload descriptor). But VP9 lacks anything similar, although section 8 thinks this should be in section 4.2 (but there is nothing there or elsewhere).

https://tools.ietf.org/html/draft-ietf-payload-vp9-11#section-8
   ...Media aware network
   elements MAY use the information in the VP9 payload descriptor in
   Section 4.2<https://tools.ietf.org/html/draft-ietf-payload-vp9-11#section-4.2> to identify non-reference frames and discard them in
   order to reduce network congestion.  Note that discarding of non-
   reference frames cannot be done if the stream is encrypted (because
   the non-reference marker is encrypted).

Is this an oversight? Or was the non-ref indicator intentionally removed? If so, why?

From my work on AV1, I know how the 8 reference frames work in AV1/VP9, so I devised a solution for frame marking. But it seems like a hack to require this knowledge and go deep into the bitstream uncompressed header (not RTP payload descriptor) to extract this information. Is this really what we must do for VP9? Here is what I put in frame marking version -12, which seems like a hack:

https://tools.ietf.org/html/draft-ietf-avtext-framemarking-12#section-3.3.1
   The D bit MUST be 1 if the refresh_frame_flags in the VP9 payload
   uncompressed header are all 0, otherwise it MUST be 0.

Reading the refresh_frame_flags from the payload requires some payload parsing and checks since it’s not a fixed offset, and requires knowing subtle nuances like key frames implicitly force all 8 flags to 1. If implementers have been confused by something as simple as TL0PICIDX++, they will likely stumble on this as well.

Is it possible to revive the VP8 N bit? This would simplify frame marking, AV1 DD, GCC, L2/L3 QoS mappings, or anything else that wants to know about discardable data.

Regards,
Mo