[Asterisk-Dev] iax2 video frame timestamps

[Ben Lear]

SteveK wrote:
> On Apr 30, 2005, at 11:25 PM, Ben Lear wrote:
> 
>> Kenny Shumard wrote:
>>> On 4/29/05, Jeff Grollo <jgrollo at horizonlive.com> 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.