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

["Ali C. Begen (abegen)" <[e-mail]>]

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

-acbegen

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Patrik Westin
> Sent: Friday, March 23, 2012 4:17 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: [payload] WGLC for draft-ietf-payload-vp8-03 ending March 1st
> 
> 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 <[e-mail]> wrote:
> > 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
> > _______________________________________________
> > payload mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/payload
> _______________________________________________
> payload mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/payload