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

[tom harper <[e-mail]>]

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