[Live-devel] Why is the FileSink (QuickTime ...etc.) buffer size based on frame rather than individual RTP packet?

[Ross Finlayson]

>Frames from live source may vary greatly in reality. However the 
>design of sink classes such as QuickTimeFileSink is implemented 
>using fixed buffer size. This may result in some frames being 
>truncated unexpectedly. Why not base the buffer size on individual 
>RTP packet in low level receiving mechanism and then return or pass 
>an appropriately allocated memory for a full frame to its 
>corresponding handler method?

Note that there's no way to know in advance how large 'frames' (which 
may consist of data from several consecutive RTP packets) are going 
to be.  A 'frame' can be arbitrarily large.

All data delivery (note: not just for data from incoming RTP packets) 
for "FramedSource" objects is done using fixed-size buffers, using 
the "FramedSource::getNextFrame()" mechanism.  It would certainly be 
possible, in principle, to redo this to use dynamic memory allocation 
(i.e., using 'realloc'), but it would involve a complete redesign and 
reimplementation of the entire library, and would probably not be as 
suitable for environments like embedded systems (which often don't 
like to do dynamic allocation of arbitrary-sized buffers).


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>