[Live-devel] Modifying LiveMedia RTSPServer classes to support URI parameters

Matt Schuckmannn matt at schuckmannacres.com
Tue Jun 14 14:45:56 PDT 2011


Ah I think I see what your saying I took your words 
"ServerMediaSubsession (subclass)" to mean that you were suggesting that 
I create an entirely new subclass type for each possible combination of 
parameters but you meant a new instance of a sub class of 
ServerMediaSubsession for each connection.

Yes, that does seem much more feasible, don't know why I didn't see it 
before.
I will investigate that approach and let you know how it goes.

Thanks,
Matt S.

On 6/14/2011 2:27 PM, Ross Finlayson wrote:
>>> For example (to use your example string), 
>>> "live_video?height=320&width=400&kbps=300&fps=15" would use a 
>>> completely separate "ServerMediaSubsession" (subclass) object than 
>>> "live_video?height=320&width=400&kbps=300&fps=30".
>>>
>> This seems infeasible as I want to be able support any number of 
>> combination of all 4 of these parameters (plus more parameters like 
>> GoP size etc).
>
> No, it's completely feasible.  The trick is *not* to create all of the 
> possible the "ServerMediaSession" (and "ServerMediaSubsession") 
> objects upfront, but instead to create them 'on demand', when needed. 
> This is what we do for the "LIVE555 Media Server" application, using 
> the "DynamicRTSPServer" class - which subclasses "RTSPServer" and 
> reimplements the virtual function "lookupServerMediaSession()". (Note 
> the code in the "mediaServer" directory.)  You could do something 
> similar.
>
>
>> Seems much more reasonable to have one subclass of ServerMediaSession 
>> and ServerMediaSubsession that can read and interpret the parameters 
>> on a per connection basis.
>
> Well, the problem with that is - as you've discovered - that the 
> "ServerMediaS(ubs)ession" objects are assumed to each represent a 
> single 'media object' that you're streaming - e.g., a file.  If you 
> open another stream with different codec parameters, it's conceptually 
> like streaming from a different file.
>
> Either way will probably work, but I suspect that you'll find it 
> easier to use a different "ServerMediaS(ubs)ession" object for each 
> parameter combination - but create these on demand.


More information about the live-devel mailing list