On 6/26/2013 2:15 AM, live-devel-requ...@ns.live555.com wrote:
Message: 2
Date: Tue, 25 Jun 2013 12:38:41 -0700
From: Ross Finlayson <finlay...@live555.com>
To: LIVE555 Streaming Media - development & use
<live-de...@ns.live555.com>
Subject: Re: [Live-devel] RTSP client and SiliconDust HDHomeRun Prime
Message-ID: <659ae46f-08b4-43aa-86dd-cbd80e2c2...@live555.com>
Content-Type: text/plain; charset="us-ascii"
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.
Thanks for the reply.
I am contacting SiliconDust, and hoping they will fix the problem soon.
Meanwhile, in order to make their device work in our application (JRiver
Media Center), we are temporarily ignoring the payload type discrepancy,
in the following way, until SiliconDust fixes the problem.
We change this block
// Check the Payload Type.
if ((unsigned char)((rtpHdr&0x007F0000)>>16)
!= rtpPayloadFormat()) {
break;
}
to this
// Check the Payload Type.
// Kludge - HDHomeRun Prime advertises the value 96, but sends
the value 33
if ((unsigned char)((rtpHdr&0x007F0000)>>16) !=
rtpPayloadFormat() &&
((unsigned char)((rtpHdr&0x007F0000)>>16) != 33 ||
rtpPayloadFormat() != 96)) {
break;
}
inside function MultiFramedRTPSource::networkReadHandler1().
Thanks again.
Yaobing Deng
JRiver
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
