[Live-devel] frame-specific header patches

[Ross Finlayson]

>>>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.
>>Actually, I think the best solution for this (making RTP sources return 
>>correct timestamps for multiple frames packed within a single RTP packet) 
>>would be to redefine the existing "nextEnclosedFrameSize()" virtual 
>>function to return a frame duration (by default, 0), and to have 
>>"BufferedPacket::use()" add this duration onto its "fPresentationTime" 
>>(after setting the "presentationTime" to be returned).
>will these changes be incorporated in the next release along with the 
>frame-specific header changes?

FYI, the latest release (2005.02.09) contains both of these changes.

In particular, in "MultiFramedRTPSource.hh", the "BufferedPacket" virtual 
member function "nextEnclosedFrameSize()" has now been deprecated.  New 
subclasses (e.g., the one that you'll be writing for your ATRAC/RTP 
receiving implementation) should, instead, (re)define 
"getNextEnclosedFrameParameters()".  This returns a frame duration (in 
microseconds), which "MultiFramedRTPSource" uses to give correct 
presentation times to multiple frames within each incoming RTP packet.

This new support for multiple frames in RTP packets (for both senders 
("MultiFramedRTPSink") and receivers ("MultiFramedRTPSource")) has not been 
extensively tested, so if you see any problems, let me know.