[Live-devel] frame-specific header patches

[Matthew Romaine]

Hi Ross,

As a followup to the below, I think if the use(...) method in 
BufferedPacket were protected and virtual, it would solve the 
timestamp-per-frame issue by allowing subclasses to recalculate the 
timestamp. The AMR/QCELP payloads have an extra few classes due to 
interleaving support, but for payloads that support multiple frames per 
packet w/o interleaving, I think the above change would suffice ...

Does this make sense, or do you recommend a different strategy?

thanks,
matt

On 2005/02/07, at 20:14, Matthew Romaine wrote:


> Hi Ross,
>
> I've added support for frame-specific headers. Changes were only 
> necessary on the Sink side; at the moment I've only tested them for 
> single frames per packet, but should work for multi-frame packets. 
> Reason for not testing with multi-frame packets is that it seems that 
> when a client asks for a next frame, the timestamp is not updated for 
> each successive frame in a packet. In other words, frames 2+ in a 
> packet continue to be associated with the timestamp for the first 
> frame.
>
> Is this correct? I looks like AMR, QCELP etc. manage to compensate for 
> this through a deInterleaving class, but I wonder if there is a 
> simpler way for payloads that don't interleave ...
>
> thnx,
> matt
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live.com/pipermail/live-devel/attachments/20050208/22d472a0/attachment.html