> I am using the RTSP client of Live555 in my application. The purpose is to
> support CableCARD tuners. I got it working for some devices (such as Ceton
> InfiniTV) but encountered a problem with SiliconDust's HDHomeRun PRIME. What
> I found out (and also confirmed by SiliconDust support) is that the device
> sends a value of 96 for payload type in the SDP description, like the
> following,
>
> v=0
> t=0 0
> a=type:broadcast
> a=recvonly
> m=video 0 RTP/AVP 96
> a=rtpmap:96 MP2T/27000000
>
> but when the actual video is streamed, the type is of value 33.
This is clearly an error in the server (the "SiliconDust's HDHomeRun PRIME").
It is advertising that its RTP packets are using RTP payload format code 96 -
which is wrong - and using a RTP timestamp frequency of 27000000 - which is
probably also wrong. (MPEG Transport Stream packets are usually streamed in
RTP with a standard RTP timestamp frequency of 90000.)
The server needs to be fixed, because it is advertising a stream that it is not
providing.
Instead of these SDP lines:
m=video 0 RTP/AVP 96
a=rtpmap:96 MP2T/27000000
The server should be fixed so that it sends just:
m=video 0 RTP/AVP 33
because "33" is a static RTP payload format code, defined specifically to mean:
streaming MPEG Transport Stream data at frequency 90000.
Or, if the server really is using a nonstandard RTP timestamp frequency of
27000000 (which is unlikely, but conceivable), then it should send:
m=video 0 RTP/AVP 33/27000000
Please contact "SiliconDust" to tell them to fix their server, and suggest that
- in the future - they use our free RTSP client applications "testRTSPClient"
and "openRTSP" to test their RTSP implementation.
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
