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

[Matt Schuckmannn]

Worked like a charm, thank you Ross.

Matt S.


On 6/14/2011 2:45 PM, Matt Schuckmannn wrote:
> 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.
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel