Re: [avtext] Frame marking & VP9 SVC

[Bernard Aboba <[e-mail]>]

Sergio said:

"So the question is they can be mapped 1-to-1 to the frame marking I and B
bits. If so, just adding that to the draft that the I and B bits on the
frame marking extension must be filled with the values of the vp9 P and U
bits ( I=!P , B=U), would work."

[BA] It's not obvious to me that the P or U bits can be inferred from
existing framemarking bits including the I and B bits.  Consider the
following dependency diagrams (done in the style of the examples in
https://tools.ietf.org/html/draft-ietf-avtext-lrr ):


Example 1


        ... <--  S2  <--  S2       S2  <--  S2  <-- ...
                  |        |        |        |

                                 \/              \/               \/
           \/


        ... <--  S1  <--  S1       S1  <--  S1  <-- ...
                  |        |        |        |
                 \/       \/       \/       \/
        ... <--  S0  <--  S0  <--  S0  <--  S0  <-- ...

                  1        2        3        4



In this example, it looks to me like all the S0 frames have the B bit
set to 1, but none of the S0, S1 or S2 frames have the I bit set to 1.

Frames 3 S1 and S2 have the B bit set to 1, all other S1 and S2 frames
have the B bit set to zero.


It also looks to me like only frames 3 S1 and S2 have the P bit set to
zero, all other S0, S1 and S2 frames have it set to 1.

So there is no clear relationship between the I and P bits.



Example 2


        ... <--  S2  <--  S2  <--  S2  <--  S2  <-- ...
                  |        |        |        |

                                 \/              \/               \/
           \/

        ... <--  S1  <--  S1  <--  S1  <--  S1  <-- ...
                  |        |        |        |
                 \/       \/       \/       \/
        ... <--  S0  <--  S0       S0  <--  S0  <-- ...

                  B        B       BIP      B



                  1        2        3        4



In this example, it looks to me like all the S0 frames have the B bit
set to 1, but only S0 frame 3 has the I bit set to 1.

None of the S1 or S2 frames have the B or I bits set to 1.  It also
looks to me like none of the frames have the P bit set to 0 or the U

bits set to 1, except frame 3 S0.  So in this example, the I and P
bits are the inverse of each other, but it's not clear how the

U bit can be inferred from other bits.


Here are the definitions of the framemarking I, D and B bits:


   o  I: Independent Frame (1 bit) - MUST be 1 for frames that can be
      decoded independent of prior frames, e.g. intra-frame, VPX
      keyframe, H.264 IDR [RFC6184
<https://tools.ietf.org/html/rfc6184>], H.265 IDR/CRA/BLA/RAP [RFC7798
<https://tools.ietf.org/html/rfc7798>];
      otherwise MUST be 0.
   o  D: Discardable Frame (1 bit) - MUST be 1 for frames that can be
      discarded, and still provide a decodable media stream; otherwise
      MUST be 0.
   o  B: Base Layer Sync (1 bit) - MUST be 1 if this frame only depends
      on the base layer; otherwise MUST be 0.  If no scalability is
      used, this MUST be 0.



Here are the P and U bit definitions:


   P: Inter-picture predicted layer frame.  When set to zero, the layer
      frame does not utilize inter-picture prediction.  In this case,
      up-switching to current spatial layer's frame is possible from
      directly lower spatial layer frame.  P SHOULD also be set to zero
      when encoding a layer synchronization frame in response to an LRR
      [I-D.ietf-avtext-lrr
<https://tools.ietf.org/html/draft-ietf-payload-vp9-03#ref-I-D.ietf-avtext-lrr>]
message (see Section 5.4
<https://tools.ietf.org/html/draft-ietf-payload-vp9-03#section-5.4>).
When P is set to
      zero, the T bit (described below) MUST also be set to 0 (if
      present).


   U: Switching up point.  If this bit is set to 1 for the current
      frame with temporal layer ID equal to T, then "switch up" to a
      higher frame rate is possible as subsequent higher temporal
      layer frames will not depend on any frame before the current
      frame (in coding time) with temporal layer ID greater than T.




On Wed, Jul 5, 2017 at 10:30 AM, Sergio Garcia Murillo <
[e-mail]> wrote:

> On 05/07/2017 17:56, Jonathan Lennox wrote:
>
>> Sergio — the updated VP9 payload draft I submitted Monday includes a
>> section describing its usage with frame marking.
>>
>> Let me know what you think?  It changes the S and T fields to reflect the
>> latest VP9 and frame marking drafts, but it does not include the P or U
>> bits.
>>
>> I think the intention is that frame marking’s B bit will provide a
>> coarser-grain version of what P and U do (and the “don’t use it with weird
>> structures” requirement will make that sufficient, though that may need to
>> be made more specific).  What do you think?
>>
>
> An SFU requires both VP9  P and U bits in order to be able to do up and
> down switching. So the question is they can be mapped 1-to-1 to the frame
> marking I and B bits. If so, just adding that to the draft that the I and B
> bits on the frame marking extension must be filled with the values of the
> vp9 P and U bits ( I=!P , B=U), would work.
>
> By the way, I liked more the "layer frame" and "frame" vs "frame"
> "picture" (but it is just a personal preference), but I am not sure if
> there haven't been any typos on the renaming, I will have to review it in
> deep because there are some things that seems wrong at first glance (but I
> am probably wrong). Will send a new email if I find anything.
>
> Best regards
> Sergio
>
> _______________________________________________
> avtext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avtext
>