[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