[Live-devel] Setting Multiple Parameters with one SET_PARAMETER command

Matt Schuckmann matt at schuckmannacres.com
Thu Sep 27 09:32:21 PDT 2012


On 9/27/2012 7:06 AM, Ross Finlayson wrote:
> Note that, in contrast, an "OnDemandServerMediaSubsession" object is 
> the *wrong* thing to be inspecting, because that class represents a 
> piece of media that can be streamed, possibly several different times 
> (sequentially or concurrently), to many different clients (which might 
> have request TCP streaming, or UDP streaming).
>
> And a "StreamState" object is also the wrong thing to be inspecting, 
> because that class represents the state of a currently ongoing stream 
> (from the piece of media represented by 
> an "OnDemandServerMediaSubsession" object), *possibly to several 
> different concurrent clients* (if the "reuseFirstSource" parameter was 
> set to True).
>

> In fact, I'm not convinced that any developer needs to have the 
> "StreamState" class (or the "Destinations" class) visible, so there's 
> a good chance that this visibility will be removed in future releases 
> of the software.  (So if you, or anyone, believes that they really 
> need these classes to remain visible, then please let us know ASAP.)
>

For an example, our sever session status widget displays, among other 
things the RTP and RTCP ports for UDP that are in use for each stream in 
each client session. Right or wrong the way we did it before was by 
sub-classing RTSPClientSession so we'd have access to the void* 
streamToken for each stream and then through OnDemaindMediaSubsession 
(or a subclass there of) inspecting the values in the StreamState 
object. Each RTSPClientSession object has a list of StreamState objects 
that appears to hold all of this kind of information and it appears to 
be specific to the client session. Looking at 
OnDemandServerMediaSubsession::getStreamParameters() it looks like the 
StreamState and Destinations objects do get shared if fReuseFirstSource 
is true otherwise a new set of each gets created for each client 
session. In our case fReuseFirstSource is never true so any sharing have 
states has never been a problem.
I'm not quite sure how it works if fReuseFirstSource is set and one 
client requests a TCP connection and another a UDP?
Spending a few minutes looking at the code this morning I can't see 
another easy way to do this.

In looking at the change log, in June of last year you intentionally 
moved the definition of StreamState to OnDemandServerMediaSubsession.hh 
so that subclasses of OnDemandServerMediaSubsession could access them. I 
remember when you did this and I thought it was due to a specific 
request from the mailing list but I can't find the thread now.

Matt S.

>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel

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


More information about the live-devel mailing list