Subject: [payload] WGLC for draft-ietf-payload-vp8-03 ending March 1st

From: tom harper <[email-masked]>
Date: Thu, 22 Mar 2012 09:20:32 -0700

Hi to all,

It looks like I am a little late to the party here.  However, after 
implementing the current VP8 payload RFC,  I would like to clarify some 
details regarding several of the bit fields in the rtp header before 
this is finalized.  Also, I have one question about the current data 
layout choice.

So first I want to discuss the current bit field usage intent.

My main use case for vp8 over rtp would involve making occasional use of 
the alt-ref and golden frames as references, in a similar manner to how 
LTR frames can be used in h264.  The method for determining if your 
frame actually references or updates a LTR in H264 is opaque and not 
addressed in rtp, but rather in the nalu header, and I was hoping that 
something similar could be avoided here such that it would be easier for 
a muxer/demuxer to know what sort of data is in the packet without 
having to delve too deeply into the specific codec.  I am also wondering 
if my usage can coexist with the temporal layers technique currently 
used within chrome, as it appears very similar in many manners below the 
surface.

So my first thought is that it should be possible to use TID & TL0PICIDX 
to signal if you are referencing an altref or golden frame- From the 
rfc, it states that I can set TID=0 and increment TL0PICIDX  whenever I 
send a frame that updates alt/gld.  Then when I reference an alt/gld, I 
would set TID = 0 and then just set the TLOPICIDX to the TL0PICIDX of 
the altref or golden frame id I am referencing.  In my case I don't want 
to send TL0PICIDX  with every base layer frame, only ones I care about 
referencing later.  It isn't called out as required that I increment 
TL0PICIDX when TID it isn't sent, and for my use I would rather not send 
it all the time.  If this usage will break something in terms of what it 
was intended to do it would be good to clarify this area more.

Alternately, to support my use case, I could just avoid using TLOPICIDX 
altogether and just use the existence of the rotating KEYIDX when I have 
a frame that references a golden or altref.  This method is not ideal 
because of lacking a reference Id, the two sides could theoretically be 
out of synch due to lost back channel messages.  Second, the rules 
surrounding KEYIDX update are not identified with absolute certainty so 
my usage would theoretically be non-interoperable.  It seems like I 
could just include it and increment it whenever I have a key frame or a 
frame that references a previous good frame, and not include it 
otherwise.  This usage isn't explicit, so it seems that some 
clarification around KEYIDX usage would be good.

The last point I was hoping to clarify was surrounding the header bit 
fields.  Given the late date, I would guess that the fields are past the 
point of discussion, but I am wondering why the TID/Y fields weren't put 
into the RSV bit space? For temporal layering this would allow for the 
last octet to be skipped most of the time, as the current specification 
doesn't require that the KEYIDX always be sent.  In the most recent 
chrome/rtc code I noted that KEYIDX was always set to 0, so it seems 
only beneficial to drop it.  A RSV 3 bit space could just be moved to 
coexist with KEYIDX instead.   Alternately, you could also increase the 
size of KEYIDX to make it more useful.  It seems a minor point I guess 
but why send an extra byte all the time when it isn't needed?

Proposal Data layout:
+-+-+-+-+-+-+-+-+
|X|R|N|S|PartID | (REQUIRED)
+-+-+-+-+-+-+-+-+
X: |I|L|T|K|TID|Y|R (OPTIONAL)
+-+-+-+-+-+-+-+-+
I: | PictureID | (OPTIONAL)
+-+-+-+-+-+-+-+-+
L: | TL0PICIDX | (OPTIONAL)
+-+-+-+-+-+-+-+-+
K:RSV|  KEYIDX       | (OPTIONAL)
+-+-+-+-+-+-+-+-+

Thanks for your consideration,

Tom

---

From: Patrik Westin <[email-masked]>
Date: Thu, 22 Mar 2012 18:17:02 +0100

I will contact you direct to better understand your use-case to see if
I can help you.

-patrik

On Thu, Mar 22, 2012 at 5:20 PM, tom harper <[email-masked]> wrote:
> details regarding several of the bit fields in the rtp header before this is
> finalized.  Also, I have one question about the current data layout choice.
>
> My main use case for vp8 over rtp would involve making occasional use of the
> alt-ref and golden frames as references, in a similar manner to how LTR
> frames can be used in h264.  The method for determining if your frame
> actually references or updates a LTR in H264 is opaque and not addressed in
> rtp, but rather in the nalu header, and I was hoping that something similar
> could be avoided here such that it would be easier for a muxer/demuxer to
> know what sort of data is in the packet without having to delve too deeply
> into the specific codec.  I am also wondering if my usage can coexist with
> the temporal layers technique currently used within chrome, as it appears
> very similar in many manners below the surface.
>
> So my first thought is that it should be possible to use TID & TL0PICIDX to
> signal if you are referencing an altref or golden frame- From the rfc, it
> states that I can set TID=0 and increment TL0PICIDX  whenever I send a frame
> that updates alt/gld.  Then when I reference an alt/gld, I would set TID = 0
> and then just set the TLOPICIDX to the TL0PICIDX of the altref or golden
> frame id I am referencing.  In my case I don't want to send TL0PICIDX  with
> every base layer frame, only ones I care about referencing later.  It isn't
> called out as required that I increment TL0PICIDX when TID it isn't sent,
> and for my use I would rather not send it all the time.  If this usage will
> break something in terms of what it was intended to do it would be good to
> clarify this area more.
>
> altogether and just use the existence of the rotating KEYIDX when I have a
> frame that references a golden or altref.  This method is not ideal because
> of lacking a reference Id, the two sides could theoretically be out of synch
> due to lost back channel messages.  Second, the rules surrounding KEYIDX
> update are not identified with absolute certainty so my usage would
> theoretically be non-interoperable.  It seems like I could just include it
> and increment it whenever I have a key frame or a frame that references a
> previous good frame, and not include it otherwise.  This usage isn't
> explicit, so it seems that some clarification around KEYIDX usage would be
> good.
>
> into the RSV bit space? For temporal layering this would allow for the last
> octet to be skipped most of the time, as the current specification doesn't
> require that the KEYIDX always be sent.  In the most recent chrome/rtc code
> I noted that KEYIDX was always set to 0, so it seems only beneficial to drop
> it.  A RSV 3 bit space could just be moved to coexist with KEYIDX instead.
> Alternately, you could also increase the size of KEYIDX to make it more
> useful.  It seems a minor point I guess but why send an extra byte all the
> time when it isn't needed?
>
> Proposal Data layout:
> +-+-+-+-+-+-+-+-+
> _______________________________________________
> payload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/payload

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 22 Mar 2012 23:16:04 +0000

Please keep the list up to date about the developments and changes you are planning to make if any.

-acbegen

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Patrik Westin
> Sent: Friday, March 23, 2012 4:17 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [payload] WGLC for draft-ietf-payload-vp8-03 ending March 1st
>