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

[Patrik Westin <[e-mail]>]

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