SteveK wrote: > On Apr 30, 2005, at 11:25 PM, Ben Lear wrote: > >> Kenny Shumard wrote: >>> On 4/29/05, Jeff Grollo <[EMAIL PROTECTED]> wrote: >>>> The enlightening iax(2) spec released yesterday describes >>>> timestamps for meta video frames as 16 bits. However, the diagram >>>> for meta video frames displays a '?' as bit 0 in the timestamp. >>>> chan_iax2.c (line 7324) only uses the lower 15 bits of the >>>> timestamp to construct a full 32-bit timestamp: >>>> >>>> fr.ts = (iaxs[fr.callno]->last & 0xFFFF8000L) | (ntohs(mh->ts) >>>> & 0x7fff); >>>> >>>> Is that bit of the timestamp reserved or should the full 16 bits be >>>> used in timestamp calculations? >>>> >>>> Jeff Grollo >>>> >>> >>> This was exactly my question, and why I had that '?' there. >>> Any insight from anyone on that bit? >> >> It would be nice if it is/could be used to indicate a complete image >> frame, basically the equivilent of an RTP Headers "M" bit. > > That's interesting; I was thinking of sending I frames via > full frames, as opposed to "mini-video" frames, Which would > implicitly do the same thing (and also get a > retransmit/acknowledgment for them). My feeling was that it made > sense to send them reliably, since otherwise the following P (or > preceeding B) frames don't make much sense without the I frame.
Error resilience(what I think you are getting at) is another issue all together, and handled to some extent by the RTP format in a lot of cases. My intended usage of the extra bit(if indeed it is available to use) would be used as an RTP frame "marker". The following definition straight out of an RTP RFC describes it fairly clearly; Marker bit (M bit): The Marker bit of the RTP header is set to 1 when the current packet carries the end of current frame, and is 0 otherwise. The assumption is that each "packet" will contain at most one(1) encoded image or part thereof(to be clear a single packet *WILL NOT* contain references to more then one encoded image), if said encoded image is too large to fit into a single packet then it may be split across multiple packets(as per relevent RFC). The reciever will concatenate all received packet payloads until a packet with a marker is detected, this signals the start of a new encoded frame(or end of the last, depending on how you look at it :P) and the current concatenated payload data can be sent to be decoded. The above is all well and good, however, we need to determine if the extra bit *IS* actually available *AND* is not reserved for some other use. Can someone shed some light on this?????? Cheers, Ben. _______________________________________________ Asterisk-Dev mailing list [email protected] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
