[Live-devel] Patch request and question

[Ross Finlayson]

> > >First, can someone please add the following line to the class
> > >definition of MediaSubsession in MediaSession.hh to add access to the
> > >rtp payload type:
> > >
> > >unsigned char rtpPayloadFormat() const { return fRTPPayloadFormat; }
> >
> > Are you sure you really need this?  If you've already called "initiate()",
> > you can also get this value by calling
> >          subsession->rtpSource()->rtpPayloadFormat()
>
>I would like to have this since I am using my own (very specialized
>and minimalistic) RTP implementation, I just want the live stack for
>the RTSP capabilities.

That seems like more trouble than it's worth (e.g., are you also 
implementing RTCP, like you're suppose to?) - but anyway, this addition to 
"MediaSession.hh" will be included in the next software release.

>The stream is raw MPEG2-TS over UDP.  Unfortunately looking at the
>DESCRIBE response they don't put the M2TP/H2221/UDP in the SDP, it
>looks like it is advertising an MPEG-2 TS stream over RTP.  But it
>will only accept a SETUP with that particular payload description .  I
>guess my only option is to send the default SETUP, wait for the 416
>response, then try the M2TP one to see if it works.
>
>Unfortunately my capture doesn't have an OPTIONS request so I can't
>determine whether it is possible to identify an nCube server by this
>method.  I can provide the capture on Monday if anyone is interested.

Yes, please post the results of running "openRTSP -V" on this 
server.  Perhaps there's some other way (e.g., given by a "Server:" header 
in a "DESCRIBE" response) to identify this kind of server?

In general, though, I'm disinclined to continue to clutter up the code to 
support broken, non-standard servers like these.  But if there's a way to 
accommodate this server with only a small amount of extra code, then I 
might consider it.


	Ross Finlayson
	LIVE.COM
	<http://www.live.com/>