> Actually, that's true only if the "reuseFirstSource" parameter was set to
> True.
> If "reuseFirstSource" is False (its default value), then each client request
> (to
> "SETUP"/"PLAY" the stream) will create a new stream source (and a new
> "StreamState" object).
That makes sense now. Thanks f
Hi Ross.
> The additions to the "RTCPInstance" class (to assign a
> RTCP "APP" packet handler, and send an "APP" packet) look
> reasonable, and I'll probably add them to the library soon.
That's good to know, thanks.
> The changes to "OnDemandServerMediaSubsession", however,
> don't look quite r
Ross.
Attached is a patch that implements bidirectional RTCP APP
packet support between client and server.
The user is able to send an APP packet by calling
RTCPInstance::sendAppPacket() from the client or
OnDemandServerMediaSubsession::sendRTCPAppPacket()
on the server.
APP packets can be recei
I'm using Live555 to replace an old streaming stack in a video / audio
recording system. One of the requirements of this system is that any
client playing back the media should be able to display the original time
at which the video / audio was recorded. In the previous system this
was supported by
Hi Ross.
We have a need to handle RTCP APP packets in our application. I notice from the
Live555 RTCPInstance code that they are currently ignored.
If we were to implement a way for a subclass of OnDemandMediaSubsession to
provide a custom handler for APP packets, in a similar way that handlers
Greetings.
We are currently exploring the possibility of using Live555 in a product
consisting of a proprietary code base, that must run on both Windows and Linux.
In order to comply with the LGPL, but not have to release our entire codebase,
we must build Live555 as shared libraries. Currently
