[Live-devel] frame headers

[Ross Finlayson]

>>So, at least for now, you should fill in your RTP-specific headers - 
>>along with your frame data - in the ("FramedSource" or "FramedFilter") 
>>subclass that will feed into your "RTPSink" subclass. Admittedly, this is 
>>a 'layering violation' (RTP-specific stuff should really remain within 
>>your "RTPSink" subclass), but it seems to be the only way to do what you 
>>want for now.
>what other payload formats currently supported by the liveMedia package 
>are taking this route to resolve the issue? Are there enough to inspire a 
>new release that will fix the 'layering violation'?

Right now three audio RTP payload formats have the same issue: MPEG-4 
(generic), AC-3 and AMR.  However, the current implementation of the 
"RTPSink" subclass for each of these avoids the problem by permitting just 
one audio frame (and thus, just one special RTP-specific header) in each 
outgoing RTP packet.

To date, we haven't had any customers who wanted to support more than one 
of these frames packed into an outgoing RTP packet.  So there hasn't yet 
been enough of an incentive to come up with a proper solution.


	Ross Finlayson
	LIVE.COM
	<http://www.live.com/>