[Live-devel] About send/receive video and audio simultaneously and RTCPInstance questions

Ross Finlayson finlayson at live555.com
Wed Oct 12 20:41:40 PDT 2011


> Our device want to send both video and audio data to the our server 
> simultaneously, but I don't how many port I should use in server for 
> receive the video and audio data.
> 
> Should I send both the video and audio data to same port of the server? 
> Can the multiple RTPSources receive from same port for different media 
> type? Or I should separate the transfer channel, use 2 port in the 
> server side so it receive video and audio separately?

If you're sending RTP/UDP packets for both audio and video streams, then you will need to two separate port numbers, and two separate "RTPSource" objects (at the receiver) to receive them.


> The other question: Why the destructor of the "RTCPInstance" is 
> protected? No need for dynamically create this type object and manual 
> destroy it?

All subclasses of "Medium" (which includes "RTCPInstance") have a protected constructor, to prevent objects of such classes from being allocated on the stack.  (We force all such objects to be heap-allocated, because that then makes it possible to define and implement subclasses of these classes, without having to recompile library code that uses the base class.)  Instead, all subclasses of "Medium" use a "createNew()" static function to create new objects of the class.

Similarly, subclasses of "Medium" also have a protected destructor, and we use the "Medium::close()" function to delete them.  Strictly speaking, though, I don't think this is necessary; we might be able to have public destructors instead.  (However, I think that having public destructors with protected constructors might cause warning messages for some compilers.)


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20111012/f41e78d5/attachment.html>


More information about the live-devel mailing list